RFC1953 日本語訳
1953 Ipsilon Flow Management Protocol Specification for IPv4 Version1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T.Lyon, G. Minshall. May 1996. (Format: TXT=43749 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Newman, Ipsilon
Request for Comments: 1953 W. L. Edwards, Sprint
Category: Informational R. Hinden, Ipsilon
E. Hoffman, Ipsilon
F. Ching Liaw, Ipsilon
T. Lyon, Ipsilon
G. Minshall, Ipsilon
May 1996
ワーキンググループのP.ニューマンをネットワークでつないでください、そして、Ipsilonはコメントのために以下を要求します。 1953w.L.エドワーズ、短距離競走カテゴリ: 情報のR.Hinden、Ipsilon E.ホフマン、Ipsilon F.チンLiaw、Ipsilon T.リヨンIpsilon G.Minshall、Ipsilon1996年5月
Ipsilon Flow Management Protocol Specification for IPv4
Version 1.0
IPv4バージョン1.0のためのIpsilon流れ管理プロトコル仕様
Status of this Memo
このMemoの状態
This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
This memo documents a private protocol for IPv4-based flows. This protocol is NOT the product of an IETF working group nor is it a standards track document. It has not necessarily benefited from the widespread and in depth community review that standards track documents receive.
このメモはIPv4ベースの流れのために個人的なプロトコルを記録します。 このプロトコルはIETFワーキンググループの製品ではありません、そして、それは標準化過程ドキュメントではありません。 必ず、標準化過程ドキュメントが受信されるのは広範囲の、そして、徹底的な共同体レビューから利益を得るというわけではありませんでした。
Abstract
要約
The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow. The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3.
Ipsilon Flow Managementプロトコル(IFMP)は、ノードが、層2のラベルを指定されたIP流動に取り付けるよう隣接しているノードに命令するのを許容するためのプロトコルです。 ラベルはその流れのためのキャッシュされたルーティング情報への、より効率的なアクセスを許します。 また、ラベルは、ノードが層2で層3でそれらを進めるよりむしろ指定された流れに属す一層のパケットを切り換えるのを可能にすることができます。
Table of Contents
目次
1. Introduction....................................................2
2. Flow Types......................................................2
3. IFMP Adjacency Protocol.........................................4
3.1 Packet Format.............................................4
3.2 Procedure.................................................7
4. IFMP Redirection Protocol......................................10
4.1 Redirect Message.........................................12
4.2 Reclaim Message..........................................13
4.3 Reclaim Ack Message......................................15
4.4 Label Range Message......................................16
1. 序論…2 2. 流れタイプ…2 3. IFMP隣接番組プロトコル…4 3.1 パケット形式…4 3.2手順…7 4. IFMPリダイレクションプロトコル…10 4.1 メッセージを向け直してください…12 4.2 メッセージを取り戻してください…13 4.3 Ackメッセージを取り戻してください…15 4.4 範囲メッセージをラベルしてください…16
Newman, et. al. Informational [Page 1] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [1ページ]情報のRFC1953IFMP仕様1996年5月
4.5 Error Message............................................17
References........................................................19
Security Considerations...........................................19
Authors' Addresses................................................19
4.5エラーメッセージ…17の参照箇所…19 セキュリティ問題…19人の作者のアドレス…19
1. Introduction
1. 序論
The Ipsilon Flow Management Protocol (IFMP), is a protocol for instructing an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow and it allows the flow to be switched rather than routed in certain cases.
Ipsilon Flow Managementプロトコル(IFMP)は、層2のラベルを指定されたIP流動に取り付けるよう隣接しているノードに命令するためのプロトコルです。 ラベルはその流れのためのキャッシュされたルーティング情報への、より効率的なアクセスを許します、そして、それは流れがある場合には、掘るよりむしろ切り換えられるのを許容します。
If a network node's upstream and downstream links both redirect a flow at the node, then the node can switch the flow at the data link layer rather than forwarding it at the network layer. The label space is managed at the downstream end of each link and redirection messages are sent upstream to associate a particular flow with a given label. Each direction of transmission on a link is treated separately.
ネットワーク・ノードの上流の、そして、川下のリンクがノードでともに流れを向け直すなら、ノードはネットワーク層でそれを進めるよりむしろデータ・リンク層で流れを切り換えることができます。 それぞれのリンクの川下の端でラベルスペースを管理します、そして、特定の流れを与えられたラベルに関連づけるために上流へリダイレクションメッセージを送ります。 リンクにおけるトランスミッションの各方向は別々に扱われます。
If the flow is not refreshed by the time the lifetime field in the redirect message expires, then the association between the flow and the label is discarded. A flow is refreshed by sending a redirect message, identical to the original, before the lifetime expires.
再直接のメッセージの生涯分野が期限が切れる時までに流れが壮快でないなら、流れとラベルとの協会は捨てられます。 流れは、寿命が期限が切れる前にオリジナルと同じ再直接のメッセージを送ることによって、リフレッシュされます。
Several flow types may be specified. Each flow type specifies the set of fields from the packet header that are used to identify a flow. There must be an ordering amongst the different flow types such that a most specific match operation may be performed.
いくつかの流れタイプが指定されるかもしれません。 それぞれの流れタイプはパケットのヘッダーからの流れを特定するのに使用される分野のセットを指定します。 注文が、最も特定のマッチ操作を実行できるように異なった流れタイプにあるに違いありません。
A particular flow is specified by a flow identifier. The flow identifier for that flow gives the contents of the set of fields from the packet header as defined for the flow type to which it belongs.
特定の流れは流れ識別子によって指定されます。 その流れのための流れ識別子はそれが属する流れタイプのために定義されるようにパケットのヘッダーから分野のセットのコンテンツを与えます。
This document specifies the IFMP protocol for IPv4 on a point-to- point link. The definition of labels, and the encapsulation of flows, are specified in a separate document for each specific data link technology. The specification for ATM data links is given in [ENCAP].
このドキュメントはポイントからポイントへのリンクの上のIPv4にIFMPプロトコルを指定します。 ラベルの定義、および流れのカプセル化はそれぞれの特定のデータ・リンク技術のための別々のドキュメントで指定されます。 [ENCAP]でATMデータ・リンクのための仕様を与えます。
2. Flow Types
2. 流れタイプ
A flow is a sequence of packets that are sent from a particular source to a particular (unicast or multicast) destination and that are related in terms of their routing and any logical handling policy they may require.
流れは特定のソースから特定(ユニキャストかマルチキャスト)の目的地に送られて、彼らが必要とするそれらのルーティングと論理的な取り扱い方針で関係づけられるパケットの系列です。
Newman, et. al. Informational [Page 2] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [2ページ]情報のRFC1953IFMP仕様1996年5月
A flow is identified by its flow identifier.
流れは流れ識別子によって特定されます。
Several different flow types can be defined. The particular set of fields from the packet header used to identify a flow constitutes the flow type. The values of these fields, for a particular flow, constitutes the flow identifier for that flow. The values of these fields must be invariant in all packets belonging to the same flow at any point in the network.
いくつかの異なった流れタイプを定義できます。 流れを特定するのに使用されるパケットのヘッダーからの特定のセットの分野は流れタイプを構成します。 特定の流れのために、これらの分野の値はその流れのための流れ識別子を構成します。 これらの分野の値は、任意な点でネットワークで同じ流れに属しながら、すべてのパケットで不変であるに違いありません。
Flow types are sub- or super-sets of each other such that there is a clear hierarchy of flow types. This permits a most specific match operation to be performed. (If additional flow types are defined in the future that are not fully ordered then the required behavior will be defined.) Each flow type also specifies an encapsulation that is to be used after a flow of this type is redirected. The encapsulations for each flow type are specified in a separate document for each specific data link technology. The encapsulations for flows over ATM data links are given in [ENCAP].
または、流れタイプがそうである、サブ、スーパーセット、互いでは、流れの明確な階層構造があるようなものはタイプされます。 これは、最も特定のマッチ操作が実行されることを許可します。 (追加流れタイプが完全に注文されるというわけではない未来に定義されると、必要な振舞いは定義されるでしょう。) また、それぞれの流れタイプはこのタイプの流れが向け直された後に使用されていることになっているカプセル化を指定します。 それぞれの流れタイプのためのカプセル化はそれぞれの特定のデータ・リンク技術のための別々のドキュメントで指定されます。 [ENCAP]でATMデータ・リンクの上の流れのためのカプセル化を与えます。
Three flow types are defined in this version of the protocol:
3つの流れタイプがプロトコルのこのバージョンで定義されます:
Flow Type 0
流れタイプ0
Flow Type 0 is used to change the encapsulation of IPv4 packets
from the default encapsulation.
流れType0は、デフォルトカプセル化からIPv4パケットのカプセル化を変えるのに使用されます。
For Flow Type 0: Flow Type = 0 and Flow ID Length = 0.
流れには、0をタイプしてください: 流れタイプ=0と流れIDの長さ=0。
The Flow Identifier for Flow Type 0 is null (zero length).
Flow Type0のためのFlow Identifierはヌル(ゼロ・レングス)です。
Flow Type 1
流れタイプ1
Flow Type 1 is designed for protocols such as UDP and TCP in which
the first four octets after the IPv4 header specify a Source Port
number and a Destination Port number.
流れType1はIPv4ヘッダーの後の最初の4つの八重奏がSource Port番号とDestination Port番号を指定するUDPやTCPなどのプロトコルのために設計されています。
For Flow Type 1, Flow Type = 1 and Flow ID Length = 4 (32 bit
words).
Flow Type1に関しては、Flow TypeはLength=4(32ビットの単語)の1とFlow IDと等しいです。
The format of the Flow Identifier for Flow Type 1 is:
Flow Type1のためのFlow Identifierの形式は以下の通りです。
Newman, et. al. Informational [Page 3] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [3ページ]情報のRFC1953IFMP仕様1996年5月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Time to Live | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| IHL|サービスのタイプ| 生きる時間| プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type 2
流れタイプ2
For Flow Type 2, Flow Type = 2 and Flow ID Length = 3 (32 bit
words).
Flow Type2に関しては、Flow TypeはLength=3(32ビットの単語)の2とFlow IDと等しいです。
The format of the Flow Identifier for Flow Type 2 is:
Flow Type2のためのFlow Identifierの形式は以下の通りです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL | Reserved | Time to Live | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| IHL| 予約されます。| 生きる時間| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved fields are unused and should be set to zero by the
sender and ignored by the receiver.
Reserved分野は、未使用であり、送付者によってゼロに設定されて、受信機によって無視されるべきです。
3. IFMP Adjacency Protocol
3. IFMP隣接番組プロトコル
The IFMP Adjacency Protocol allows a host or router to discover the identity of a peer at the other end of a link. It is also used to synchronize state across the link, to detect when the peer at the other end of the link changes, and to exchange a list of IP addresses assigned to the link.
IFMP Adjacencyプロトコルで、ホストかルータがリンクのもう一方の端で同輩のアイデンティティを発見できます。 また、リンクの向こう側に状態を同期させて、リンクのもう一方の端の同輩がいつ変化するかを検出して、リンクに割り当てられたIPアドレスのリストを交換するのも使用されています。
3.1 Packet Format
3.1 パケット・フォーマット
All IFMP messages belonging to the Adjacency Protocol must be encapsulated within an IPv4 packet and must be sent to the IP limited broadcast address (255.255.255.255). The Protocol field in the IP header must contain the value 101 (decimal) indicating that the IP packet contains an IFMP message. The Time to Live (TTL) field in the IP header must be set to 1.
Adjacencyプロトコルに属すのをIPv4パケットの中でカプセル化しなければならなくて、制限されたIPに送らなければならないというすべてのIFMPメッセージがアドレスを放送する、(255.255 .255 .255)。 IPパケットがIFMPメッセージを含むのを示しながら、IPヘッダーのプロトコル分野は値101の(小数)を含まなければなりません。 IPヘッダーのLive(TTL)分野へのTimeは1に用意ができなければなりません。
Newman, et. al. Informational [Page 4] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [4ページ]情報のRFC1953IFMP仕様1996年5月
All IFMP messages belonging to the adjacency protocol have the following structure:
隣接番組プロトコルに属すすべてのIFMPメッセージが以下の構造を持っています:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Next Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | Max Ack Intvl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address List ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| オペコード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩のアイデンティティ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次の一連番号にじっと見てください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 予約されます。| マックスAck Intvl| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 住所録~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The IFMP protocol version number. The current Version = 1.
IFMPプロトコルバージョンが付番するバージョン。 現在のバージョン=1。
Op Code
Specifies the function of the message. Four Op Codes are
defined for the IFMP Adjacency Protocol:
オプアートCode Specifies、メッセージの機能。 4Op CodesがIFMP Adjacencyプロトコルのために定義されます:
SYN: Op Code = 0
SYNACK: Op Code = 1
RSTACK: Op Code = 2
ACK: Op Code = 3
SYN: オペコードは0SYNACKと等しいです: オペコードは1RSTACKと等しいです: オペコードは2ACKと等しいです: オペコード=3
Checksum
The 16-bit one's complement of the one's complement sum of
a pseudo header of information from the IP header and the
IFMP message itself. The pseudo header, conceptually
prefixed to the IFMP message, contains the Source Address,
the Destination Address, and the Protocol fields from the
IPv4 header, and the total length of the IFMP message
starting with the Version field (this is equivalent to the
value of the Total Length field from the IPv4 header minus
the length of the IPv4 header itself).
1の補数の16ビットの1の補数がまとめるIPヘッダーとIFMPメッセージ自体からの情報の疑似ヘッダーのチェックサム。 概念的にIFMPメッセージへ前に置かれた疑似ヘッダーはSource Address、Destination Address、IPv4ヘッダーからのプロトコル分野、およびバージョン野原から始まるIFMPメッセージの全長を含んでいます(これはIPv4ヘッダー自体の長さを引いてIPv4ヘッダーからのTotal Length分野の値に同等です)。
Newman, et. al. Informational [Page 5] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [5ページ]情報のRFC1953IFMP仕様1996年5月
Sender Instance
For the SYN, SYNACK, and ACK messages, is the sender's
instance number for the link. The receiver uses this to
detect when the link comes back up after going down or when
the identity of the peer at the other end of the link
changes. The instance number is a 32 bit number that is
guaranteed to be unique within the recent past and to
change when the link or node comes back up after going
down. It is used in a similar manner to the initial
sequence number (ISN) in TCP [RFC 793]. Zero is not a
valid instance number. For the RSTACK message the Sender
Instance field is set to the value of the Peer Instance
field from the incoming message that caused an RSTACK
message to be generated.
送付者Instance For SYN(SYNACK、およびACKメッセージ)は送付者のリンクのインスタンス番号です。 受信機は、リンクが落ちた後に、いつ来て戻るか、そして、またはリンクのもう一方の端の同輩のアイデンティティがいつ変化するかを検出するのにこれを使用します。 インスタンス番号は最近の過去中に特有であり、リンクかノードが落ちた後にいつ来て戻るかを変えるために保証される32ビットの数です。 それは同じようにTCP[RFC793]の初期シーケンス番号(ISN)に使用されます。 ゼロは有効なインスタンス番号ではありません。 RSTACKメッセージにおいて、Sender Instance分野は生成するべきRSTACKメッセージを引き起こした入力メッセージからのPeer Instance分野の値に設定されます。
Peer Instance
For the SYN, SYNACK, and ACK messages, is what the sender
believes is the peer's current instance number for the
link. If the sender of the message does not know the
peer's current instance number for the link, the sender
must set this field to zero. For the RSTACK message the
Peer Instance field is set to the value of the Sender
Instance field from the incoming message that caused an
RSTACK message to be generated.
同輩Instance For SYN(SYNACK、およびACKメッセージ)は送付者が同輩のリンクの現在のインスタンス番号であると信じていることです。 メッセージ送信者が同輩のリンクの現在のインスタンス番号を知らないなら、送付者はこの分野をゼロに設定しなければなりません。 RSTACKメッセージにおいて、Peer Instance分野は生成するべきRSTACKメッセージを引き起こした入力メッセージからのSender Instance分野の値に設定されます。
Peer Identity
For the SYN, SYNACK, and ACK messages, is the IP address of
the peer that the sender of the message believes is at the
other end of the link. The Peer Identity is taken from the
Source IP Address of the IP header of a SYN or a SYNACK
message. If the sender of the message does not know the IP
address of the peer at the other end of the link, the
sender must set set this field to zero. For the RSTACK
message, the Peer Identity field is set to the value of the
Source Address field from the IP header of the incoming
message that caused an RSTACK message to be generated.
同輩Identity For SYN(SYNACK、およびACKメッセージ)はメッセージ送信者がリンクのもう一方の端にいると信じている同輩のIPアドレスです。 SYNのIPヘッダーかSYNACKメッセージのSource IP AddressからPeer Identityを取ります。 メッセージ送信者がリンク、送付者のもう一方の端の同輩のアドレスが知らなければならないIPを知らないなら、セットはこの分野をゼロに設定しました。 RSTACKメッセージに関しては、Peer Identity分野は生成するべきRSTACKメッセージを引き起こした入力メッセージのIPヘッダーからのSource Address分野の値へのセットです。
Peer Next Sequence Number
Gives the value of the peer's Sequence Number that the
sender of the IFMP Adjacency Protocol message expects to
arrive in the next IFMP Redirection Protocol message. If a
node is in the ESTAB state, and the value of the Peer Next
Sequence Number in an incoming ACK message is greater than
the value of the Sequence Number plus one, from the last
IFMP Redirection Protocol message transmitted out of the
port on which the incoming ACK message was received, the
link should be reset. The procedure to reset the link is
defined in section 3.2.
同輩Next Sequence Number Gives、IFMP Adjacencyプロトコルメッセージの送付者が次のIFMP Redirectionプロトコルメッセージに到着すると予想する同輩のSequence Numberの値。 ノードがESTAB状態にあって、入って来るACKメッセージのPeer Next Sequence Numberの値がSequence Numberと1の値より大きいなら、入って来るACKメッセージが受け取られたポートから送られた最後のIFMP Redirectionプロトコルメッセージから、リンクはリセットされるべきです。 リンクをリセットする手順はセクション3.2で定義されます。
Newman, et. al. Informational [Page 6] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [6ページ]情報のRFC1953IFMP仕様1996年5月
Max Ack Intvl
Maximum Acknowledgement Interval is the maximum amount of
time the sender of the message will wait until transmitting
an ACK message.
マックスAck Intvl Maximum Acknowledgement Intervalはメッセージ送信者がACKメッセージを送るまで待つ最大の時間です。
Address List
A list of one or more IP addresses that are assigned to the
link by the sender of the message. The list must have at
least one entry that is identical to the Source Address in
the IP header. The contents of this list are not used by
the IFMP protocol but can be made available to the routing
protocol.
List Aがメッセージ送信者によってリンクに割り当てられる1つ以上のIPアドレスのリストであると扱ってください。 リストには、IPヘッダーでSource Addressと同じ少なくとも1つのエントリーがなければなりません。 このリストの中身をIFMPプロトコルによって使用されませんが、ルーティング・プロトコルは入手できます。
3.2 Procedure
3.2手順
The IFMP Adjacency Protocol is described by the rules and state tables given in this section.
IFMP Adjacencyプロトコルはこのセクションで与えられた規則とステートテーブルによって説明されます。
The rules and state tables use the following operations:
規則とステートテーブルは以下の操作を使用します:
o The "Update Peer Verifier" operation is defined as storing the
Sender Instance and the Source IP Address from a SYN or SYNACK
message received from the peer on a particular port.
o 「アップデート同輩検証」操作は指定港の上の同輩から受け取られたSYNかSYNACKメッセージからSender InstanceとSource IP Addressを保存すると定義されます。
o The procedure "Reset the link" is defined as:
o 手順が「リンクをリセットした」、以下と定義されます。
1. Generate a new instance number for the link
2. Delete the peer verifier (set the stored values of Sender
Instance and Source IP Address of the peer to zero)
3. Set Sequence Number and Peer Next Sequence Number to zero
4. Send a SYN message
5. Enter the SYNSENT state
1. 新しいインスタンスがリンク2の数であると生成してください。 同輩検証(Sender Instanceの保存された値と同輩のSource IP Addressをゼロに設定する)3を削除してください。 Sequence NumberとPeer Next Sequence Numberに4のゼロを合わせるように設定してください。 SYNメッセージ5を送ってください。 SYNSENT状態に入ってください。
o The state tables use the following Boolean terms and operators:
o ステートテーブルは以下の論理項とオペレータを使用します:
A The Sender Instance in the incoming message matches the
value stored from a previous message by the "Update Peer
Verifier" operation for the port on which the incoming
message is received.
入力メッセージのSender Instanceは前のメッセージから入力メッセージが受信されているポートのための「アップデート同輩検証」操作で保存された値に合っています。
B The Sender Instance and the Source IP Address in the
incoming message matches the value stored from a previous
message by the "Update Peer Verifier" operation for the
port on which the incoming message is received.
値が前のメッセージから入力メッセージが受信されているポートのための「アップデート同輩検証」操作で保存した入力メッセージマッチのB Sender InstanceとSource IP Address。
Newman, et. al. Informational [Page 7] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [7ページ]情報のRFC1953IFMP仕様1996年5月
C The Peer Instance and Peer Identity in the incoming message
matches the value of the Sender Instance and the Source IP
Address currently in use for all SYN, SYNACK, and ACK
messages transmitted out of the port on which the incoming
message was received.
入力メッセージのCのPeer InstanceとPeer Identityは入力メッセージが受け取られたポートから送られたすべてのSYN、SYNACK、およびACKメッセージに、現在使用中のSender InstanceとSource IP Addressの値に合っています。
"&&" Represents the logical AND operation
"&&"は論理的なAND演算を表します。
"||" Represents the logical OR operation
"||「論理的なOR演算を表します」
"!" Represents the logical negation (NOT) operation.
"!" 論理的な否定(NOT)操作を表します。
o A timer is required for the periodic generation of SYN, SYNACK,
and ACK messages. The period of the timer is unspecified but a
value of one second is suggested.
o タイマがSYN、SYNACK、およびACKメッセージの周期的な世代に必要です。 タイマの期間は不特定ですが、1秒の値は示されます。
There are two independent events: the timer expires, and a packet
arrives. The processing rules for these events are:
2回の独立事象があります: タイマは期限が切れます、そして、パケットは到着します。 これらのイベントのための処理規則は以下の通りです。
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
タイマは期限が切れます: SYNRCVD Send SYNACK If SYNSENT Send SYN IfリセットTimer If状態=状態=状態はESTAB Send ACKと等しいです。
Packet Arrives: If incoming message is an RSTACK
If A && C && !SYNSENT
Reset the link
Else Discard the message
Else the following State Tables.
パケットは到着します: 入力メッセージがRSTACK If Aである、C、SYNSENT ResetリンクElse DiscardメッセージElseは以下の州Tablesをそうします。
o State synchronization across a link is considered to be achieved
when a node reaches the ESTAB state.
o ノードがESTAB状態に達するとき、リンクの向こう側の州の同期が達成されると考えられます。
Newman, et. al. Informational [Page 8] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [8ページ]情報のRFC1953IFMP仕様1996年5月
State Tables
ステートテーブル
State: SYNSENT
州: SYNSENT
+======================================================================+ | Condition | Action | New State | +====================+=====================================+===========+ | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | +--------------------+-------------------------------------+-----------+ | SYNACK && !C | Send RSTACK | SYNSENT | +--------------------+-------------------------------------+-----------+ | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | +--------------------+-------------------------------------+-----------+ | ACK | Send RSTACK | SYNSENT | +======================================================================+
+======================================================================+ | 状態| 動作| 新しい状態| +====================+=====================================+===========+ | SYNACK、C| 同輩検証をアップデートしてください。 ACKを送ってください。| ESTAB| +--------------------+-------------------------------------+-----------+ | SYNACK、C| RSTACKを送ってください。| SYNSENT| +--------------------+-------------------------------------+-----------+ | SYN| 同輩検証をアップデートしてください。 SYNACKを送ってください。| SYNRCVD| +--------------------+-------------------------------------+-----------+ | ACK| RSTACKを送ってください。| SYNSENT| +======================================================================+
State: SYNRCVD
州: SYNRCVD
+======================================================================+ | Condition | Action | New State | +====================+=====================================+===========+ | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | +--------------------+-------------------------------------+-----------+ | SYNACK && !C | Send RSTACK | SYNRCVD | +--------------------+-------------------------------------+-----------+ | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | +--------------------+-------------------------------------+-----------+ | ACK && B && C | Send ACK | ESTAB | +--------------------+-------------------------------------+-----------+ | ACK && !(B && C) | Send RSTACK | SYNRCVD | +======================================================================+
+======================================================================+ | 状態| 動作| 新しい状態| +====================+=====================================+===========+ | SYNACK、C| 同輩検証をアップデートしてください。 ACKを送ってください。| ESTAB| +--------------------+-------------------------------------+-----------+ | SYNACK、C| RSTACKを送ってください。| SYNRCVD| +--------------------+-------------------------------------+-----------+ | SYN| 同輩検証をアップデートしてください。 SYNACKを送ってください。| SYNRCVD| +--------------------+-------------------------------------+-----------+ | ACK、B、C| ACKを送ってください。| ESTAB| +--------------------+-------------------------------------+-----------+ | ACK、(B、C)| RSTACKを送ってください。| SYNRCVD| +======================================================================+
State: ESTAB
州: ESTAB
+=======================================================================+ | Condition | Action | New State | +=====================+=====================================+===========+ | SYN || SYNACK | Send ACK (note 1) | ESTAB | +---------------------+-------------------------------------+-----------+ | ACK && B && C | Send ACK (note 1) | ESTAB | +---------------------+-------------------------------------+-----------+ | ACK && !(B && C) | Send RSTACK | ESTAB | +=======================================================================+
+=======================================================================+ | 状態| 動作| 新しい状態| +=====================+=====================================+===========+ | SYN|| SYNACK| ACK(注意1)を送ってください。| ESTAB| +---------------------+-------------------------------------+-----------+ | ACK、B、C| ACK(注意1)を送ってください。| ESTAB| +---------------------+-------------------------------------+-----------+ | ACK、(B、C)| RSTACKを送ってください。| ESTAB| +=======================================================================+
Note 1: No more than one ACK should be sent within any time period of
length defined by the timer.
注意1: タイマによって定義された長さのどんな期間以内にも1ACKを送るべきです。
Newman, et. al. Informational [Page 9] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [9ページ]情報のRFC1953IFMP仕様1996年5月
4. IFMP Redirection Protocol
4. IFMPリダイレクションプロトコル
A sender encapsulates within an IPv4 packet all IFMP messages belonging to the Redirection Protocol. The sender sends these messages to the unicast IP address of the peer at the other end of the link. The IP address of the peer is obtained from the adjacency protocol. The Protocol field in the IP header must contain the value 101 (decimal) indicating that the IP packet contains an IFMP message. The Time to Live (TTL) field in the IP header must be set to 1.
送付者は、Redirectionプロトコルに属しながら、IPv4パケットの中ですべてのIFMPメッセージをカプセル化します。 送付者はリンクのもう一方の端で同輩のユニキャストIPアドレスにこれらのメッセージを送ります。 隣接番組プロトコルから同輩のIPアドレスを得ます。 IPパケットがIFMPメッセージを含むのを示しながら、IPヘッダーのプロトコル分野は値101の(小数)を含まなければなりません。 IPヘッダーのLive(TTL)分野へのTimeは1に用意ができなければなりません。
All IFMP Redirection Protocol messages have the following structure:
すべてのIFMP Redirectionプロトコルメッセージには、以下の構造があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| オペコード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ メッセージ本体~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The IFMP protocol version number, currently Version = 1.
IFMPプロトコルバージョンが付番するバージョン、現在のバージョン=1。
Op Code
This field gives the message type. Five message types are
currently defined for the IFMP Redirection Protocol:
オプアートCode This分野はメッセージタイプに与えます。 5つのメッセージタイプが現在、IFMP Redirectionプロトコルのために定義されます:
REDIRECT: Op Code = 4
RECLAIM: Op Code = 5
RECLAIM ACK: Op Code = 6
LABEL RANGE: Op Code = 7
ERROR: Op Code = 8
向け直します: 4が取り戻すオペコード=: オペコード=5はACKを開墾します: オペコードは6ラベル範囲と等しいです: オペコードは7誤りと等しいです: オペコード=8
Checksum
The 16-bit one's complement of the one's complement sum of
a pseudo header of information from the IP header, and the
IFMP message itself. The pseudo header, conceptually
prefixed to the IFMP message, contains the Source Address,
the Destination Address, and the Protocol fields from the
1の補数の16ビットの1の補数がまとめるIPヘッダー、およびIFMPメッセージ自体からの情報の疑似ヘッダーのチェックサム。 概念的にIFMPメッセージへ前に置かれた疑似ヘッダーはSource Address、Destination Address、およびプロトコル分野を含んでいます。
Newman, et. al. Informational [Page 10] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [10ページ]情報のRFC1953IFMP仕様1996年5月
IPv4 header, and the total length of the IFMP message
starting with the version field (this is equivalent to the
value of the Total Length field from the IPv4 header minus
the length of the IPv4 header itself).
IPv4ヘッダー、およびバージョン野原(これはIPv4ヘッダー自体の長さを引いてIPv4ヘッダーからのTotal Length分野の値に同等である)から始まるIFMPメッセージの全長。
Sender Instance
The sender's instance number for the link from the IFMP
Adjacency Protocol.
送付者の送付者InstanceのIFMP Adjacencyプロトコルからのリンクのインスタンス番号。
Peer Instance
What the sender believes is the peer's current instance
number for the link from the IFMP Adjacency protocol.
送付者が信じている同輩Instance Whatは同輩のIFMP Adjacencyプロトコルからのリンクの現在のインスタンス番号です。
Sequence Number
The sender must increment by one, modulo 2**32, for every
IFMP Redirection Protocol message sent across a link. It
allows the receiver to process IFMP Redirection Protocol
messages in order. The Sequence Number is set to zero when
a node resets the link.
送付者のNumberが1つ増加しなければならない系列、各IFMP Redirectionプロトコルメッセージあたり法2**32はリンクの向こう側に発信しました。 それで、受信機は整然とした状態でIFMP Redirectionプロトコルメッセージを処理できます。 ノードがリンクをリセットするとき、Sequence Numberはゼロに用意ができています。
Message Body
Contains a list of one or more IFMP Redirection Protocol
message elements. All of the message elements in the list
have the same message type because the Op Code field
applies to the entire IFMP message. The number of message
elements included in a single packet must not cause the
total size of the IFMP message to exceed the MTU size of
the underlying data link. Only a single message element is
permitted in a Label Range message or in an Error message.
1つ以上のIFMP Redirectionプロトコルメッセージ要素のBody Contains aリストを通信させてください。 Op Code分野が全体のIFMPメッセージに適用されるので、リストのメッセージ要素のすべてには、同じメッセージタイプがあります。 単一のパケットにメッセージ要素を含む数は基本的なデータ・リンクのMTUサイズを超えるIFMPメッセージの総サイズを引き起こしてはいけません。 ただ一つのメッセージ要素だけがLabel RangeメッセージかErrorメッセージで受入れられます。
No IFMP Redirection Protocol messages can be sent across a link until the IFMP Adjacency Protocol has achieved state synchronization across that link. All IFMP Redirection Protocol messages received on a link that does not currently have state synchronization must be discarded. For every received IFMP Redirection Protocol message the receiver must check the Source IP Address from the IP header, the Sender Instance, and the Peer Instance. The incoming message must be discarded if the Sender Instance and the Source IP Address fields do not match the values stored by the "Update Peer Verifier" operation of the IFMP Adjacency Protocol for the port on which the message is received. The incoming message must also be discarded if the Peer Instance field does not match the current value for the Sender Instance of the IFMP Adjacency Protocol.
IFMP Adjacencyプロトコルがそのリンクの向こう側に州の同期を実現するまで、リンクの向こう側にIFMP Redirectionプロトコルメッセージを全く送ることができません。 現在州の同期を持っていないリンクの上に受け取られたすべてのIFMP Redirectionプロトコルメッセージを捨てなければなりません。 あらゆる受信されたIFMP Redirectionプロトコルメッセージがないかどうか、受信機はIPヘッダー、Sender Instance、およびPeer InstanceからSource IP Addressをチェックしなければなりません。 Sender InstanceとSource IP Address分野がIFMP Adjacencyプロトコルの「アップデート同輩検証」操作でメッセージが受信されているポートとして保存された値に合っていないなら、入力メッセージを捨てなければなりません。 また、Peer Instance分野がIFMP AdjacencyプロトコルのSender Instanceのための現行価値に合っていないなら、入力メッセージを捨てなければなりません。
Newman, et. al. Informational [Page 11] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [11ページ]情報のRFC1953IFMP仕様1996年5月
4.1 Redirect Message
4.1 再直接のメッセージ
The Redirect Message element is used to instruct an adjacent node to attach one or more given labels to packets belonging to one or more specified flows each for a specified period of time. The Redirect message is not acknowledged.
Redirect Message要素は、1つを付けるよう隣接しているノードに命令するのに使用するか、または指定された期間の間にそれぞれ1回以上の指定された流れに属すパケットにラベルをもう少し与えます。 Redirectメッセージは承認されません。
Each Redirect message element has the following structure:
それぞれのRedirectメッセージ要素には、以下の構造があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れタイプ| 流れIDの長さ| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 流れ識別子~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type
Specifies the Flow Type of the flow identifier contained in
the Flow Identifier field.
流れ識別子のFlow TypeがFlow Identifier分野に保管していた流れType Specifies。
Flow ID Length
Specifies the length of the Flow Identifier field in
integer multiples of 32 bit words.
32の整数倍数における、Flow Identifier分野の長さの流れID Length Specifiesは単語に噛み付きました。
Lifetime field
Specifies the length of time, in seconds, for which this
redirection is valid. The association of flow identifier
and label should be discarded at a time no greater than
that specified by the Lifetime field. A value of zero is
not valid.
秒の時間の長さの生涯分野Specifies。(このリダイレクションは秒の間、有効です)。 よりそれがLifetime分野で指定したとき、流れ識別子とラベルの協会は捨てられるべきです。 ゼロの値は有効ではありません。
Label field
Contains a 32 bit label. The format of the label is
dependent upon the type of physical link across which the
Redirect message is sent. (The format of the label for ATM
data links is specified in [ENCAP].)
32ビットのラベルと分野Containsをラベルしてください。 ラベルの形式はRedirectメッセージが送られる物理的なリンクのタイプに依存しています。 (ATMデータ・リンクへのラベルの形式は[ENCAP]で指定されます。)
Flow Identifier
Identifies the flow with which the specified label should
be associated. The length of the Flow Identifier field
must be an integer multiple of 32 bit words to preserve 32
bit alignment.
流れIdentifier Identifies、指定されたラベルが関連しているべきである流れ。 Flow Identifier分野の長さは、32ビットの整列を保存するためには32ビットの単語の整数倍数でなければなりません。
Newman, et. al. Informational [Page 12] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [12ページ]情報のRFC1953IFMP仕様1996年5月
A node can send an IFMP message containing one or more Redirect message elements across a link to its upstream neighbor. Each Redirect message element requests that the upstream neighbor associate a given link-level label to packets belonging to a specified flow for up to a specified period of time. A node receiving an IFMP message that contains one or more Redirect message elements from an adjacent downstream neighbor can choose to ignore any or all of the Redirect message elements. Neither the IFMP message nor any of the Redirect message elements are acknowledged. If the node chooses to accept a particular Redirect message element and to redirect the specified flow, it should attach the label specified in the Redirect message element to all further packets sent on that flow until it chooses to do so no longer, or until the specified lifetime expires. While the flow remains redirected, the encapsulation specified by the definition of the Flow Type given in the Redirect message element must be used for all packets belonging to that flow. If the label in a Redirect message element is outside the range that can be handled across the relevant link, a Label Range message can be returned to the sender. The Label Range message informs the sender of the Redirect message of the range of labels that can be sent across the link.
ノードはリンクの向こう側に1つ以上のRedirectメッセージ要素を含むIFMPメッセージを上流の隣人に送ることができます。 それぞれのRedirectメッセージ要素は、上流の隣人が指定された期間まで指定された流れに属すパケットに与えられたリンク・レベルラベルを関連づけるよう要求します。 隣接している川下の隣人から1つ以上のRedirectメッセージ要素を含むIFMPメッセージを受け取るノードは、Redirectメッセージ要素のいずれかすべてを無視するのを選ぶことができます。 IFMPメッセージもRedirectメッセージ要素のいずれも承認されません。 ノードが特定のRedirectメッセージ要素を受け入れて、指定された流れを向け直すのを選ぶなら、それはもうそうしないのを選ぶか、または指定された寿命が期限が切れるまでその流れで送られたパケットをすべて促進するためにRedirectメッセージ要素で指定されたラベルを取り付けるべきです。 流れが向け直されたままで残っている間、その流れに属すすべてのパケットにRedirectメッセージ要素で与えられているFlow Typeの定義で指定されたカプセル化を使用しなければなりません。 関連リンクの向こう側に扱うことができる範囲の外にRedirectメッセージ要素のラベルがあるなら、Label Rangeメッセージを送付者に返すことができます。 Label Rangeメッセージはリンクの向こう側に送ることができるラベルの範囲に関するRedirectメッセージについて送付者に知らせます。
If a Redirect message element is received specifying a flow that is already redirected, the Label field in the received Redirect message element must be checked against the label stored for the redirected flow. If they agree, the lifetime of the redirected flow is reset to that contained in the Redirect message element. If they disagree, the Redirect message element is ignored, and the flow returned to the default state. There is a minimum time between Redirect message elements specifying the same flow. The default value is one second.
Redirectメッセージ要素が既に向け直される流れを指定するのにおいて受け取られているなら、向け直された流れのために保存されたラベルに対して容認されたRedirectメッセージ要素のLabel分野をチェックしなければなりません。 彼らが同意するなら、向け直された流れの寿命はRedirectメッセージ要素に含まれたそれにリセットされます。 彼らが意見を異にするなら、Redirectメッセージ要素は無視されました、そして、流れはデフォルト状態に戻りました。 同じ流れを指定するRedirectメッセージ要素の間には、最小の時間があります。 デフォルト値は1秒です。
If a receiving node detects an error in any of the fields of a Redirect message element, the node must discard that message element without affecting any other Redirect message elements in the same IFMP message. The receiver should return an error message to the sender only in the case that the receiver does not understand the version of the IFMP protocol in the received IFMP message or does not understand a Flow Type in any of the Redirect message elements. An Error Message should be returned for each Flow Type that is not understood.
受信ノードがRedirectメッセージ要素の分野のどれかに誤りを検出するなら、同じIFMPメッセージでいかなる他のRedirectメッセージ要素にも影響しないで、ノードはそのメッセージ要素を捨てなければなりません。 受信機が単に受信されたIFMPメッセージでIFMPプロトコルのバージョンを理解していないか、またはRedirectメッセージ要素のいずれでもFlow Typeを理解していなくて、受信機はエラーメッセージを送付者に返すはずです。 理解されていない各Flow TypeのためにError Messageを返すべきです。
4.2 Reclaim Message
4.2はメッセージを取り戻します。
The Reclaim message element is used by a node to instruct an adjacent upstream node to unbind one or more flows from the labels to which they are currently bound, and to release the labels.
Reclaimメッセージ要素はノードによって使用されて、それらが現在制限されているラベルから1回以上の流れを解くよう隣接している上流のノードに命令して、ラベルを放出します。
Newman, et. al. Informational [Page 13] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [13ページ]情報のRFC1953IFMP仕様1996年5月
Each Reclaim message element has the following structure:
それぞれのReclaimメッセージ要素には、以下の構造があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れタイプ| 流れIDの長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 流れ識別子~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type
Specifies the Flow Type of the Flow Identifier contained in
the Flow ID field.
Flow IdentifierのFlow TypeがFlow ID分野に保管していた流れType Specifies。
Flow ID Length
Specifies the length of the Flow Identifier field in
integer multiples of 32 bit words.
32の整数倍数における、Flow Identifier分野の長さの流れID Length Specifiesは単語に噛み付きました。
Reserved
Field is unused and should be set to zero by the sender and
ignored by the receiver.
予約されたFieldは未使用であり、送付者がゼロに用意ができて、受信機によって無視されるべきです。
Label
Field contains the label to be released.
ラベルFieldはリリースされるべきラベルを含んでいます。
Flow Identifier
Field contains the flow identifier to be unbound.
流れIdentifier Fieldは解かれるべき流れ識別子を含んでいます。
A node can send a Reclaim message element to instruct an adjacent upstream node to unbind a flow from the label to which it is currently bound, return the flow to the default forwarding state, and release the label. Each Reclaim message element applies to a single flow and a single label. When the receiver has completed the operation, it must issue a Reclaim Ack message element. Reclaim Ack message elements can be grouped together, in any order, into one or more IFMP Reclaim Ack messages and returned to the sender as an acknowledgment that the operation is complete.
ノードは、それが現在制限されているラベルから流れを解くよう隣接している上流のノードに命令するためにReclaimメッセージ要素を送って、状態を進めながら流れをデフォルトに返して、ラベルを放出できます。 それぞれのReclaimメッセージ要素はただ一つの流れと単一のラベルに適用されます。 受信機が操作を完了したとき、それはReclaim Ackメッセージ要素を発行しなければなりません。 一緒に順不同に1つ以上のIFMP Reclaim Ackメッセージに分類できて、操作が完全であるという承認として送付者に返されたAckメッセージ要素を再生利用してください。
If a Reclaim message element is received indicating an unknown flow, a Reclaim Ack message element must be returned containing the same Label and Flow Identifier fields from the Reclaim message.
Reclaimメッセージ要素が未知の流れを示すのにおいて受け取られているなら、Reclaimメッセージからの同じLabelとFlow Identifier分野を含んでいて、Reclaim Ackメッセージ要素を返さなければなりません。
Newman, et. al. Informational [Page 14] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [14ページ]情報のRFC1953IFMP仕様1996年5月
If a Reclaim message element is received indicating a known flow, but with a Label that is not currently bound to that flow, the flow must be unbound and returned to the default forwarding state, and a Reclaim Ack message sent containing the actual label to which the flow was previously bound.
Reclaimメッセージ要素が知られている流れを示すのにおいて受け取られていますが、現在Labelと共にその流れにそれを縛らないなら、デフォルト推進状態に流れを解いて、返さなければなりませんでした、そして、流れが以前に制限されていた実際のラベルを含んでいて、Reclaim Ackメッセージは発信しました。
If the receiver detects an error in any of the fields of a Reclaim message element, the receiver must discard that message element, without affecting any other Reclaim message elements in the same message. The receiver must return an error message to the sender only in the case that the receiver does not understand the version of the IFMP protocol in the received message or does not understand a Flow Type in one of the Reclaim message elements.
受信機がReclaimメッセージ要素の分野のどれかに誤りを検出するなら、受信機はそのメッセージ要素を捨てなければなりません、同じメッセージでいかなる他のReclaimメッセージ要素にも影響しないで。 受信機が単に受信されたメッセージでIFMPプロトコルのバージョンを理解していないか、またはReclaimメッセージ要素の1つでFlow Typeを理解していなくて、受信機はエラーメッセージを送付者に返さなければなりません。
4.3 Reclaim Ack Message
4.3はAckメッセージを取り戻します。
The Reclaim Ack message element is used by a receiving node to acknowledge the successful release of one or more reclaimed labels.
Reclaim Ackメッセージ要素は受信ノードによって使用されて、1以上のうまくいっているリリースがラベルを再生利用したと認めます。
Each Reclaim Ack message element has the following structure:
それぞれのReclaim Ackメッセージ要素には、以下の構造があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れタイプ| 流れIDの長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 流れ識別子~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type
Specifies the Flow Type of the Flow Identifier contained in
the Flow Identifier field.
Flow IdentifierのFlow TypeがFlow Identifier分野に保管していた流れType Specifies。
Flow ID Length
Specifies the length of the Flow Identifier field in
integer multiples of 32 bit words.
32の整数倍数における、Flow Identifier分野の長さの流れID Length Specifiesは単語に噛み付きました。
Reserved
Field is unused and should be set to zero by the sender and
ignored by the receiver.
予約されたFieldは未使用であり、送付者がゼロに用意ができて、受信機によって無視されるべきです。
Label
Field contains the label released from the flow specified
by the Flow Identifier.
ラベルFieldはFlow Identifierによって指定された流れから放出されたラベルを含んでいます。
Newman, et. al. Informational [Page 15] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [15ページ]情報のRFC1953IFMP仕様1996年5月
Flow Identifier
Field contains the Flow Identifier from the Reclaim message
element that requested the release of the label specified
in the Label field.
流れIdentifier FieldはラベルのリリースがLabel分野で指定したよう要求したReclaimメッセージ要素からのFlow Identifierを含んでいます。
A Reclaim Ack message element must be sent in response to each Reclaim message element received. It is sent to indicate that the requested flow is now unbound and that the label is now free. If possible, each Reclaim Ack message element should not be sent until all data queued for transmission on the link, using the label specified for release, has been sent.
Reclaimメッセージ要素が受けたそれぞれに対応してReclaim Ackメッセージ要素を送らなければなりません。 要求された流れが現在、解かれて、ラベルが現在無料であることを示すためにそれを送ります。 できれば、リリースに指定されたラベルを使用して、トランスミッションのためにリンクの上に列に並ばせられたすべてのデータを送るまでそれぞれのReclaim Ackメッセージ要素を送るべきではありません。
If a Reclaim Ack message element is received specifying a flow for which no Reclaim message element was issued, that Reclaim Ack message element must be ignored, but no other Reclaim Ack message elements in the same message must be affected.
Reclaim Ackメッセージ要素がReclaimメッセージ要素が全く発行されなかった流れを指定するのにおいて受け取られているなら、そのReclaim Ackメッセージ要素を無視しなければなりませんが、同じメッセージの他のReclaim Ackメッセージ要素は全く影響を受けてはいけません。
If a Reclaim Ack message element is received specifying a different label from the one sent in the original Reclaim message element for that flow, the Reclaim Ack message element should be handled as if the reclaim operation were successful.
Reclaim Ackメッセージ要素がその流れのために元のReclaimメッセージ要素で送られたものと異なったラベルを指定するのにおいて受け取られているなら、Reclaim Ackメッセージ要素が扱われるべきである、開墾、操作はうまくいきます。
If an error is detected in any of the fields of a Reclaim Ack message element, that message element must be discarded, but no other Reclaim Ack message elements in the same message must be affected.
誤りがReclaim Ackメッセージ要素の分野のどれかに検出されるなら、そのメッセージ要素を捨てなければなりませんが、同じメッセージの他のReclaim Ackメッセージ要素は全く影響を受けてはいけません。
The receiver should return an Error message to the sender only in the case that the receiver does not understand the version of the IFMP protocol in the received message or does not understand a Flow Type in one of the Reclaim Ack message elements.
受信機が単に受信されたメッセージでIFMPプロトコルのバージョンを理解していないか、またはReclaim Ackメッセージ要素の1つでFlow Typeを理解していなくて、受信機はErrorメッセージを送付者に返すはずです。
4.4 Label Range Message
4.4 ラベル範囲メッセージ
The Label Range message element is sent in response to a Redirect message if the label requested in one or more of the Redirect message elements is outside the range that the receiver of the Redirect message can handle. The Label Range message informs the sender of the Redirect message of the label range that can be handled on the relevant link.
Redirectメッセージの受信機が扱うことができる範囲の外にRedirectメッセージ要素の1つ以上で要求されたラベルがあるなら、Redirectメッセージに対応してLabel Rangeメッセージ要素を送ります。 Label Rangeメッセージは関連リンクの上に扱うことができるラベル範囲に関するRedirectメッセージについて送付者に知らせます。
Only a single Label Range message element is permitted in a Label Range message. The Label Range message element has the following structure:
ただ一つのLabel Rangeメッセージ要素だけがLabel Rangeメッセージで受入れられます。 Label Rangeメッセージ要素には、以下の構造があります:
Newman, et. al. Informational [Page 16] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [16ページ]情報のRFC1953IFMP仕様1996年5月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimum Label
The minimum value of label that can be specified in an IFMP
Redirection Protocol message across this link.
最小のLabel、このリンクの向こう側にIFMP Redirectionプロトコルメッセージで指定できるラベルの最小値。
Maximum Label
The maximum value of label that can be specified in an IFMP
Redirection Protocol message across this link.
最大のLabel、このリンクの向こう側にIFMP Redirectionプロトコルメッセージで指定できるラベルの最大値。
All values of label within the range Minimum Label to Maximum Label inclusive may be specified in an IFMP Redirection Protocol message across the link.
Maximum Labelに包括的な範囲Minimum Labelの中のラベルのすべての値がリンクの向こう側にIFMP Redirectionプロトコルメッセージで指定されるかもしれません。
4.5 Error Message
4.5 エラーメッセージ
An Error message can be sent by a node in response to any IFMP Redirection Protocol message.
ノードはどんなIFMP Redirectionプロトコルメッセージに対応してErrorメッセージを送ることができます。
Only a single Error message element is permitted in an Error message. The Error message element has the following structure:
ただ一つのErrorメッセージ要素だけがErrorメッセージで受入れられます。 Errorメッセージ要素には、以下の構造があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| パラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code
Specifies which an error has occurred.
誤りが起こるようにする誤りCode Specifies。
Each Error message can specify a single Parameter.
それぞれのErrorメッセージは独身のParameterを指定できます。
Newman, et. al. Informational [Page 17] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [17ページ]情報のRFC1953IFMP仕様1996年5月
Two Error message elements are specified:
2つのErrorメッセージ要素が指定されます:
Bad Version:
悪いバージョン:
Error Code = 1. The sender of the Error message cannot process the
version of the IFMP protocol of the message that caused the
error. This message must only be sent if the version of
the message that caused the error is greater than the most
recent version that the sender of the Error message can
process. The parameter field of this Error message gives
the most recent version of the IFMP protocol that the
sender can process, right justified, with the unused most
significant bits of the Parameter field set to zero.
エラーコード=1。 Errorメッセージの送付者は誤りを引き起こしたメッセージのIFMPプロトコルのバージョンを処理できません。 誤りを引き起こしたメッセージのバージョンがErrorメッセージの送付者が処理できる最新のバージョンより大きいなら、このメッセージを送るだけでよいです。 このErrorメッセージのパラメタ分野は送付者が処理できるIFMPプロトコルの最新のバージョンを与えます、まさしく正当です、ゼロに設定されたParameter分野の未使用の最上位ビットで。
Bad Flow Type:
悪い流れタイプ:
Error Code = 2. The sender of the Error message does not understand a
Flow Type that was received in the message that caused the
error. The Flow Type that caused the error is given in the
parameter field, right justified, with the unused most
significant bits of the Parameter field set to zero.
エラーコード=2。 Errorメッセージの送付者は誤りを引き起こしたメッセージに受け取られたFlow Typeを理解していません。 パラメタ分野で誤りを引き起こしたFlow Typeを与えます、まさしく正当です、ゼロに設定されたParameter分野の未使用の最上位ビットで。
Newman, et. al. Informational [Page 18] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [18ページ]情報のRFC1953IFMP仕様1996年5月
REFERENCES
参照
[ENCAP] Newman, P., et. al., "Transmission of Flow Labelled IPv4
on ATM Data Links Ipsilon Version 1.0," Ipsilon Networks,
RFC 1954, May 1996.
[ENCAP]ニューマン、P.et(アル)、「流れの送信は気圧データ・リンクの上のIPv4をIpsilonバージョン1.0とラベルしました」、Ipsilon Networks、RFC1954、1996年5月。
[RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
SECURITY CONSIDERATIONS
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
AUTHORS' ADDRESSES
作者のアドレス
Peter Newman Phone: +1 (415) 846-4603 Ipsilon Networks, Inc. EMail: pn@ipsilon.com
ピーターニューマンPhone: +1 (415) 846-4603 IpsilonはInc.メールをネットワークでつなぎます: pn@ipsilon.com
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334 Sprint EMail: texas@sprintcorp.com
L.エドワーズ、W.首席科学官は以下に電話をします。 +1(913) 534 5334年の短距離競走メール: texas@sprintcorp.com
Robert M. Hinden Phone: +1 (415) 846-4604 Ipsilon Networks, Inc. EMail: hinden@ipsilon.com
ロバートM.Hindenは以下に電話をします。 +1 (415) 846-4604 IpsilonはInc.メールをネットワークでつなぎます: hinden@ipsilon.com
Eric Hoffman Phone: +1 (415) 846-4610 Ipsilon Networks, Inc. EMail: hoffman@ipsilon.com
エリックホフマンPhone: +1 (415) 846-4610 IpsilonはInc.メールをネットワークでつなぎます: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (415) 846-4607 Ipsilon Networks, Inc. EMail: fong@ipsilon.com
フォンチンLiawは以下に電話をします。 +1 (415) 846-4607 IpsilonはInc.メールをネットワークでつなぎます: fong@ipsilon.com
Tom Lyon Phone: +1 (415) 846-4601 Ipsilon Networks, Inc. EMail: pugs@ipsilon.com
トムリヨン電話: +1 (415) 846-4601 IpsilonはInc.メールをネットワークでつなぎます: pugs@ipsilon.com
Greg Minshall Phone: +1 (415) 846-4605 Ipsilon Networks, Inc. EMail: minshall@ipsilon.com
グレッグMinshallは以下に電話をします。 +1 (415) 846-4605 IpsilonはInc.メールをネットワークでつなぎます: minshall@ipsilon.com
Newman, et. al. Informational [Page 19] RFC 1953 IFMP Specification May 1996
etニューマン、アル。 [19ページ]情報のRFC1953IFMP仕様1996年5月
Ipsilon Networks, Inc. is located at:
Ipsilon Networks Inc.は以下に位置しています。
2191 East Bayshore Road Suite 100 Palo Alto, CA 94303 USA
パロアルト、2191の東Bayshore道路スイート100カリフォルニア94303米国
Sprint is located at:
スプリントは以下に位置しています。
Sprint Sprint Technology Services - Long Distance Division 9300 Metcalf Avenue Mailstop KSOPKB0802 Overland Park, KS 66212-6333 USA
スプリントの短距離競走技術サービス--長距離の事業部9300メトカーフ・アベニューMailstop KSOPKB0802カンザス66212-6333オーバーランドパーク(米国)
Newman, et. al. Informational [Page 20]
etニューマン、アル。 情報[20ページ]
一覧
スポンサーリンク
