RFC1940 日本語訳
1940 Source Demand Routing: Packet Format and Forwarding Specification(Version 1). D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. May 1996. (Format: TXT=60858 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Estrin
Request for Comments: 1940 USC
Category: Informational T. Li
Y. Rekhter
cisco Systems
K. Varadhan
D. Zappala
USC
May 1996
Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1940年のUSCカテゴリ: 情報のT.李Y.RekhterコクチマスSystems K.Varadhan D.Zappala USC1996年5月
Source Demand Routing:
Packet Format and Forwarding Specification (Version 1).
ソース要求ルート設定: パケット・フォーマットと推進仕様(バージョン1)。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
1. Overview
1. 概要
The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This document refers to such source-initiated routes as "SDRP routes". This document describes the packet format and forwarding procedure for SDRP. It also describes procedures for ascertaining feasibility of SDRP routes. Other components not described here are routing information distribution and route computation. This portion of the protocol may initially be used with manually configured routes. The same packet format and processing will be usable with dynamic route information distribution and computation methods under development.
SDRPの目的は既存のルーティング・プロトコルによって相互ドメインとイントラドメインルートの両方に提供されたルート選択の補足となるようにルートの情報筋によって開始された品揃えをサポートすることです。 このドキュメントは「SDRPは発送します」のような情報筋によって開始されたルートを示します。 このドキュメントはSDRPのためにパケット・フォーマットと推進手順について説明します。 また、それはSDRPルートに関する実現の可能性を確かめるための手順について説明します。 ここで説明されなかった他のコンポーネントは、ルーティング情報流通と経路計算です。 プロトコルのこの部分は初めは、手動で構成されたルートで使用されるかもしれません。 同じパケット・フォーマットと処理はダイナミックなルート情報流通と開発中の計算メソッドで使用可能になるでしょう。
The packet forwarding protocol specified here makes minimal assumptions about the distribution and acquisition of routing information needed to construct the SDRP routes. These minimal assumptions are believed to be sufficient for the existing Internet. Future components of the SDRP protocol will extend capabilities in this area and others in a largely backward-compatible manner.
ここで指定されたパケット推進プロトコルはルーティングの分配と獲得に関する最小量の仮定をSDRPルートを構成するのに必要である情報にします。 これらの最小量の仮定が既存のインターネットに十分であると信じられています。 SDRPプロトコルの将来の成分は主に後方コンパチブル方法でこの領域と他のものの能力を広げるでしょう。
This version of the packet forwarding protocol sends all packets with the complete SDRP route in the SDRP header. Future versions will address route setup and other enhancements and optimizations.
完全なSDRPルートがSDRPヘッダーにある状態で、パケット推進プロトコルのこのバージョンはすべてのパケットを送ります。 将来のバージョンはルートセットアップ、他の増進、および最適化を扱うでしょう。
Estrin, et al Informational [Page 1] RFC 1940 SDRv1 May 1996
Estrin、他Informational[1ページ]RFC1940のSDRv1 May 1996
2. Model of operations
2. 操作のモデル
An Internet can be viewed as a collection of routing domains interconnected by means of common subnetworks, and Border Routers (BRs) attached to these subnetworks. A routing domain itself may be composed of further subnetworks, routers interconnecting these subnetworks, and hosts. This document assumes that there is some type of routing present within the routing domain, but it does not assume that this intra-domain routing is coordinated or even consistent.
経路ドメインの収集が一般的なサブネットワークによってインタコネクトしたようにインターネットを見ることができました、そして、Border Routers(BRs)はこれらのサブネットワークに付きました。 経路ドメイン自体は一層のサブネットワーク、これらのサブネットワークとインタコネクトするルータ、およびホストで構成されるかもしれません。 このドキュメントは、タイプの経路ドメインの中に存在しているルーティングがあると仮定しますが、それは、このイントラドメインルーティングが連携しているか、または一貫してさえいると仮定しません。
For the purposes of this discussion, a BR belongs to only one domain. A pair of BRs, each belonging to a different domain, but attached to a common subnetwork, form an inter-domain connection. By definition, packets that traverse multiple domains must traverse BRs of these domains. Note that a single physical router may act as multiple BRs for the purposes of this model.
この議論の目的のために、BRは1つのドメインだけに属します。 1組のBRs(一般的なサブネットワークに異なったドメインに属しましたが、付けられたそれぞれ)は相互ドメイン接続を形成します。 定義上、複数のドメインを横断するパケットはこれらのドメインのBRsを横断しなければなりません。 ただ一つの物理的なルータがこのモデルの目的のために同じくらい複数のBRsを機能させるかもしれないことに注意してください。
A pair of domains is said to be adjacent if there is at least one pair of BRs, one in each domain, that form an inter-domain connection.
少なくとも1組のBRsがあれば1組のドメインが隣接していると言われて、あるコネが各ドメインであり、そのフォームは相互ドメイン接続です。
Each domain has a globally unique identifier, called a Domain Identifier (DI). All the BRs within a domain need to know the DI assigned to the domain. Management of the DI space is outside the scope of this document. This document assumes that Autonomous System (AS) numbers are used as DIs. A domain path (or simply path) refers to a list of DIs such as might be taken from a BGP AS path [1, 2, 3] or an IDRP RD path [4]. We refer to a route as the combination of a network address and domain paths. The network addresses are represented by NLRI (Network Layer Reachability Information) as described in [3].
Domain Identifier(DI)は、各ドメインにはグローバルにユニークな識別子があると呼びました。 ドメインの中のすべてのBRsが、そのドメインに割り当てられたDIを知る必要があります。 このドキュメントの範囲の外にDIスペースの管理があります。 このドキュメントは、Autonomous System(AS)番号がDIsとして使用されると仮定します。 ドメイン経路(または、単に経路)はBGP AS経路[1、2、3]かIDRP RD経路[4]から取るかもしれないようなDIsのリストを示します。 私たちはネットワーク・アドレスとドメイン経路の組み合わせとルートを呼びます。 ネットワーク・アドレスは[3]で説明されるようにNLRI(ネットワークLayer Reachability情報)によって表されます。
This document assumes that the routing domains are congruent to the autonomous systems. Thus, within the content of this document, the terms autonomous system and routing domain can be used interchangeably.
このドキュメントは、経路ドメインが自律システムに一致していると仮定します。その結果、このドキュメントの中身の中では、用語自律システムと経路ドメインは互換性を持って使用できます。
An application residing at a source host inside a domain, communicates with a destination host at another domain. An intermediate router in the path from the source host to the destination host may decide to forward the packet using SDRP. It can do this by encapsulating the entire IP packet from the source host in an SDRP packet. The router that does this encapsulation is called the "encapsulating router."
別のドメインのあて先ホストは、ソースに住んでいるアプリケーションが中でドメインを接待するのをコミュニケートします。 送信元ホストからあて先ホストまでの経路の中間的ルータは、SDRPを使用することでパケットを進めると決めるかもしれません。 それは、SDRPパケットで送信元ホストから全体のIPパケットをカプセルに入れることによって、これができます。 このカプセル化をするルータは「要約ルータ」と呼ばれます。
Estrin, et al Informational [Page 2] RFC 1940 SDRv1 May 1996
Estrin、他Informational[2ページ]RFC1940のSDRv1 May 1996
2.1 SDRP routes
2.1 SDRPルート
A component in an SDRP route is either a DI (AS number) or an IP
address. Thus, an SDRP route is defined as a sequence of domains
and routers, syntactically expressed as a sequence of DIs and IP
addresses. Thus an SDRP route is a collection of source routed
hops.
SDRPルートによるコンポーネントは、DI(AS番号)かIPアドレスのどちらかです。 したがって、SDRPルートはDIsとIPアドレスの系列としてシンタクス上言い表されたドメインとルータの系列と定義されます。 したがって、SDRPルートはソースの発送されたホップの収集です。
Each component of the SDRP route is called a "hop." The packet
traverses each component of the SDRP route exactly once. When a
router corresponding to one of the components of the SDRP route
receives the packet from a router corresponding to the previous
component of the SDRP route, the router will process the packet
according to the SDRP forwarding rules in this packet. The next
component of the SDRP route that this router will forward the
packet to, is called the "next hop," with respect to this router
and component of the SDRP route.
SDRPルートの各部品は「ホップ」と呼ばれます。 パケットはまさに一度SDRPルートの各部品を横断します。 SDRPルートの部品の1つに対応するルータがSDRPルートの前の部品に対応するルータからパケットを受けるとき、SDRP推進規則に従って、ルータはこのパケットでパケットを処理するでしょう。 このルータがパケットを送るSDRPルートの次の部品は、このルータに関して「次のホップ」と呼ばれて、SDRPルートでコンポーネントです。
An SDRP hop can either be a "strict" source routed hop, or a
"loose" source routed hop. A strict source route hop is one in
which, if the next hop specified is a DI, refers to an immediately
adjacent domain, and the packet will be forwarded directly to a
route within the domain; if the next hop specified is an IP
address, refers to an immediately adjacent router on a common
subnetwork. Any other kind of a source route hop is a loose
source route hop.
SDRPホップは、「厳しい」ソース発送されたホップ、または「ゆるい」ソース発送されたホップのどちらかであるかもしれません。 厳しい送信元経路ホップは指定された次のホップがDIであるならすぐに隣接しているドメインについて言及するあるコネです、そして、直接ドメインの中のルートにパケットを送るでしょう。 指定された次のホップがIPアドレスであり、一般的なサブネットワークの上のすぐに隣接しているルータについて言及するなら。 送信元経路ホップのいかなる他の種類もゆるい送信元経路ホップです。
A route is a "strict source route" if the current hop being
executed is processed as a strict source route hop. Likewise, a
route is a "loose source route" if the current hop being executed
is processed as a loose source route hop.
実行される現在のホップが厳しい送信元経路ホップとして処理されるなら、ルートは「厳しい送信元経路」です。 同様に、実行される現在のホップがゆるい送信元経路ホップとして処理されるなら、ルートは「ゆるい送信元経路」です。
It is assumed that each BR participates in the intra-domain
routing protocol(s) (IGPs) of the domain to which the BR belongs.
Thus, a BR may forward a packet to any other BR in its own domain
using intra-domain routing procedures. Forwarding a packet
between two BRs that form an inter-domain connection requires
neither intra-domain nor the inter-domain routing procedures (an
inter-domain connection is a common Layer 2 subnetwork).
各BRがBRが属するドメインのイントラドメインルーティング・プロトコル(IGPs)に参加すると思われます。 したがって、BRは、イントラドメインルーティング手順を用いることでそれ自身のドメインのいかなる他のBRにもパケットを送るかもしれません。 相互ドメイン接続を形成する2BRsの間にパケットを送るのはイントラドメインも相互ドメインルーティング手順も必要としません(相互ドメイン接続は一般的なLayer2サブネットワークです)。
It is also assumed that all routers participate in the intra-
domain routing protocol(s) (IGPs) of the domain to which they
belong.
また、すべてのルータが彼らが属するドメインのイントラドメインルーティング・プロトコル(IGPs)に参加すると思われます。
While SDRP does not require that all domains have a common network
layer protocol, all the BRs in the domains along a given SDRP
route are required to support a common network layer. This
document specifies SDRP operations when that common network layer
SDRPが、すべてのドメインには一般的なネットワーク層プロトコルがあるのを必要としていない間、与えられたSDRPルートに沿ったドメインのすべてのBRsが、一般的なネットワーク層をサポートするのに必要です。 その一般的なネットワーク層であるときに、このドキュメントはSDRP操作を指定します。
Estrin, et al Informational [Page 3] RFC 1940 SDRv1 May 1996
Estrin、他Informational[3ページ]RFC1940のSDRv1 May 1996
protocol is IP ([5]).
プロトコルはIP([5])です。
While this document requires all the BRs to support IP, the
document does not preclude a BR from additionally supporting other
network layer protocols as well (e.g., CLNP, IPX, AppleTalk). If
a BR supports multiple network layers, then for the purposes of
this model, the BR must maintain multiple Forwarding Information
Bases (FIBs), one per network layer.
このドキュメントが、すべてのBRsがIPをサポートするのを必要としている間、他のネットワーク層がまた、プロトコル(例えば、CLNP、IPX、AppleTalk)であるとさらに、サポートするので、ドキュメントはBRを排除しません。 BRが複数のネットワーク層をサポートするなら、このモデルの目的のために、BRは複数の1ネットワーク層あたり1つ歳のForwarding Information基地(FIBs)を維持しなければなりません。
2.2 SDRP encapsulation
2.2 SDRPカプセル化
Forwarding an IP packet along an SDRP route is accomplished by
encapsulating the entire packet in an SDRP packet. An SDRP packet
consists of the SDRP header followed by the SDRP data. The SDRP
header carries the SDRP route constructed by the domain that
originated the SDRP packet. The SDRP data carries the original
packet that the source domain decided to forward via SDRP.
SDRPルートに沿ってIPパケットを進めるのは、SDRPパケットで全体のパケットをカプセルに入れることによって、達成されます。 SDRPパケットはSDRPデータがあとに続いたSDRPヘッダーから成ります。 SDRPヘッダーはSDRPパケットを溯源したドメインによって構成されたSDRPルートを運びます。 SDRPデータはソースドメインがSDRPを通して進めると決めたオリジナルのパケットを運びます。
An SDRP packet is carried across domains as the data portion of an
IP packet with protocol number 42.
SDRPパケットはIPパケットのデータ部としてドメインの向こう側にプロトコル番号42で運ばれます。
This document refers to the IP header of a packet that carries an
SDRP packet as the delivery IP header (or just the delivery
header). This document refers to the packet carried as SDRP data
s the payload packet, and the IP header of the payload packet is
the payload header.
このドキュメントは配送IPヘッダー(または、まさしく配送ヘッダー)としてSDRPパケットを運ぶパケットのIPヘッダーについて言及します。 このドキュメントはペイロードパケットに関するSDRPデータペイロードパケット、およびIPヘッダーのsがペイロードヘッダーであるので運ばれたパケットについて言及します。
Thus, an SDRP Packet can be represented as follows:
したがって、以下の通りSDRP Packetを表すことができます:
+-------------------+--------------+-------------------
| Delivery header | SDRP header | SDRP data
| (IP header) | | (Payload packet)
+-------------------+--------------+--------------------
+-------------------+--------------+------------------- | 配送ヘッダー| SDRPヘッダー| SDRPデータ| (IPヘッダー) | | (有効搭載量パケット) +-------------------+--------------+--------------------
Each SDRP route may have an MTU associated with it. An MTU of an
SDRP route is defined as the maximum length of the payload packet
that can be carried without fragmentation of an SDRP packet. This
means that the SDRP MTU as seen by the transport layer and
applications above the transport layer is the actual link MTU less
the length of the Delivery and SDRP headers. Procedures for MTU
discovery are specified in Section 9.
それぞれのSDRPルートには、それに関連しているMTUがあるかもしれません。 SDRPルートのMTUはSDRPパケットの断片化なしで運ぶことができるペイロードパケットの最大の長さと定義されます。 これは、トランスポート層とアプリケーションでトランスポート層を超えて見られるSDRP MTUが実際のリンクよりMTU以下であることを意味します。DeliveryとSDRPヘッダーの長さ。 MTU発見のための手順はセクション9で指定されます。
2.3 D-FIB
2.3D-空言
It is assumed that a BR participates in either BGP or IDRP. A BR
participating in SDRP augments its FIBs with a D-FIB that contains
routes to domains. A route to a domain is a triplet <DI, Next-
Hop, NLRI>, where DI depicts a destination domain, Next-Hop
BRがBGPかIDRPのどちらかに参加すると思われます。 SDRPに参加するBRはドメインにルートを含むD-FIBと共にFIBsを増大させます。 ドメインへのルートは三つ子の<DI、Nextホップ、NLRI>です。(そこでは、DIが目的地ドメイン、Next-ホップについて表現します)。
Estrin, et al Informational [Page 4] RFC 1940 SDRv1 May 1996
Estrin、他Informational[4ページ]RFC1940のSDRv1 May 1996
depicts the IP address of the next-hop BR, and NLRI depicts the
set of reachable destinations within the destination domain. D-
FIBs are constructed based on the information obtained from either
BGP, IDRP, or configuration information.
表現、BRはIPが次のホップを扱って、NLRIが届いている目的地のセットについて表現する、目的地ドメイン。 D FIBsはBGP、IDRPか設定情報のどちらかから得られた情報に基づいて組み立てられます。
An SDRP packet is forwarded across multiple domains by utilizing
the forwarding databases (both FIBs and D-FIBs) maintained by the
BRs.
複数のドメインの向こう側にBRsによって維持された推進データベース(FIBsとD-FIBsの両方)を利用することによって、SDRPパケットを進めます。
The operational status of SDRP routes is monitored via passive
(Error Reporting) and active (Route Probing) mechanisms. The Error
Reporting mechanism provides the originator of the SDRP route with
a failure notification. The Probing mechanism provides the
originator of the SDRP route with confirmation of a route's
feasibility.
SDRPルートの操作上の状態は受け身(誤りReporting)の、そして、アクティブな(ルートProbing)メカニズムでモニターされます。Error ReportingメカニズムはSDRPルートの創始者に失敗通知を提供します。 Probingメカニズムはルートの実行可能性の確認をSDRPルートの創始者に提供します。
3. SDRP Packet format
3. SDRP Packet形式
The total length of an SDRP packet (header plus data) can be determined from the information carried in the delivery IP header. The length of the payload packet can be determined from the total length of an SDRP packet and the length of its SDRP Header.
SDRPパケット(ヘッダープラスデータ)の全長は配送IPヘッダーで運ばれた情報から決定できます。 SDRPパケットの全長とSDRP Headerの長さからペイロードパケットの長さを測定できます。
The following describes the format of an SDRP packet.
以下はSDRPパケットの形式について説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |D|S|P| | Hop Count |SourceProtoType| Payload Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Route Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Notification |SrcRouteLength | NextHopPtr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Route ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver|D|S|P| | ホップカウント|SourceProtoType| 有効搭載量タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送信元経路識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| 通知|SrcRouteLength| NextHopPtr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースルート… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version and Flags (1 octet)
バージョンと旗(1つの八重奏)
The SDRP version number and control flags are coded in the first
octet. Bit 0 is the most significant bit, bit 7 is the least
significant bit.
SDRPバージョン番号と指揮旗は最初の八重奏でコード化されます。 ビット0が最も重要なビットである、ビット7は最下位ビットです。
Estrin, et al Informational [Page 5] RFC 1940 SDRv1 May 1996
Estrin、他Informational[5ページ]RFC1940のSDRv1 May 1996
Version (bits 0 through 2)
バージョン(ビット0〜2)
The first three bits contain the Version field indicating
the version number of the protocol. The value of this field
is set to 1.
最初の3ビットはプロトコルのバージョン番号を示すバージョン分野を含んでいます。 この分野の値は1に設定されます。
Flags (bits 3 through 7)
旗(ビット3〜7)
Data packet/Control packet (bit 3)
データ・パケット/コントロールパケット(ビット3)
If the bit is set to 1, then the packet carries data.
ビットが1に設定されるなら、パケットはデータを運びます。
Otherwise, the packet carries control information.
さもなければ、パケットは制御情報を運びます。
Loose/Strict Source Route (bit 4)
ゆるいか厳しい送信元経路(ビット4)
The Loose/Strict Source Route indicator is used when
making a forwarding decision (see Section 5.2). If this
bit is set to 1, it indicates that the next hop is a
Strict Source Route Hop. If this bit is set to 0, it
indicates that the next hop is a Loose Source Route.
推進決定をするとき、Loose/厳しいSource Routeインディケータは使用されています(セクション5.2を見てください)。 このビットが1に設定されるなら、それは、次のホップがStrict Source Route Hopであることを示します。 このビットが0に設定されるなら、それは、次のホップがLoose Source Routeであることを示します。
Probe Indicator (bit 5)
インディケータを調べてください。(ビット5)
The Probe Indicator is used by the originator of the
route to request verification of the route's feasibility
(see Sections 4 and 7.1). If this bit is set to 1, it
indicates that the originator is probing the route. This
bit should always be set to 0 for control packets.
Probe Indicatorは、ルートの実行可能性の検証を要求するのにルートの創始者によって使用されます(セクション4と7.1を見てください)。 このビットが1に設定されるなら、それは、創始者がルートを調べているのを示します。 このビットはコントロールパケットのためにいつも0に設定されるべきです。
Hop Count (1 octet)
ホップカウント(1つの八重奏)
The Hop Count field carries the maximum number of routers an
SDRP data packet may traverse. It is decremented by 1 as an
SDRP data packet traverses a router which forwards the packet
using SDRP forwarding. Once the Hop Count field reaches the
value of 0, the router should discard the data packet and
generate a control packet (see Section 5.2.6). A router that
receives a packet with a Hop Count value of 0 should discard
the data packet, and generate a control packet (see Section
5.2.6).
Hop Count分野はSDRPデータ・パケットが横断するかもしれないルータの最大数を運びます。 SDRPデータ・パケットがSDRP推進を使用することでパケットを進めるルータを横断するのに従って、それは1つ減少します。 Hop Count分野がいったん0の値に達すると、ルータは、データ・パケットを捨てて、コントロールパケットを生成するべきです(セクション5.2.6を見てください)。 0のHop Count値でパケットを受けるルータは、データ・パケットを捨てて、コントロールパケットを生成するべきです(セクション5.2.6を見てください)。
Source Route Protocol Type (1 octet)
送信元経路プロトコルタイプ(1つの八重奏)
The Source Route Protocol Type fields indicates the type of
information that appears in the source route. The value 1 in
this field indicates that the contents of the source route are
as described in this document and indicates an Explicit Source
プロトコルTypeがさばくSource Routeは送信元経路に現れる情報の種類を示します。 この分野の値1は、本書では説明されるように送信元経路の内容がそうであることを示して、Explicit Sourceを示します。
Estrin, et al Informational [Page 6] RFC 1940 SDRv1 May 1996
Estrin、他Informational[6ページ]RFC1940のSDRv1 May 1996
Route. The value 2 in this field indicates a Route Setup. The
syntax of the source route for this value is identical to a
value of 1, but also has additional semantics which are defined
in other documents.
発送します。 この分野の値2はRoute Setupを示します。 この値のための送信元経路の構文は、1の値と同じですが、他のドキュメントで定義される追加意味論をまた持っています。
Payload Protocol Type (1 octet)
有効搭載量プロトコルタイプ(1つの八重奏)
The Payload Protocol Type field indicates the protocol type of
the payload. If the payload is an IP datagram, then this field
should contain the value 1.
有効搭載量プロトコルType分野はペイロードのプロトコルタイプを示します。 ペイロードがIPデータグラムであるなら、この分野は値1を含むべきです。
Note that this Payload Protocol Type is not the same as the IP
protocol type[5,7].
この有効搭載量プロトコルTypeがIPプロトコルタイプ[5、7]と同じでないことに注意してください。
Source Route Identifier (4 octets)
送信元経路識別子(4つの八重奏)
The BR that originates the SDRP packet should insert a 32 bit
value in this field which will serve as an identifier for the
source route. This value needs to be unique only in the
context of the originating BR.
SDRPパケットを溯源するBRは送信元経路のための識別子として機能するこの分野に32ビットの値を挿入するはずです。 この値は、起因しているBRの文脈だけで特有である必要があります。
Target Router (4 octets)
目標ルータ(4つの八重奏)
This field is meaningful only in control packets.
この分野はコントロールパケットだけで重要です。
The Target Router field contains one of the IP addresses of the
router that originated the SDRP packet that triggered the
control packet to be returned.
Target Router分野は返されるコントロールパケットの引き金となったSDRPパケットを溯源したルータのIPアドレスの1つを含んでいます。
Prefix (4 octets)
接頭語(4つの八重奏)
The Prefix field contains an IP address prefix. Only the
number of bits specified in the Prefix Length are significant.
The Prefix field is used to prevent routing loops when using
BGP or IDRP to route to the next AS in a loose source route
(see Section 4).
Prefix分野はIPアドレス接頭語を含んでいます。 Prefix Lengthで指定されたビットの数だけが重要です。 Prefix分野は、ゆるい送信元経路で次のASへのルートにBGPかIDRPを使用するとき、輪を発送するのを防ぐのに使用されます(セクション4を見てください)。
Prefix Length (1 octet)
接頭語の長さ(1つの八重奏)
The Prefix Length field indicates the length in bits of the IP
address prefix. A length of zero indicates a prefix that
matches all IP addresses.
Prefix Length分野はIPアドレス接頭語のビットの長さを示します。 ゼロの長さはすべてのIPアドレスに合っている接頭語を示します。
Notification Code (1 octet)
通知コード(1つの八重奏)
This field is only meaningful in control packets. In
data packets, this field is transmitted as zero, and
should be ignored on receipt.
この分野は単にコントロールパケットで重要です。 データ・パケットでは、この野原は、ゼロとして伝えられて、領収書の上で無視されるべきです。
Estrin, et al Informational [Page 7] RFC 1940 SDRv1 May 1996
Estrin、他Informational[7ページ]RFC1940のSDRv1 May 1996
This document defines the following values for the
Notification Code:
このドキュメントはNotification Codeのために以下の値を定義します:
1 - No Route Available
1--利用可能なルートがありません。
2 - Strict Source Route Failed
2--厳しい送信元経路は失敗しました。
3 - Transit Policy Violation
3--運送保険証券違反
4 - Hop Count Exceeded
4--超えられていたホップカウント
5 - Probe Completed
終了する5--徹底的調査
6 - Unimplemented SDRP version
6--Unimplemented SDRPバージョン
7 - Unimplemented Source Route Protocol Type
7--Unimplemented送信元経路プロトコルタイプ
8 - Setup Request Rejected
8--拒絶されたセットアップ要求
Source Route Length (1 octet)
送信元経路の長さ(1つの八重奏)
The Source Route Length field indicates the length in 32 bit
words of the domain level source route carried in the SDRP
Header.
Source Route Length分野は、ドメインレベル送信元経路の32ビットの単語による長さがSDRP Headerで運ばれたのを示します。
Next Hop Pointer (1 octet)
次のホップ指針(1つの八重奏)
The Next Hop Pointer field indicates the offset of the high-
order byte of the next hop along the route that the packet has
to be forwarded. This offset is relative to the start of the
Source Route field; so if the value of the Next Hop Pointer
field equals the value of the Source Route Length field, then
the entire source route has been completely traversed. All
other source routes are said to be incompletely traversed.
Next Hop Pointer分野はパケットが送られなければならないルートに沿って次のホップの高いオーダーバイトのオフセットを示します。 このオフセットはSource Route分野の始まりに比例しています。 それで、Next Hop Pointer分野の値がSource Route Length分野の値と等しいなら、全体の送信元経路は完全に横断されました。 他のすべての送信元経路が不完全に横断されると言われています。
Source Route (variable)
送信元経路(可変)です。
The components of the source route are syntactically IP
addresses.
送信元経路の部品はシンタクス上そうです。IPアドレス。
An IP address from network 128.0.0.0 is used to encode a next
hop that is a domain. The least significant two octets contain
the DI, which is an Internet Autonomous System number.
.0が使用されているネットワーク128.0.0からのIPアドレスはドメインである次のホップをコード化します。 最も重要でない2つの八重奏がDIを含んでいます。(DIはインターネットAutonomous System番号です)。
Estrin, et al Informational [Page 8] RFC 1940 SDRv1 May 1996
Estrin、他Informational[8ページ]RFC1940のSDRv1 May 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 . 0 | D. I. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 . 0 | D。 I. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An IP address from the network 127.0.0.0 is used to encode
characteristics of the source route. The least significant
three octets are used as a Source Route Change field.
.0が使用されているネットワーク127.0.0からのIPアドレスは送信元経路の特性をコード化します。 最も重要でない3つの八重奏がSource Route Change分野として使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 127 | Source Route Change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 127 | 送信元経路変化| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Route Change (3 octets)
送信元経路変化(3つの八重奏)
Loose/Strict Source Route Change (bit 1)
ゆるいか厳しい送信元経路変化(ビット1)
The Loose/Strict Source Route Change bit reflects a new
value of the Loose/Strict Source Route bit in the SDRP
header. The value of the Loose/Strict Source Route
Change bit is copied into the Loose/Strict Source Route
bit in the SDRP header when a Source Route Change field
is encountered in processing an SDRP packet.
Loose/厳しいSource Route ChangeビットはSDRPヘッダーのLoose/厳しいSource Routeビットの新しい価値を反映します。 Source Route Change分野がSDRPパケットを処理する際に遭遇するとき、Loose/厳しいSource Route Changeビットの価値はSDRPヘッダーにLoose/厳しいSource Routeビットにコピーされます。
The rest of the Source Route Change field is transmitted as
zero, and should be ignored on receipt.
Source Route Change分野の残りは、ゼロとして伝えられて、領収書の上で無視されるべきです。
Payload (variable)
有効搭載量(可変)です。
The Payload field carries the datagram originated by the end-
system within the domain that constructed the SDRP packet. The
Payload field forms the data portion of the SDRP packet. In a
control packet this field may be empty or may carry the payload
header of the packet that triggered the control message (see
5.2.5). Note that there is no padding between the Source Route
and the Payload, and that the Payload may start at any
arbitrary octet boundary.
有効搭載量分野はSDRPパケットを組み立てたドメインの中のエンドシステムによって溯源されたデータグラムを運びます。 有効搭載量分野はSDRPパケットのデータ部を形成します。 この分野がコントロールパケットでは、空であるかもしれないか、またはコントロールメッセージの引き金となったパケットのペイロードヘッダーを運ぶかもしれない、(見る、5.2、.5、) Source Routeと有効搭載量の間でそっと歩いてはいけなくて、有効搭載量がどんな任意の八重奏境界でも始まるかもしれないことに注意してください。
Estrin, et al Informational [Page 9] RFC 1940 SDRv1 May 1996
Estrin、他Informational[9ページ]RFC1940のSDRv1 May 1996
4. Originating SDRP Data packets
4. SDRP Dataパケットを溯源します。
This document assumes that a router that originates SDRP packets is preconfigured with a set of SDRP routes. Procedures for constructing these routes are outside the scope of this document. SDRP packet forwarding may be deployed initially without additional routing protocol support.
このドキュメントは、SDRPパケットを溯源するルータが1セットのSDRPルートであらかじめ設定されると仮定します。 このドキュメントの範囲の外にこれらのルートを構成するための手順があります。 SDRPパケット推進は初めは、追加ルーティング・プロトコルサポートなしで配布されるかもしれません。
An application on a source host generates packets that must be delivered to a given destination. The packet traverses the Internet by following normal hop-by-hop routing information. An intermediate router in the path between the source host and the destination host may decide to forward some of these packets via SDRP.
送信元ホストにおけるアプリケーションは与えられた送付先に提供しなければならないパケットを生成します。 パケットは、ホップごとの正常なルーティング情報に従うことでインターネットを横断します。 送信元ホストとあて先ホストの間の経路の中間的ルータは、SDRPを通してこれらのいくつかのパケットを進めると決めるかもしれません。
When this router receives an IP datagram, the router uses the information in the datagram and the local criteria to determine whether the datagram should be forwarded along a particular SDRP route. Associated with each set of criteria is a set of one or more SDRP routes that should be used to route matching packets. The exact nature of the criteria is a local matter. The only restrictions this document places on the applicability of SDRP routes is that an IP datagram that contains a strict source route should not be forwarded along an SDRP route, that SDRP encapsulation should never be applied to an SDRP packet, and that if SDRP is used with inter-domain routes, the destination domain must also run SDRP.
このルータがIPデータグラムを受けるとき、ルータは、データグラムが特定のSDRPルートに沿って進められるべきであるかどうか決定するのにデータグラムと地方の評価基準に情報を使用します。 それぞれのセットの評価基準に関連づけられているのは、合っているパケットを発送するのに使用されるべきである1つ以上のSDRPルートのセットです。 評価基準の正確な本質は地域にかかわる事柄です。 このドキュメントがSDRPルートの適用性に関して課す唯一の制限はSDRPルートに沿って厳しい送信元経路を含むIPデータグラムを進めるべきでなくて、SDRPカプセル化がSDRPパケットに決して適用されるべきでなくて、また、SDRPが相互ドメインルートで使用されるなら、目的地ドメインがSDRPを実行しなければならないということです。
If the router decides to forward a datagram along a particular SDRP route, the router constructs the SDRP packet by placing the original datagram into the Payload field of the SDRP packet and constructing the SDRP header based on the selected SDRP route. The Next Hop pointer is set to 0 (the first entry in the Source Route field of the SDRP packet). The value of the Time To Live field in the payload header should be copied into the Hop Count field of the SDRP header.
ルータが、特定のSDRPルートに沿ってデータグラムを進めると決めるなら、ルータは、SDRPパケットの有効搭載量分野にオリジナルのデータグラムを置いて、選択されたSDRPルートに基づくSDRPヘッダーを組み立てることによって、SDRPパケットを組み立てます。 Next Hop指針は0(SDRPパケットのSource Route分野での初記入)に設定されます。 ペイロードヘッダーのTime To Live分野の値はSDRPヘッダーのHop Count分野にコピーされるべきです。
Even if we assume that interior routing is loop free, it is possible, either due to the state of inter-domain routing or due to other SDRP routers, that a domain level source route that does not terminate with the intended destination domain may lead a packet into a routing loop. Originating SDRP routers that wish to insure that this does not occur should include a final domain level hop of the destination's domain, i.e. specify the SDRP route as <DI1, DI2, DI3> instead of <DI1, DI2>, if the destination host is in domain DI3. The means for determining the DI of the destination domain is outside of the scope of this document.
私たちが、内部のルーティングには輪がないと思っても、がどちらか相互ドメインルーティングの状態のために可能であるか、または他のSDRPルータのため、ドメインが意図している目的地ドメインで終わらない送信元経路を平らにするのがパケットをルーティング輪に導くかもしれません。 SDRPルータを溯源して、これが起こらないのを保障するというその願望は目的地のドメインのドメインの最終的なレベルホップを含むべきです、すなわち、<DI1としてSDRPルートを指定してください、DI2、<DI1の代わりにDI3>、DI2>、あて先ホストがドメインDI3にいるなら。 目的地ドメインのDIを決定するための手段がこのドキュメントの範囲の外にあります。
Similarly, when using SDRP for interior routing, it is possible that the source route does not coincide with IGP routing. In this case, one means of preventing a loop is to specify the last hop router's IP
内部のルーティングにSDRPを使用するとき、同様に、送信元経路がIGPルーティングと一致していないのは、可能です。 この場合、輪を防ぐ1つの手段は最後のホップルータのIPを指定することです。
Estrin, et al Informational [Page 10] RFC 1940 SDRv1 May 1996
Estrin、他Informational[10ページ]RFC1940のSDRv1 May 1996
address as the last address within the source route. The encapsulating router can do this by specifying the source route to reach destination host IP3 as <IP1, IP2, IP3> instead of <IP1, IP2>.
送信元経路の中の最後のアドレスとしてのアドレス。 要約ルータは<IP1としてあて先ホストIP3に達するように送信元経路を指定することによって、これができます、IP2、<IP1の代わりにIP3>、IP2>。
The source address field in the delivery header should contain an IP address of the router. The value of the Don't Fragment flag of the delivery header is copied from the Don't Fragment flag of the payload header. The value of the Type Of Service field in the delivery header is copied from the Type Of Service field in the payload header. If the payload header contains an IP security option, that option is replicated as an option in the delivery header. All other IP options in the payload header must be ignored.
The source address field in the delivery header should contain an IP address of the router. The value of the Don't Fragment flag of the delivery header is copied from the Don't Fragment flag of the payload header. The value of the Type Of Service field in the delivery header is copied from the Type Of Service field in the payload header. If the payload header contains an IP security option, that option is replicated as an option in the delivery header. All other IP options in the payload header must be ignored.
If the SDRP route that is used is learned from IDRP, then the TOS corresponding to this route is copied into the TOS field in the delivery header.
If the SDRP route that is used is learned from IDRP, then the TOS corresponding to this route is copied into the TOS field in the delivery header.
The resulting SDRP packet is then forwarded as described in Section 5.2.2.
The resulting SDRP packet is then forwarded as described in Section 5.2.2.
If the encapsulating router decides to forward a datagram along a particular SDRP route that has an MTU smaller than the length of the datagram, then if the payload header has the Don't Fragment flag set to 1, the router should generate an ICMP Destination Unreachable message with a code meaning "fragmentation needed and DF set" in accordance with [6]. The ICMP message must be sent to the original source host. The router should then discard the original datagram.
If the encapsulating router decides to forward a datagram along a particular SDRP route that has an MTU smaller than the length of the datagram, then if the payload header has the Don't Fragment flag set to 1, the router should generate an ICMP Destination Unreachable message with a code meaning "fragmentation needed and DF set" in accordance with [6]. The ICMP message must be sent to the original source host. The router should then discard the original datagram.
If a router has learned an MTU for a particular SDRP route, either via ICMP messages or via configuration information, and it determines that an SDRP packet must be fragmented before transmission, then it first calculates the the effective MTU seen by the payload packet. If the effective MTU is greater than or equal to 512 bytes, the router SHOULD first fragment the payload packet using normal IP fragmentation. SDRP packets are then constructed for each fragment, as describe above. Otherwise, the router should first form the SDRP packet, and then fragment it.
If a router has learned an MTU for a particular SDRP route, either via ICMP messages or via configuration information, and it determines that an SDRP packet must be fragmented before transmission, then it first calculates the the effective MTU seen by the payload packet. If the effective MTU is greater than or equal to 512 bytes, the router SHOULD first fragment the payload packet using normal IP fragmentation. SDRP packets are then constructed for each fragment, as describe above. Otherwise, the router should first form the SDRP packet, and then fragment it.
A router may use locally originated SDRP packets to verify the feasibility of its SDRP routes. To do this the router sets the value of the Probe Indicator field in the SDRP packet to 1. Receipt of an SDRP control packet by the originating router with the "Probe Completed" Notification Code (see Section 7.1) indicates feasibility of the SDRP route. Persistent lack of SDRP control packets with the "Probe Completed" Notification Code should be used as an indication that the associated SDRP route is not feasible.
A router may use locally originated SDRP packets to verify the feasibility of its SDRP routes. To do this the router sets the value of the Probe Indicator field in the SDRP packet to 1. Receipt of an SDRP control packet by the originating router with the "Probe Completed" Notification Code (see Section 7.1) indicates feasibility of the SDRP route. Persistent lack of SDRP control packets with the "Probe Completed" Notification Code should be used as an indication that the associated SDRP route is not feasible.
Estrin, et al Informational [Page 11] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 11] RFC 1940 SDRv1 May 1996
5. Processing SDRP packets
5. Processing SDRP packets
We say that a router receives an SDRP packet if the destination address field in the delivery header of the packet arriving at the router contains one of the IP addresses of the router.
We say that a router receives an SDRP packet if the destination address field in the delivery header of the packet arriving at the router contains one of the IP addresses of the router.
When a router receives an SDRP packet, the router extracts the Source Route Protocol field from the SDRP header.
When a router receives an SDRP packet, the router extracts the Source Route Protocol field from the SDRP header.
5.1 Supporting Transit Policies
5.1 Supporting Transit Policies
A router may be able to verify that a packet that it is given to forward does not violate any of the transit policies that may exist, of the domain to which the router belongs. Specific verification mechanisms are a matter that is local to the router and are outside the scope of this document.
A router may be able to verify that a packet that it is given to forward does not violate any of the transit policies that may exist, of the domain to which the router belongs. Specific verification mechanisms are a matter that is local to the router and are outside the scope of this document.
The restriction on the verification mechanisms is that they may take into account only the contents of the SDRP header, the payload header, and transport protocol header of the payload packet.
The restriction on the verification mechanisms is that they may take into account only the contents of the SDRP header, the payload header, and transport protocol header of the payload packet.
With SDRP a domain may enforce its transit policies by applying filters based on the information present in the IP Header. For example a router may initially carefully filter all SDRP traffic from all possible sources. A filter that allows certain SDRP traffic from selected sources to pass through the router could then be installed dynamically to pass similar types of traffic. Thus, by caching appropriate filtering information, a transit domain can efficiently support transit policies. Other mechanisms for supporting transit policy and implementation techniques are not precluded by this document.
With SDRP a domain may enforce its transit policies by applying filters based on the information present in the IP Header. For example a router may initially carefully filter all SDRP traffic from all possible sources. A filter that allows certain SDRP traffic from selected sources to pass through the router could then be installed dynamically to pass similar types of traffic. Thus, by caching appropriate filtering information, a transit domain can efficiently support transit policies. Other mechanisms for supporting transit policy and implementation techniques are not precluded by this document.
If the router detects that the SDRP packet violates a domain's transit policy it sends back an SDRP control packet to the encapsulating router and discards the violating packet.
If the router detects that the SDRP packet violates a domain's transit policy it sends back an SDRP control packet to the encapsulating router and discards the violating packet.
SDRP control packets are not subject to transit policies.
SDRP control packets are not subject to transit policies.
If a router does not discard an SDRP packet due to a transit policy violation, then the router attempts to forward it as specified in Section 5.2.
If a router does not discard an SDRP packet due to a transit policy violation, then the router attempts to forward it as specified in Section 5.2.
5.2 Forwarding SDRP packets
5.2 Forwarding SDRP packets
Procedures for forwarding of an SDRP packet depend on
Procedures for forwarding of an SDRP packet depend on
a) whether the router has the routing information needed to
forward the packet;
a) whether the router has the routing information needed to forward the packet;
Estrin, et al Informational [Page 12] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 12] RFC 1940 SDRv1 May 1996
b) whether the SDRP route has been completely traversed;
c) whether the SDRP route is strict or loose, and
d) whether the packet is a data or control packet.
b) whether the SDRP route has been completely traversed; c) whether the SDRP route is strict or loose, and d) whether the packet is a data or control packet.
When forwarding an SDRP packet (either data or control) a router should not modify the following fields in the delivery header:
When forwarding an SDRP packet (either data or control) a router should not modify the following fields in the delivery header:
a) Source Address
b) Don't Fragment flag
a) Source Address b) Don't Fragment flag
If the Source Route Protocol Type of a packet indicates a Route Setup and the router does not or cannot support setup, the router MAY send the encapsulating router a control packet with a Notification Code of Setup Request Rejected. It MAY then modify the data packet so that the Source Route Protocol Type is Explicit Source Route and the Probe Indicator bit is 0, then forwards the packet as described below. The router MAY send notification of a failed setup request only periodically. Alternately, a router MAY silently drop the Route Setup packet.
If the Source Route Protocol Type of a packet indicates a Route Setup and the router does not or cannot support setup, the router MAY send the encapsulating router a control packet with a Notification Code of Setup Request Rejected. It MAY then modify the data packet so that the Source Route Protocol Type is Explicit Source Route and the Probe Indicator bit is 0, then forwards the packet as described below. The router MAY send notification of a failed setup request only periodically. Alternately, a router MAY silently drop the Route Setup packet.
5.2.1 Forwarding algorithm pseudo-code
5.2.1 Forwarding algorithm pseudo-code
The following pseudo-code gives an overview of the SDRP forwarding algorithm. Please consult the text below for more details.
The following pseudo-code gives an overview of the SDRP forwarding algorithm. Please consult the text below for more details.
Let LOCAL_DI be the DI of the domain of the local system, let NEXT_HOP be the next hop in the source route if the source route has not been completely traversed, let NEXT_DI be the DI portion of NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER be the IP address of the next router if the packet is to be forwarded using SDRP. We say that NEXT_DI is adjacent if the local domain is adjacent to the domain that has NEXT_DI as its DI, and we say that NEXT_ROUTER is adjacent if it represents an IP address of a router that shares a link with the current router. Normal IP forwarding refers to forwarding that can be accomplished using FIBs constructed via BGP, IDRP or one or more IGPs.
Let LOCAL_DI be the DI of the domain of the local system, let NEXT_HOP be the next hop in the source route if the source route has not been completely traversed, let NEXT_DI be the DI portion of NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER be the IP address of the next router if the packet is to be forwarded using SDRP. We say that NEXT_DI is adjacent if the local domain is adjacent to the domain that has NEXT_DI as its DI, and we say that NEXT_ROUTER is adjacent if it represents an IP address of a router that shares a link with the current router. Normal IP forwarding refers to forwarding that can be accomplished using FIBs constructed via BGP, IDRP or one or more IGPs.
The pseudo code requires sending control messages in a number of places. All such control messages must be sent to the encapsulating router, which is indicated in the source address of the delivery header. Note too that all intermediate SDRP routers that process an SDRP packet must ensure that the source address of the delivery header is left untouched, since this source address is the address of the encapsulating router to which any control messages must be sent.
The pseudo code requires sending control messages in a number of places. All such control messages must be sent to the encapsulating router, which is indicated in the source address of the delivery header. Note too that all intermediate SDRP routers that process an SDRP packet must ensure that the source address of the delivery header is left untouched, since this source address is the address of the encapsulating router to which any control messages must be sent.
Estrin, et al Informational [Page 13] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 13] RFC 1940 SDRv1 May 1996
if the packet is a control packet begin
if the Target Router equals an address assigned to the
local router begin
remove the delivery header
process information carried in the control packet
return
end if
if the packet can be forwarded using normal IP forwarding begin
set Next Hop Pointer to Source Route Length
forward the packet using normal IP forwarding
return
end if
end if
if the packet is a control packet begin if the Target Router equals an address assigned to the local router begin remove the delivery header process information carried in the control packet return end if if the packet can be forwarded using normal IP forwarding begin set Next Hop Pointer to Source Route Length forward the packet using normal IP forwarding return end if end if
if the version field is not 1 begin
if the packet is a data packet begin
generate a control packet with "Unimplemented SDRP version"
end if
discard the packet
return
end if
if the version field is not 1 begin if the packet is a data packet begin generate a control packet with "Unimplemented SDRP version" end if discard the packet return end if
if the source route protocol type is not 1 begin
if the packet is a data packet begin
generate a control packet with "Unimplemented source route
protocol type"
end if
discard the packet
return
end if
if the source route protocol type is not 1 begin if the packet is a data packet begin generate a control packet with "Unimplemented source route protocol type" end if discard the packet return end if
if the Hop Count field is greater than 0 begin
decrement the Hop Count field
end if
if the Hop Count field is 0 begin
if the packet is a data packet begin
generate a control packet with "Hop Count Exceeded"
end if
discard the packet
return
end if
if the Hop Count field is greater than 0 begin decrement the Hop Count field end if if the Hop Count field is 0 begin if the packet is a data packet begin generate a control packet with "Hop Count Exceeded" end if discard the packet return end if
if the packet is a data packet begin
if the packet violates transit policy begin
generate a control packet with "Transit Policy Violation"
if the packet is a data packet begin if the packet violates transit policy begin generate a control packet with "Transit Policy Violation"
Estrin, et al Informational [Page 14] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 14] RFC 1940 SDRv1 May 1996
discard the data packet
return
end if
end if
discard the data packet return end if end if
set mode to NONE
set advanced to FALSE
if Next Hop Ptr does not equal Source Route Length begin
set NEXT_HOP to the next hop in the source route
while mode equals NONE begin
if NEXT_HOP is from network 127.0.0.0 begin
set the Loose/Strict Source Route bit equal to
the Loose/Strict Source Route Change bit
else if NEXT_HOP is from network 128.0.0.0 begin
set NEXT_DI to the least significant two octets of NEXT_HOP
if NEXT_DI is not equal to LOCAL_DI begin
set mode to DOMAIN
end if
else if NEXT_HOP does not equal an address assigned to the
local router begin
set mode to LOCAL
end if
if mode equals NONE begin
set advanced to TRUE
increment the Next Hop Pointer field
if Next Hop Pointer equals Source Route Length begin
set mode to COMPLETE
else
set NEXT_HOP to the next hop in the source route
end if
end if
end while
end if
set mode to NONE set advanced to FALSE if Next Hop Ptr does not equal Source Route Length begin set NEXT_HOP to the next hop in the source route while mode equals NONE begin if NEXT_HOP is from network 127.0.0.0 begin set the Loose/Strict Source Route bit equal to the Loose/Strict Source Route Change bit else if NEXT_HOP is from network 128.0.0.0 begin set NEXT_DI to the least significant two octets of NEXT_HOP if NEXT_DI is not equal to LOCAL_DI begin set mode to DOMAIN end if else if NEXT_HOP does not equal an address assigned to the local router begin set mode to LOCAL end if if mode equals NONE begin set advanced to TRUE increment the Next Hop Pointer field if Next Hop Pointer equals Source Route Length begin set mode to COMPLETE else set NEXT_HOP to the next hop in the source route end if end if end while end if
if mode equals DOMAIN begin
set route to NONE
if the source route is loose begin
if not advanced begin
find the route, if any, based on Prefix and Prefix Length
if the route is an aggregate formed at the local router begin
set route to NONE
end if
end if
if route equals NONE begin
select a BGP or IDRP route, if any, with a path that includes
NEXT_DI and is not an aggregate formed at the local router
if route equals NONE begin
if mode equals DOMAIN begin set route to NONE if the source route is loose begin if not advanced begin find the route, if any, based on Prefix and Prefix Length if the route is an aggregate formed at the local router begin set route to NONE end if end if if route equals NONE begin select a BGP or IDRP route, if any, with a path that includes NEXT_DI and is not an aggregate formed at the local router if route equals NONE begin
Estrin, et al Informational [Page 15] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 15] RFC 1940 SDRv1 May 1996
if the packet is a data packet begin
generate a control packet with "No Route Available"
end if
discard the packet
return
end if
copy the NLRI from the route to the Prefix and Prefix Length
end if
if the route is an IDRP route begin
set appropriate TOS in delivery header
end if
set NEXT_ROUTER from the route
else
set NEXT_ROUTER from the routing information for NEXT_DI
using the D-FIB
if route equals NONE begin
if the packet is a data packet begin
generate a control packet with "No Route Available"
end if
discard the packet
return
end if
if NEXT_DI is not adjacent begin
if the packet is a data packet begin
generate a control packet with "Strict Source Route Failed"
end if
discard the packet
return
end if
end if
end if
end if
if the packet is a data packet begin generate a control packet with "No Route Available" end if discard the packet return end if copy the NLRI from the route to the Prefix and Prefix Length end if if the route is an IDRP route begin set appropriate TOS in delivery header end if set NEXT_ROUTER from the route else set NEXT_ROUTER from the routing information for NEXT_DI using the D-FIB if route equals NONE begin if the packet is a data packet begin generate a control packet with "No Route Available" end if discard the packet return end if if NEXT_DI is not adjacent begin if the packet is a data packet begin generate a control packet with "Strict Source Route Failed" end if discard the packet return end if end if end if end if
if mode equals LOCAL begin
set NEXT_ROUTER equal to NEXT_HOP
if the source route is strict and NEXT_ROUTER is not
adjacent begin
if the packet is a data packet begin
generate a control packet with "Strict Source Route Failed"
end if
discard the packet
return
end if
end if
if mode equals LOCAL begin set NEXT_ROUTER equal to NEXT_HOP if the source route is strict and NEXT_ROUTER is not adjacent begin if the packet is a data packet begin generate a control packet with "Strict Source Route Failed" end if discard the packet return end if end if
if mode equals LOCAL or mode equals DOMAIN begin
set the destination address of the delivery header equal
if mode equals LOCAL or mode equals DOMAIN begin set the destination address of the delivery header equal
Estrin, et al Informational [Page 16] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 16] RFC 1940 SDRv1 May 1996
to NEXT_ROUTER
checksum the delivery header
route packet to NEXT_ROUTER using normal IP forwarding
return
end if
to NEXT_ROUTER checksum the delivery header route packet to NEXT_ROUTER using normal IP forwarding return end if
if the packet is a control packet begin
discard the packet
end if
remove the delivery header and the SDRP Header
if there is no normal IP route to the payload destination begin
generate a control packet with "No Route Available"
discard the data packet
return
end if
forward the payload using normal IP forwarding
if the probe bit is set begin
generate a control packet with "Probe Completed"
end if
if the packet is a control packet begin discard the packet end if remove the delivery header and the SDRP Header if there is no normal IP route to the payload destination begin generate a control packet with "No Route Available" discard the data packet return end if forward the payload using normal IP forwarding if the probe bit is set begin generate a control packet with "Probe Completed" end if
5.2.2 Handling an SDRP control packet.
5.2.2 Handling an SDRP control packet.
An SDRP control packet is indicated by 0 in the Data packet/Control packet bit in the Flags field in the SDRP Header.
An SDRP control packet is indicated by 0 in the Data packet/Control packet bit in the Flags field in the SDRP Header.
If the Target Router field of the received SDRP packet contains an IP address that is assigned to the router that received this SDRP packet, then the router should use the information carried in the Notification Code field, the Source Route Identifier field and the information carried in the Payload field to update the status of its SDRP routes. Details of such procedures are described in Section 7.
If the Target Router field of the received SDRP packet contains an IP address that is assigned to the router that received this SDRP packet, then the router should use the information carried in the Notification Code field, the Source Route Identifier field and the information carried in the Payload field to update the status of its SDRP routes. Details of such procedures are described in Section 7.
Otherwise, the router checks whether it can forward the packet to the router specified in the Target Router field by using the routing information present in its local FIB. If forwarding is possible then the local system sets the destination address of the delivery header to the address specified in the Target Router field, and hands the packet off for normal IP forwarding. If normal IP forwarding is impossible then the packet may be forwarded in the same manner as an SDRP data packet (described below) but with the following exceptions.
Otherwise, the router checks whether it can forward the packet to the router specified in the Target Router field by using the routing information present in its local FIB. If forwarding is possible then the local system sets the destination address of the delivery header to the address specified in the Target Router field, and hands the packet off for normal IP forwarding. If normal IP forwarding is impossible then the packet may be forwarded in the same manner as an SDRP data packet (described below) but with the following exceptions.
- Control packets are not subject to transit policies.
- In no case should a control packet be generated in response to
an error caused by a control packet.
- If the source route is completely traversed and the packet still
cannot be forwarded via normal IP routing, the packet should be
silently dropped.
- Control packets are not subject to transit policies. - In no case should a control packet be generated in response to an error caused by a control packet. - If the source route is completely traversed and the packet still cannot be forwarded via normal IP routing, the packet should be silently dropped.
Estrin, et al Informational [Page 17] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 17] RFC 1940 SDRv1 May 1996
5.2.3 Handling an SDRP data packet.
5.2.3 Handling an SDRP data packet.
An SDRP data packet is indicated by a one in the Data packet/Control packet bit in the Flags field in the SDRP Header.
An SDRP data packet is indicated by a one in the Data packet/Control packet bit in the Flags field in the SDRP Header.
An SDRP data packet is forwarded by sending the packet along the source route in the SDRP Header. When the source route is completely traversed and the packet has reached the destination domain, the payload may be removed from the data packet and forwarded normally. Further details are described below.
An SDRP data packet is forwarded by sending the packet along the source route in the SDRP Header. When the source route is completely traversed and the packet has reached the destination domain, the payload may be removed from the data packet and forwarded normally. Further details are described below.
5.2.4 Checking the SDRP version number
5.2.4 Checking the SDRP version number
An SDRP packet that has a version number other than 1 should be discarded. If the SDRP packet was a data packet, then a control packet with the Notification Code "Unimplemented SDRP version" should be generated as specified in section 6.
An SDRP packet that has a version number other than 1 should be discarded. If the SDRP packet was a data packet, then a control packet with the Notification Code "Unimplemented SDRP version" should be generated as specified in section 6.
5.2.5 Checking the Source Route Protocol Type
5.2.5 Checking the Source Route Protocol Type
This document describes Source Route Protocol Type 1. An SDRP router may support multiple Source Route Protocol Types; however an SDRP router is NOT required to support all defined Source Route Types. Any packet that has a Source Route Protocol Type which is not supported should be discarded. If the SDRP packet was a data packet, then a control packet with the Notification Code "Unimplemented Source Route Protocol Type" should be generated as specified in section 6.
This document describes Source Route Protocol Type 1. An SDRP router may support multiple Source Route Protocol Types; however an SDRP router is NOT required to support all defined Source Route Types. Any packet that has a Source Route Protocol Type which is not supported should be discarded. If the SDRP packet was a data packet, then a control packet with the Notification Code "Unimplemented Source Route Protocol Type" should be generated as specified in section 6.
5.2.6 Decrementing and checking Hop Count
5.2.6 Decrementing and checking Hop Count
If an SDRP packet is to be forwarded and the Hop Count field is non- zero, the Hop Count field should be decremented. If the resulting value is zero and the packet was a data packet, then a control packet with the Notification Code "Hop Count Exceeded" should be generated and sent to the encapsulating router as specified in section 6, and the packet should be discarded. If the resulting value is zero and the packet was a control packet, the packet should be discarded. The payload of the control packet should carry the payload header followed by 64 bits of the payload data of the data packet.
If an SDRP packet is to be forwarded and the Hop Count field is non- zero, the Hop Count field should be decremented. If the resulting value is zero and the packet was a data packet, then a control packet with the Notification Code "Hop Count Exceeded" should be generated and sent to the encapsulating router as specified in section 6, and the packet should be discarded. If the resulting value is zero and the packet was a control packet, the packet should be discarded. The payload of the control packet should carry the payload header followed by 64 bits of the payload data of the data packet.
5.2.7 Upholding transit policies
5.2.7 Upholding transit policies
It is not a goal of SDRP to create a security routing system. Therefore, we need to qualify our use of the term "upholding transit policy". It is assumed that transit policies have the nature of a "gentleperson's agreement", and are upheld by all the participants. In other words, it is assumed that there will be no malicious
It is not a goal of SDRP to create a security routing system. Therefore, we need to qualify our use of the term "upholding transit policy". It is assumed that transit policies have the nature of a "gentleperson's agreement", and are upheld by all the participants. In other words, it is assumed that there will be no malicious
Estrin, et al Informational [Page 18] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 18] RFC 1940 SDRv1 May 1996
attempts to violate transit policies and that parties will rely on auditing and post facto detection of violations. When a security architecture is developed for IP or other network protocols then it may be applied to increase the assurance of transit policy enforcement. These issues are beyond the scope of this document.
attempts to violate transit policies and that parties will rely on auditing and post facto detection of violations. When a security architecture is developed for IP or other network protocols then it may be applied to increase the assurance of transit policy enforcement. These issues are beyond the scope of this document.
A router may examine any data packet to verify if it complies with local transit policies, as described in section 5.1. If the verification fails, the router generates a control packet. If the verification referred to only the contents of the SDRP header, then the payload field of the control packet should be empty. If the verification referred to both the contents of the SDRP header and the payload header, then the payload field of the control packet should carry the payload header. If the verification referred to the transport protocol header, then the payload field of the control packet should carry the payload header and the transport header.
A router may examine any data packet to verify if it complies with local transit policies, as described in section 5.1. If the verification fails, the router generates a control packet. If the verification referred to only the contents of the SDRP header, then the payload field of the control packet should be empty. If the verification referred to both the contents of the SDRP header and the payload header, then the payload field of the control packet should carry the payload header. If the verification referred to the transport protocol header, then the payload field of the control packet should carry the payload header and the transport header.
The Notification Code field of the SDRP header in the control packet is set to Transit Policy Violation. The procedures for constructing the rest of the SDRP Header of the control packet are specified in Section 6.
The Notification Code field of the SDRP header in the control packet is set to Transit Policy Violation. The procedures for constructing the rest of the SDRP Header of the control packet are specified in Section 6.
5.2.8 Partially traversed source routes
5.2.8 Partially traversed source routes
If a router receives an SDRP packet with a partially traversed source route, it extracts the next hop of the source route from the Source Route field. The router locates the high-order byte of the appropriate hop by using the Next Hop Pointer field as a 32 bit word offset relative to the start of the Source Route field. The next hop is always four octets long. The following procedure is used to interpret the next hop.
If a router receives an SDRP packet with a partially traversed source route, it extracts the next hop of the source route from the Source Route field. The router locates the high-order byte of the appropriate hop by using the Next Hop Pointer field as a 32 bit word offset relative to the start of the Source Route field. The next hop is always four octets long. The following procedure is used to interpret the next hop.
Syntactically, each element in the source route appears as an IP address. There are three encodings for the next hop:
Syntactically, each element in the source route appears as an IP address. There are three encodings for the next hop:
a) The next hop is an address in network 127.0.0.0. In this case, the Loose/Strict Source Route field is set equal to the Loose/Strict Source Route Change bit. Then the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases are examined again.
a) The next hop is an address in network 127.0.0.0. In this case, the Loose/Strict Source Route field is set equal to the Loose/Strict Source Route Change bit. Then the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases are examined again.
b) The next hop is an address in network 128.0.0.0. In this case, the DI of the next domain is extracted from the least significant two octets of the next hop. If the extracted DI is the same as the DI of the local domain, then the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases are examined again. Otherwise, if the extracted DI is different from the DI of the local domain, the next hop is the extracted DI, and the
b) The next hop is an address in network 128.0.0.0. In this case, the DI of the next domain is extracted from the least significant two octets of the next hop. If the extracted DI is the same as the DI of the local domain, then the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases are examined again. Otherwise, if the extracted DI is different from the DI of the local domain, the next hop is the extracted DI, and the
Estrin, et al Informational [Page 19] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 19] RFC 1940 SDRv1 May 1996
forwarding process may proceed.
forwarding process may proceed.
c) The next hop is any other IP address. If the next hop is equal to any IP address assigned to the local router, the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases examined again. Otherwise, the next hop is the IP address of the next router in the source route and the forwarding process may proceed.
c) The next hop is any other IP address. If the next hop is equal to any IP address assigned to the local router, the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases examined again. Otherwise, the next hop is the IP address of the next router in the source route and the forwarding process may proceed.
The above procedure for interpreting the next hop in the source route finishes when the next hop is either a router other than the local router or an encoded DI that is not the local DI or a completed source route.
The above procedure for interpreting the next hop in the source route finishes when the next hop is either a router other than the local router or an encoded DI that is not the local DI or a completed source route.
If upon termination of this procedure the source route is completely traversed, see section 5.2.9.
If upon termination of this procedure the source route is completely traversed, see section 5.2.9.
5.2.8.1 Finding a route to the next hop
5.2.8.1 Finding a route to the next hop
If the next hop is not a DI, then the destination address in the delivery header is replaced by the next hop address and the resulting packet can then be forwarded using normal IP forwarding. Otherwise, a DI was extracted from the next hop in the source route, and the following procedure is used to find a route to the next domain.
If the next hop is not a DI, then the destination address in the delivery header is replaced by the next hop address and the resulting packet can then be forwarded using normal IP forwarding. Otherwise, a DI was extracted from the next hop in the source route, and the following procedure is used to find a route to the next domain.
Given the DI of the next domain, the router next consults its D-FIB. If no entry exists in the D-FIB for the next domain, then the packet should be discarded. If the packet was a data packet, a control message with Notification Code "No Route Available" should be generated as specified in Section 6. No other actions are necessary.
Given the DI of the next domain, the router next consults its D-FIB. If no entry exists in the D-FIB for the next domain, then the packet should be discarded. If the packet was a data packet, a control message with Notification Code "No Route Available" should be generated as specified in Section 6. No other actions are necessary.
If there is a D-FIB entry, the router next examines the SDRP header to determine if the packet specified a strict source route. If so, and the next domain is not adjacent to the local domain, then a control packet with the Notification Code "Strict Source Route Failed" should be generated, as specified in section 6, and the original packet should be discarded. No other actions are necessary.
If there is a D-FIB entry, the router next examines the SDRP header to determine if the packet specified a strict source route. If so, and the next domain is not adjacent to the local domain, then a control packet with the Notification Code "Strict Source Route Failed" should be generated, as specified in section 6, and the original packet should be discarded. No other actions are necessary.
If source route is loose, then BGP or IDRP information must be used to insure that there is no loop in reaching the next hop. If the Next Hop Pointer was incremented when determining the next hop, then the router must select a BGP or IDRP route with a path that includes the extracted DI, and the NLRI for this route is copied into the Prefix Length and Prefix fields.
If source route is loose, then BGP or IDRP information must be used to insure that there is no loop in reaching the next hop. If the Next Hop Pointer was incremented when determining the next hop, then the router must select a BGP or IDRP route with a path that includes the extracted DI, and the NLRI for this route is copied into the Prefix Length and Prefix fields.
Otherwise, the Next Hop Pointer was not incremented, and the router should use the information carried in the Prefix and Prefix Length as an index into its BGP or IDRP routing table. If it finds a matching
Otherwise, the Next Hop Pointer was not incremented, and the router should use the information carried in the Prefix and Prefix Length as an index into its BGP or IDRP routing table. If it finds a matching
Estrin, et al Informational [Page 20] RFC 1940 SDRv1 May 1996
Estrin, et al Informational [Page 20] RFC 1940 SDRv1 May 1996
route then it must select the corresponding D-FIB entry. If the route was formed locally by aggregation, then the router must consult its D-FIB and select any route with a path that includes the extracted DI. The NLRI for this route should be copied into the Prefix Length and Prefix fields.
route then it must select the corresponding D-FIB entry. If the route was formed locally by aggregation, then the router must consult its D-FIB and select any route with a path that includes the extracted DI. The NLRI for this route should be copied into the Prefix Length and Prefix fields.
In either case, the D-FIB entry includes the IP address of the next SDRP-speaking router to which the SDRP packet should be routed. The destination address in the delivery header is replaced by this address. The resulting packet can then be forwarded using normal IP forwarding.
In either case, the D-FIB entry includes the IP address of the next SDRP-speaking router to which the SDRP packet should be routed. The destination address in the delivery header is replaced by this address. The resulting packet can then be forwarded using normal IP forwarding.
5.2.8.2 Last Hop Optimization
5.2.8.2 Last Hop Optimization
A small optimization can be performed if there is only a single DI or IP address in the source route that has not been traversed.
A small optimization can be performed if there is only a single DI or IP address in the source route that has not been traversed.
In this case, if the next hop in the SDRP route is a DI, that DI is adjacent to the router processing this packet, the route has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent domain, then the source route may be considered completely traversed and processing may proceed as in section 5.2.9.
In this case, if the next hop in the SDRP route is a DI, that DI is adjacent to the router processing this packet, the route has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent domain, then the source route may be considered completely traversed and processing may proceed as in section 5.2.9.
If the next hop in the SDRP route is an IP address, that IP address is adjacent to the router processing this packet, the router has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent IP address, then the source route may be considered completely traversed and processing may proceed as in section 5.2.9.
If the next hop in the SDRP route is an IP address, that IP address is adjacent to the router processing this packet, the router has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent IP address, then the source route may be considered completely traversed and processing may proceed as in section 5.2.9.
Since the last hop optimization may only be done if the last hop is directly adjacent, and reachable, it is irrelevant whether the SDRP route specifies that this is a strict source route or a loose source route hop.
Since the last hop optimization may only be done if the last hop is directly adjacent, and reachable, it is irrelevant whether the SDRP route specifies that this is a strict source route or a loose source route hop.
5.2.9 Completely Traversed source routes
5.2.9 Completely Traversed source routes
If the SDRP packet received by a router with a completely-traversed source route is a control packet and if the Target Router field carries an IP address assigned to the router, then the packet should be processed as specified in Section 7. Otherwise, if the SDRP packet is a control packet, and the packet cannot be forwarded via either SDRP or normal IP forwarding, the packet should be silently dropped.
ルータによって完全に横断された送信元経路で受け取られたSDRPパケットがコントロールパケットであり、Target Router分野がルータに割り当てられたIPアドレスを運ぶなら、パケットはセクション7で指定されるように処理されるべきです。 さもなければ、SDRPパケットがコントロールパケットであり、SDRPか通常のIP推進のどちらかでパケットを進めることができないなら、パケットは静かに落とされるべきです。
The Hop Count field has already been decremented when processing the SDRP header. The Hop Count field should now be copied from the SDRP
SDRPヘッダーを処理するとき、Hop Count分野は既に減少しました。 Hop Count分野は現在、SDRPからコピーされるべきです。
Estrin, et al Informational [Page 21] RFC 1940 SDRv1 May 1996
Estrin、他Informational[21ページ]RFC1940のSDRv1 May 1996
header into the IP TTL field in the payload header. The resulting payload packet is then forwarded using normal IP forwarding. If there is no FIB entry for the destination, then the packet should be discarded and a control message with Notification Code "No Route Available" should be generated as specified in Section 6. If the packet can be forwarded and if the Probe Indication bit is set to one in the SDRP header, then a control message with Notification Code "Probe Completed" should be generated as specified in section 6. If a control packet is generated, then it must be sent to the encapsulating router. The payload of the control packet should carry the first 64 bits of the SDRP header and the payload header.
ペイロードヘッダーのIP TTL分野へのヘッダー。 そして、通常のIP推進を使用することで結果として起こるペイロードパケットを進めます。 目的地のためのFIBエントリーが全くなければ、パケットは捨てられるべきです、そして、「利用可能なルートがありません」というNotification Codeがあるコントロールメッセージはセクション6で指定されるように発生するべきです。 パケットを送ることができて、SDRPヘッダーの1つにProbe Indicationビットを設定するなら、セクション6で指定されるように「終了する徹底的調査」というNotification Codeがあるコントロールメッセージを発生させるべきです。 コントロールパケットを発生させるなら、要約ルータにそれを送らなければなりません。 コントロールパケットのペイロードはSDRPヘッダーの最初の64ビットとペイロードヘッダーを運ぶはずです。
6. Originating SDRP control packets
6. 由来しているSDRPコントロールパケット
A router sends a control packet in response to either error conditions, or to successful completion of a probe request (indicated via Probe Indication in the Flags field).
ルータはエラー条件に対応した徹底的調査要求(Flags分野のProbe Indicationを通して、示される)の無事終了にコントロールパケットを送ります。
The Data Packet/Control Packet field is set to indicate Control Packet. The following fields are copied from the SDRP header of the Data packet that caused the generation of the Control packet:
Data Packet/コントロールPacket分野がControl Packetを示すように設定されます。 以下の分野はControlパケットの世代を引き起こしたDataパケットのSDRPヘッダーからコピーされます:
- Loose/Strict Source Route
- Source Route Protocol Type
- Source Route Identifier
- Source Route Length field
- Payload Protocol Type
- ゆるいか厳しいSource Route--Type--ソースRoute Identifier--ソースRoute LengthがさばくソースRouteプロトコル--有効搭載量プロトコルType
A Control packet should not carry a Probe Indication field.
ControlパケットはProbe Indication野原を運ぶはずがありません。
A router should never originate a Control packet as the result of an error caused by a control packet.
ルータはコントロールパケットによって引き起こされた誤りの結果としてControlパケットを決して溯源するべきではありません。
The Target Router is copied from the source IP address of the delivery header of the SDRP Data packet. This causes the control packet to be returned to the encapsulating router.
Target RouterはSDRP Dataパケットの配送ヘッダーのソースIPアドレスからコピーされます。 これで、コントロールパケットを要約ルータに返します。
The router generating a control packet checks its FIB for a route to the destination depicted by the Target Router field. If such a route is present, then the value of the Destination Address field in the delivery header is set to the Target Router, the Source Address field in the delivery header is set to the IP address of one of the interfaces attached to the local system, and the packet is forwarded via normal IP forwarding.
コントロールパケットを発生させるルータはルートがないかどうかTarget Router分野によって表現された目的地にFIBをチェックします。 そのようなルートが存在しているなら、配送ヘッダーのDestination Address分野の値をTarget Routerに設定します、そして、ローカルシステムに付けられたインタフェースの1つのIPアドレスに配送ヘッダーのSource Address分野を設定します、そして、通常のIP推進でパケットを送ります。
If the FIB does not have a route to the destination depicted by the Target Router field, the local system constructs the Source Route field of the Control packet by reversing the SDRP route carried in
FIBがTarget Router分野で目的地へのルートを表現させないなら、Source RouteがさばくSDRPルートを逆にするのによるControlパケットのローカルシステム構造物は運び込みました。
Estrin, et al Informational [Page 22] RFC 1940 SDRv1 May 1996
Estrin、他Informational[22ページ]RFC1940のSDRv1 May 1996
the Source Route field of the Data packet, sets the value of the Next Hop Pointer to the value of the Source Route Length field minus the value of the Next Hop Pointer field of the SDRP data packet that caused generation of the Control Packet. All Loose/Strict Source Route change bits in the new source route should be set to 0 (loose source route).
Dataパケット(Source Route Lengthの値へのNext Hop Pointerの値がControl Packetの世代を引き起こしたSDRPデータ・パケットのNext Hop Pointer分野の値を引いてさばくセット)のSource Route分野。 新しい送信元経路によるすべてのLoose/厳しいSource Route変更ビットが0(ゆるい送信元経路)に設定されるべきです。
The contents of the Payload field depends on the reason for generating a control packet.
有効搭載量分野のコンテンツはコントロールパケットを発生させる理由によります。
The resulting packet is then handled via SDRP Forwarding procedures described in Section 5.2.
そして、結果として起こるパケットはセクション5.2で説明されたSDRP Forwarding手順で扱われます。
7. Processing control information
7. 処理制御情報
A router participating in SDRP may receive control information in two forms, SDRP control packets from other routers and ICMP messages from routers that do not participate in SDRP, but are involved in forwarding SDRP packets.
SDRPに参加するルータは2個の用紙と他のルータからのSDRPコントロールパケットとSDRPに参加しませんが、推進SDRPパケットにかかわるルータからのICMPメッセージの制御情報を受け取るかもしれません。
7.1 Processing SDRP control packets
7.1 処理SDRPコントロールパケット
Most control packets carry information about some SDRP routes used by the router. To correlate information carried in the SDRP control packet with the SDRP routes used by the router, the router uses information carried in the SDRP header of the control packet, and optionally in the SDRP payload of the control packet (if present).
ほとんどのコントロールパケットがルータによって使用されるいくつかのSDRPルートの情報を運びます。 相関物情報に、ルートがルータ、情報がコントロールパケットのSDRPヘッダーに、任意に運んだルータ用途で中のSDRPを使用していた状態で、コントロールパケットのSDRPペイロードはSDRPコントロールパケットで運ばれていました(存在しているなら)。
In general, receipt of any SDRP control packet that carries one of the following Notification codes
一般に、どんなSDRPの領収書も以下のNotificationコードの1つを運ぶパケットを制御します。
- No Route Available
- 利用可能なルートがありません。
- Strict Source Route Failed
- 厳しい送信元経路は失敗しました。
- Unimplemented SDRP Version
- Unimplemented SDRPバージョン
- Unimplemented Source Route Probe Type
- 送信元経路徹底的調査タイプをUnimplementedしました。
indicates that the corresponding SDRP route is presently not feasible, and thus should not be used for packet forwarding. The router must mark the affected routes as not feasible, and may use alternate routes if available.
対応するSDRPルートが現在可能でないことを示して、その結果、パケット推進に使用するべきではありません。 ルータは、可能でないとして影響を受けるルートをマークしなければならなくて、利用可能であるなら、代替経路を使用するかもしれません。
The router may at some later point attempt to use an SDRP route that was marked as infeasible. The criteria used for retrying routes is outside the scope of this document and a subject of further study. It need not be standardizes and can be a matter of local control.
ルータは実行不可能であるとしてマークされたSDRPルートを使用する何らかの後のポイント試みのときにそうするかもしれません。 このドキュメントの範囲とさらなる研究の対象の外にルートを再試行するのに使用される評価基準があります。 それがそうである必要はない、標準化、現場制御の問題はそうであることができます。
Estrin, et al Informational [Page 23] RFC 1940 SDRv1 May 1996
Estrin、他Informational[23ページ]RFC1940のSDRv1 May 1996
Receipt of an SDRP control packet that carries "Probe Completed" Notification code indicates that the corresponding SDRP route is feasible.
「徹底的調査完成した」Notificationコードを運ぶSDRPコントロールパケットの領収書は、対応するSDRPルートが可能であることを示します。
Receipt of an SDRP control packet that carries the "Transit Policy Violation" Notification Code shall be interpreted as follows:
「運送保険証券違反」Notification Codeを運ぶSDRPコントロールパケットの領収書は以下の通り解釈されるものとします:
- If the control packet carries no payload data then the
corresponding SDRP route violates transit policy regardless of
the content of the payload packet carried along that route.
- If the control packet carries only the payload header, then
the corresponding SDRP route violates transit policy due to
the content of the payload header.
- If the control packet carries the payload header and the
transport header, then the corresponding SDRP route violates
transit policy for the particular combination of payload and
transport header contents.
- コントロールパケットがペイロードデータを全く運ばないなら、対応するSDRPルートはそのルートに沿って運ばれたペイロードパケットの内容にかかわらず運送保険証券に違反します。 - コントロールパケットがペイロードヘッダーだけを運ぶなら、対応するSDRPルートはペイロードヘッダーの内容のため運送保険証券に違反します。 - コントロールパケットがペイロードヘッダーと輸送ヘッダーを運ぶなら、対応するSDRPルートはペイロードと輸送ヘッダーコンテンツの特定の組み合わせのための運送保険証券に違反します。
If a router receives an SDRP control packet that carries "Hop Count Exceeded" Notification Code, the router should use the information in the payload of the Control packet to construct an ICMP Time Exceeded Message with code "time to live exceeded in transit" and send the message to the host indicated by the source address in the Payload Header.
ルータが「超えられていたホップカウント」Notification Codeを運ぶSDRPコントロールパケットを受けるなら、ルータは、「ライブ超えられているコネへの時間は通過する」コードでICMP Time Exceeded Messageを組み立てて、有効搭載量Headerのソースアドレスによって示されたホストにメッセージを送るのにControlパケットのペイロードで情報を使用するべきです。
7.2 Processing ICMP messages
7.2 処理ICMPメッセージ
To correlate information carried in the ICMP messages with the SDRP routes used by the router, the router uses the portion of the SDRP datagram returned by ICMP. This must contain the Source Route Identifier of the SDRP route used by the router.
SDRPルートがルータによって使用されている状態でICMPメッセージで運ばれた情報を関連させるように、ルータはICMPによって返されたSDRPデータグラムの一部を使用します。 これはルータによって使用されるSDRPルートのSource Route Identifierを含まなければなりません。
ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set" should be used for SDRP MTU discovery as described in Section 9.
「断片化が必要であり、DFは設定する」コード意味があるICMP Destination UnreachableメッセージがSDRP MTU発見にセクション9で説明されるように使用されるべきです。
All other ICMP Unreachable messages indicate that the associated route is not feasible.
他のすべてのICMP Unreachableメッセージが、関連ルートが可能でないことを示します。
8. Constructing D-FIBs.
8. D-空言を組み立てます。
A BR constructs its D-FIB as a result of participating in either BGP or IDRP. A BR must advertise a route to destinations within its domain to all of its external peers (BRs in adjacent domains), via BGP or IDRP. In BGP and IDRP, a BR must advertise a route to destinations within its domain to all of its external peers (BRs in adjacent domains).
その結果、BRは、BGPかIDRPのどちらかに参加しながら、D-FIBを作ります。 BRは外部の同輩(隣接しているドメインのBRs)のすべてへのドメインの中の目的地にルートの広告を出さなければなりません、BGPかIDRPを通して。 BGPとIDRPでは、BRは外部の同輩(隣接しているドメインのBRs)のすべてへのドメインの中の目的地にルートの広告を出さなければなりません。
Estrin, et al Informational [Page 24] RFC 1940 SDRv1 May 1996
Estrin、他Informational[24ページ]RFC1940のSDRv1 May 1996
If a BR receives a route to an adjacent domain from a BR in that domain and selects that route as part of its BGP or IDRP Decision Process, then it must propagate this route (via BGP or IDRP) to all other BRs within its domain. A BR may also propagate such a route if it depicts an autonomous system other than the adjacent domain.
BRがそのドメインのBRからルートを隣接しているドメインに受けて、そのBGPかIDRP Decision Processの一部としてそのルートを選定するなら、それはこのルート(BGPかIDRPを通した)をドメインの中の他のすべてのBRsに伝播しなければなりません。 また、隣接しているドメイン以外の自律システムについて表現するなら、BRはそのようなルートを伝播するかもしれません。
Since AS numbers are encoded as network numbers in network 128.0.0.0, it is possible to also advertise a route to a domain in BGP or IDRP.
以来AS番号がネットワーク・ナンバーとしてネットワークでコード化される、128.0、.0、.0、また、BGPかIDRPのドメインにルートの広告を出すのは可能です。
9. SDRP MTU Discovery
9. SDRP MTU発見
To participate in Path MTU Discovery ([6]) a router may maintain information about the maximum length of the payload packet that can be carried without fragmentation along a particular SDRP route.
([6]) Path MTUディスカバリーに参加するために、ルータは、情報が特定のSDRPルートに沿って断片化なしで運ぶことができるペイロードパケットの最大のおよそ長さであることを支持するかもしれません。
SDRP provides two complimentary techniques to support MTU Discovery.
SDRPは、MTUディスカバリーを支持するために2つの賞賛テクニックを提供します。
The first one is passive and is based on the receipt of the ICMP Destination Unreachable messages (as described in Section 7.2). By combining information provided in the ICMP message with local information about the SDRP route the local system can determine the length of a payload packet that would require fragmentation.
最初のものは、受け身であり、ICMP Destination Unreachableメッセージの領収書に基づいています(セクション7.2で説明されるように)。 SDRPルートのローカルの情報と共にICMPメッセージに提供された情報を結合することによって、ローカルシステムは断片化を必要とするペイロードパケットの長さを測定できます。
The second one is active and employs the Probe Indicator bit. If an SDRP data packet that carries the Probe Indicator bit in the SDRP header and Don't Fragment flag in the delivery header triggers the last router on the SDRP route to return an SDRP Control packet (with the Notification Code "Probe Completed"), then the information carried in the payload header of the control packet can be used to determine the length of the payload packet that went through the SDRP route without fragmentation.
2番目の人は、アクティブであり、Probe Indicatorビットを使います。 配送ヘッダーでFragment旗ではなく、SDRPヘッダーとドンのProbe Indicatorビットを運ぶSDRPデータ・パケットがSDRP Controlパケット(「徹底的調査は完成した」Notification Codeと)を返すSDRPルートの上の最後のルータの引き金となるなら、断片化なしでSDRPルートに直面していたペイロードパケットの長さを測定するのにコントロールパケットのペイロードヘッダーで運ばれた情報は使用できます。
10. Acknowledgments
10. 承認
The authors would like to thank Scott Bradner (Harvard University), Noel Chiappa (Consultant), Joel Halpern (Newbridge Networks), Christian Huitema (INRIA), and Curtis Villamizar (ANS) for their comments on various aspects of this document.
作者はこのドキュメントの種々相の彼らのコメントについてスコットブラドナー(ハーバード大学)、クリスマスChiappa(コンサルタント)、ジョエル・アルペルン(ニューブリッジネットワークス)、クリスチャンのHuitema(INRIA)、およびカーティスVillamizar(ANS)に感謝したがっています。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Estrin, et al Informational [Page 25] RFC 1940 SDRv1 May 1996
Estrin、他Informational[25ページ]RFC1940のSDRv1 May 1996
Authors' Addresses
作者のアドレス
Deborah Estrin USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, Ca 90292-6695.
デボラEstrin USC/情報科学は4676の海軍省方法でマリーナデル・レイ、Ca90292-6695を設けます。
Phone: +1 310 822 1511 x 253 EMail: estrin@isi.edu
以下に電話をしてください。 +1 310 822、1511x253EMail: estrin@isi.edu
Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025
トニー李コクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025
Phone: +1 415 526 8186 EMail: tli@cisco.com
以下に電話をしてください。 +1 8186年の415 526メール: tli@cisco.com
Yakov Rekhter Cisco systems 170 West Tasman Drive San Jose, CA, USA
ヤコフRekhterシスコシステム170の西タスマン・Driveサンノゼ(カリフォルニア)(米国)
Phone: +1 914 528 0090 Fax: +1 408 526-4952 EMail: yakov@cisco.com
以下に電話をしてください。 +1 914 528、0090Fax: +1 408 526-4952 メールしてください: yakov@cisco.com
Kannan Varadhan USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, Ca 90292-6695.
Kannan Varadhan USC/情報科学は4676の海軍省方法でマリーナデル・レイ、Ca90292-6695を設けます。
Phone: +1 310 822 1511 x 402 EMail: kannan@isi.edu
以下に電話をしてください。 +1 310 822、1511x402EMail: kannan@isi.edu
Daniel Zappala USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, Ca 90292-6695.
ダニエルZappala USC/情報科学は4676の海軍省方法でマリーナデル・レイ、Ca90292-6695を設けます。
Phone: +1 310 822 1511 x 352 EMail: daniel@isi.edu
以下に電話をしてください。 +1 310 822、1511x352EMail: daniel@isi.edu
Estrin, et al Informational [Page 26] RFC 1940 SDRv1 May 1996
Estrin、他Informational[26ページ]RFC1940のSDRv1 May 1996
References
参照
[1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3), RFC 1267, October 1991.
[1] ロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)、RFC1267、1991年10月。」
[2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
Protocol in the Internet", RFC 1268, October 1991.
Rekhter、Y.、およびP.が利益を上げる[2]、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1268、1991年10月。
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1654, July 1994.
[3]Rekhter、Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1654 1994年7月。
[4] Hares, S., "IDRP for IP", IDR Working Group, 1994.
Work in Progress.
[4] 野兎、S.、「IPのためのIDRP」、IDR作業部会、1994。 進行中で、働いてください。
[5] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, September 1981.
[5] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、1981年9月。
[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[6] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[7] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC 1700, October 1994.
[7] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
Estrin, et al Informational [Page 27]
Estrin、他のInformational[27ページ]
一覧
スポンサーリンク
