RFC2129 日本語訳
2129 Toshiba's Flow Attribute Notification Protocol (FANP)Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S.Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT=41137 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Nagami
Request for Comments: 2129 Y. Katsube
Category: Informational Y. Shobatake
A. Mogi
S. Matsuzawa
T. Jinmei
H. Esaki
Toshiba R&D Center
April 1997
Nagamiがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2129年のY.Katsubeカテゴリ: 情報のY.のH.江崎東芝研究開発センターShobatake A.茂木S.Matsuzawa T.Jinmei1997年4月
Toshiba's Flow Attribute Notification Protocol (FANP) Specification
東芝の流れ属性通知プロトコル(FANP)仕様
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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By using FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;
このメモはFlow Attribute Notificationプロトコル(FANP)について議論します。(それは、深く切っているパケット推進の機能性の管理のための隣人ノードの間のプロトコルです)。 深く切っているパケット推進では、ルータは容認されたパケットのための従来のIPパケット処理を実行する必要はありません。 FANPは、隣人ノードへのデータリンク接続とパケット流動の間のマッピング情報を示して、1組のノードがマッピング情報を管理するのを助けます。 FANPを使用することによって、ルータ(例えば、CSR; セルSwitch Router)はそれらのデータリンクレベル接続識別子に基づく入って来るパケットを進めることができます、普通のIPパケット処理を迂回させて。 FANPのデザイン方針はそうです。
(1) soft-state cut-through path (Dedicated-VC) management
(2) protocol between neighbor nodes instead of end-to-end
(3) applicable to any connection oriented datalink platform
(1) 終わりから終わりへのどんな接続にも適切な(3)の代わりに隣人ノードの間の深く切っている軟性国家経路(専用VC)管理(2)プロトコルはデータリンクプラットホームを適応させました。
1. Background
1. バックグラウンド
Due to the scalability requirement, connection oriented (CO) datalink platforms, e.g., ATM and Frame Relay, are going to be used as well as connection less (CL) datalink platforms, e.g., Ethernet and FDDI. One of the important features of the CO datalink is the presence of a datalink-level connection identifier. In the CO datalink, we can establish multiple virtual connections (VCs) with their VC identifiers among the nodes. When we aggregate packets that have the same direction (e.g., having the same destination IP address) into a single VC, we can forward the packets in the VC without IP
スケーラビリティ要件のために、接続(CO)指向のデータリンクプラットホーム(例えば、ATMとFrame Relay)は、接続より少ない(CL)データリンクプラットホーム、例えば、イーサネットと同様に使用されるべきである行くのとFDDIです。 COデータリンクの重要な特徴の1つはデータリンクレベル接続識別子の存在です。 COデータリンクに、ノードの中に彼らのVC識別子がある状態で、私たちは複数の仮想接続(VCs)を設立できます。 同じ指示(例えば、同じ送付先IPアドレスを持っている)を独身のVCに持っているパケットに集めるとき、私たちはVCでIPなしでパケットを進めることができます。
Nagami, et. al. Informational [Page 1] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [1ページ]情報のRFC2129FANP仕様1997年4月
processing. With this configuration, routers can decide which node is the next-hop for the packets based on the VC identifier. CSRs [1] can forward the incoming packets using an ATM switch engine bypassing the conventional IP processing. According to the ingress VPI/VCI value with ingress interface information, CSR determines the egress interface and egress VPI/VCI value.
処理。 この構成で、ルータは、VC識別子に基づくパケットのためにどのノードが次のホップであるかを決めることができます。 CSRs[1]は、従来のIP処理を迂回させるATM構内機関車を使用することで入って来るパケットを進めることができます。 イングレスインターフェース情報があるイングレスVPI/VCI価値によると、CSRは出口のインタフェースと出口VPI/VCI価値を測定します。
In order to configure the cut-through packet forwarding state, a pair of neighbor nodes have to share the mapping information between the packet flow and the datalink VC. FANP (Flow Attribute Notification Protocol) described in this memo is the protocol to configure and manage the cut-through packet forwarding state.
深く切っているパケット推進状態を構成するために、1組の隣人ノードはパケット流動とデータリンクVCの間のマッピング情報を共有しなければなりません。 このメモで説明されたFANP(流れAttribute Notificationプロトコル)は深く切っているパケット推進状態を構成して、経営するプロトコルです。
2. Protocol Requirements and Future Enhancement
2. プロトコル要件と今後の増進
2.1 Protocol Requirements
2.1 プロトコル要件
The followings are the protocol requirements for FANP.
従、はFANPのためのプロトコル要件です。
(1) Applicable to various types of CO datalink platforms
様々なタイプのCOデータリンクプラットホームへの適切な(1)
(2) Available with various connection types (i.e., SVC, PVC, VP)
様々な結合方式がいる利用可能な(2)(すなわち、SVC、PVC、VP)
(3) Robust operation
The system should operate correctly even under the following
conditions.
(3) システムが以下の条件さえのもとで正しく操作するはずである体力を要している操作。
(a) VC failure
Some systems can detect VC failure as the function of
datalink (e.g., OAM function in the ATM). However, we can
not assume all nodes in the system can detect VC failure.
The system has to operate correctly, assuming that every
node can not detect VC failure.
(a) VC失敗Someシステムはデータリンクの機能としてVCの故障を検出できます(例えば、OAMはATMで機能します)。 しかしながら、私たちは、システムのすべてのノードがVCの故障を検出できると思うことができません。 あらゆるノードがVCの故障を検出できるというわけではないと仮定して、システムは正しく作動しなければなりません。
(b) Message loss
Control messages in the FANP may be lost. The system has to
operate correctly, even when some control messages are lost.
(b) FANPのメッセージ損失Controlメッセージは失われるかもしれません。 いくつかのコントロールメッセージが無くなるときさえ、システムは正しく作動しなければなりません。
(c Node failure
A node may be down without any explicit notification to its
neighbors. The system has to operate correctly, even with
node failure.
隣人にはcノード障害Aノードが少しも明白な通知なしであるかもしれません。(システムは正しく作動しなければなりません、ノード障害がいても。
Though FANP is not the protocol only for ATM, the following discussion assumes that the datalink is an ATM network.
FANPはATMのためだけのプロトコルではありませんが、以下の議論は、データリンクがATMネットワークであると仮定します。
Nagami, et. al. Informational [Page 2] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [2ページ]情報のRFC2129FANP仕様1997年4月
2.2 Future Enhancement
2.2 今後の増進
The followings are the future enhancements to be done.
従、は行われる今後の増進です。
(1) Aggregated flow
(1) 集められた流れ
In this memo, we define the flow which contain source and
destination IP address. As this may require many VC
resources, we also need a new definition of aggregated flow
which includes several end-to-end flows. The concrete
definition of the aggregated flow is for future study.
このメモでは、私たちはどれがソースを含んでいるか、そして、目的地IPが記述する流れを定義します。 また、これが多くのVCリソースを必要とするとき、私たちは数回の終わりから終わりへの流れを含んでいる集められた流れの新しい定義を必要とします。 今後の研究には集められた流れの具体的な定義があります。
(2) Providing multicast service
(3) Supporting IP level QOS signaling like RSVP
(4) Supporting IPv6
(2) RSVP(4)のようにIPv6を支持しながら合図するIPレベルQOSを支持しながら、マルチキャストサービス(3)を提供すること。
3. Terminology and Definition
3. 用語と定義
o VCID (Virtual Connection IDentifier)
Since VPI/VCI values at the origination and the termination points
of a VC (and VP) may not be the same, we need an identifier to
uniquely identify the datalink connection between neighbor nodes.
We define this identifier as a VCID. Currently, only one type of
VCID is defined. This VCID contains the ESI (End System
Identifier) of a source node and the unique identifier within a
source node.
o 創作におけるVPI/VCI値とVC(そして、VP)の終了先以来のVCID(仮想のConnection IDentifier)が同じでないかもしれない、私たちは唯一隣人ノードの間のデータリンク接続を特定するために識別子を必要とします。 私たちはこの識別子をVCIDと定義します。 現在、VCIDの1つのタイプだけが定義されます。 このVCIDはソースノードの中にソースノードとユニークな識別子のESI(終わりのSystem Identifier)を含んでいます。
o Flow ID (Flow IDentifier)
IP level packet flow is identified by some parameters in a packet.
Currently, only one type of flow ID is defined. This flow ID
contains a source IP address and a destination IP address. Note
that flow ID used in this specification is not the same as the
flow-id specified in IPv6.
o 流れID(流れIDentifier)のIPの平らなパケット流動はパケットのいくつかのパラメタによって特定されます。 現在、1つのタイプの流れIDだけが定義されます。 この流れIDはソースIPアドレスと送付先IPアドレスを含んでいます。 流れイドがIPv6で指定したようにIDがこの仕様で使用した流れが同じでないことに注意してください。
o Cut-through packet forwarding
Packets are forwarded without any IP processing at the router
using the datalink level information (e.g.,VPI/VCI).
Internetworking level information (e.g., destination IP address)
is mapped to the corresponding datalink-level identifier by using
the FANP.
o 少しもIP処理なしでルータでデータリンクレベル情報(例えば、VPI/VCI)を使用することで深く切っているパケット推進Packetsを進めます。 インターネットワーキングレベル情報(例えば、送付先IPアドレス)は、FANPを使用することによって、対応するデータリンクレベル識別子に写像されます。
o Hop-by-Hop packet forwarding
Packets are forwarded using IP level information like conventional
routers. In ATM, cells are re-assembled into packets at the
router to analyze the IP header.
o 従来のルータのようにIPの平らな情報を使用することでホップごとのパケット推進Packetsを進めます。 ATMでは、セルは、IPヘッダーを分析するためにルータでパケットに組み立て直されます。
Nagami, et. al. Informational [Page 3] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [3ページ]情報のRFC2129FANP仕様1997年4月
o Default-VC
Default-VC is used for hop-by-hop packet forwarding. Cells
received from the Default-VC are reassembled into IP packets.
Conventional IP processing is performed for these packets. The
encapsulation over the Default-VC is LLC for routed non-ISO
protocols defined by RFC1483 [3].
o デフォルト-VC Default-VCはホップごとのパケット推進に使用されます。 Default-VCから受け取られたセルはIPパケットに組み立て直されます。 従来のIP処理はこれらのパケットのために実行されます。 Default-VCの上のカプセル化はRFC1483[3]によって定義された発送された非ISOプロトコルのためのLLCです。
o Dedicated-VC
Dedicated-VC is used for the specific IP packet flow identified by
the flow-ID. When the flow-ID for an incoming VC and an outgoing
VC are the same at a CSR, it can forward the packets belonging to
the flow through the cut-through packet forwarding. The
encapsulation over the Dedicated-VC is LLC for routed non-ISO
protocols defined by RFC1483 [3].
o 専用VC Dedicated-VCは流れIDによって特定された特定のIPパケット流動に使用されます。 入って来るVCのための流れIDと出発しているVCがCSRで同じであるときに、それは深く切っているパケット推進で流れに属すパケットを進めることができます。 Dedicated-VCの上のカプセル化はRFC1483[3]によって定義された発送された非ISOプロトコルのためのLLCです。
o Cut-through trigger
When a FANP capable node receives a trigger packet, it tries to
establish Dedicated-VC and to notify the mapping information
between the Dedicated-VC and the IP packet flow which the received
trigger packet belongs to. Trigger packets are defined by the
port-ID of TCP/UDP with the local policy of each FANP capable
node. In general, they would be the port-ID's of sessions with a
long life-time and/or with large amount of packets; e.g., http,
ftp and nntp. Future implementation will include other triggers
such as an arrival of resource reservation request.
o 深く切っているよりこぎれいなWhen a FANPできるノードが引き金のパケットを受けて、それは、Dedicated-VCを設立して、容認された引き金のパケットが属すDedicated-VCとIPパケット流動の間のマッピング情報に通知しようとします。 引き金のパケットはTCP/UDPのポートIDによってそれぞれのFANPのできるノードのローカルの方針で定義されます。 一般に、それらは長い生涯多量のパケットとのセッションについてIDのものを移植するでしょう。 例えば、http、ftp、およびnntp。 今後の実現はリソース予約の要請の到着などの他の引き金を含むでしょう。
4. Protocol Overview
4. プロトコル概観
Figure 1 shows an operational overview of FANP. In the figure, a cut-through packet forwarding path is established from host 1 (H1) to host 2 (H2) using two Dedicated-VCs. H1 and H2 are connected to Ethernets, and R1, R2 and R3 are routers which can speak FANP. R1 and R3 have both an ATM interface and an Ethernet interface. R2 has two ATM interfaces.
図1はFANPの操作上の概観を示しています。 図に、深く切っているパケット推進経路は、2Dedicated-VCsを使用することでホスト1(H1)からホスト2(H2)まで確立されます。 H1とH2はEthernetsに接続されます、そして、R1、R2、およびR3はFANPを話すことができるルータです。 R1とR3には、ATMインタフェースとイーサネットインタフェースの両方があります。 R2には、2つのATMインタフェースがあります。
When R1 receives an IP packet from H1, R1 analyzes the payload of the received IP packet whether it is a trigger packet or not. When the received packet is a trigger packet, R1 fetches a Dedicated-VC to its downstream neighbor(R2) and sends FANP messages. FANP is effective between the neighboring nodes only. The same procedure would be performed between R2 and R3 independently from the procedure between R1 and R2. The flow-ID of the packet flow from H1 to H2 is represented as id(H1,H2). Here, id(H1,H2) is the set of the IP address of H1 and that of H2.
R1がH1からIPパケットを受けるとき、R1はそれが引き金のパケットであるか否かに関係なく、容認されたIPパケットのペイロードを分析します。 容認されたパケットが引き金のパケットであるときに、R1は川下の隣人(R2)にDedicated-VCをとって来て、メッセージをFANPに送ります。 FANPは隣接しているノードだけの間で有効です。 同じ手順はR2とR3の間でR1とR2の間の手順から独自に実行されるでしょう。 H1からH2までのパケット流動の流れIDはイド(H1、H2)として表されます。 ここで、イド(H1、H2)はH1のIPアドレスとH2のもののセットです。
Nagami, et. al. Informational [Page 4] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [4ページ]情報のRFC2129FANP仕様1997年4月
The Dedicated-VC is released when no packet is transferred on it for a given period. We do not need to explicitly indicate release of the Dedicated-VC to the neighbor node, since the state management in FANP is of soft-state, rather than of hard-state.
与えられた期間それでパケットを全く移さないとき、Dedicated-VCをリリースします。 私たちは明らかにDedicated-VCのリリースを隣人ノードに示す必要はありません、FANPの国家管理が固い状態についてというよりむしろ軟性国家のものであるので。
+--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+
|H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
+--+ +--+ +-----+ +--+ +-----+ +--+ +--+
trigger pkt
|----------> trigger packet
|-------------> trigger packet
FANP |--------------> trigger pkt
<=============> FANP |----------->
<==============>
+--+ イーサネット+--+ +-----+ +--+ +-----+ +--+ イーサネット+--+|H1|----------|R1|---| 気圧|---|R2|---| 気圧|---|R3|----------|H2| +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ 引き金のpkt|---------->引き金のパケット|------------->引き金のパケットFANP|-------------->引き金のpkt<。=============>FANP|-----------><=======>。
|=============|
Dedicated-VC |==============|
Dedicated-VC
|=============| 専用VC|==============| 専用VC
Figure 1. Trigger packet and FANP initiation
図1。 引き金のパケットとFANP開始
5. Protocol Sequence
5. プロトコル系列
FANP has the following five procedures, that are (1) Dedicated-VC selection, (2) VCID negotiation, (3) flow-ID notification, (4) Dedicated-VC refresh and (5) Dedicated-VC release. Procedures (2), (3) and (4) have nothing to do with the kind of the Dedicated- VC;i.e.,SVC,PVC or VP. On the contrary, the procedures (1) and (5) with SVC are different from the procedures with PVC and with VP.
FANPには、以下の5つの手順があって、それは(1)専用VC選択です、(2)VCID交渉、(3)流れID通知、専用VCがリフレッシュして、(5)の専用VCがリリースする(4)。 手順(2)、(3)、および(4)はDedicated- VCの種類と関係ありません; すなわち、SVC、PVCまたはVP。 これに反して、SVCがある手順(1)と(5)はPVCとVPについて手順と異なっています。
The detailed procedures are described in the following subsections.
詳細手順書は以下の小区分で説明されます。
5.1 Dedicated-VC Selection Procedure
5.1専用VC選択手順
A VC is picked up in order to use as a Dedicated-VC. The ways of picking up the Dedicated-VC is either of the followings.
VCは、aとしてDedicated-VCを使用するために拾われます。 Dedicated-VCを拾う方法は従のどちらかです。
(1) A number of VCs are prepared in advance, and registered into an
un-used VC list. When a Dedicated-VC is needed, one of them is
picked up from the un-used VC list.
(1) 多くのVCsが未使用のVCリストの中にあらかじめ準備されて、登録されます。 Dedicated-VCが必要であるときに、それらの1つは未使用のVCリストから拾われます。
(2) A new VC is established through ATM signaling on demand.
(2) 新しいVCは要求に応じてATMシグナリングを通して設立されます。
With ATM PVC/VP configuration, a Dedicated-VC is activated by the procedure (1).
ATM PVC/VP構成で、Dedicated-VCは手順(1)で動きます。
Nagami, et. al. Informational [Page 5] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [5ページ]情報のRFC2129FANP仕様1997年4月
With ATM SVC configuration, a Dedicated-VC is activated by the procedure (1) or (2). When the procedure (1) is used, some number of VCs are prepared in advance through ATM signaling. These VCs are registered into the un-used VC list. When a Dedicated-VC is needed, a VC is picked up from the un-used VC list. When the procedure (2) is used, a Dedicated-VC is established through ATM signaling each time it is required.
ATM SVC構成で、Dedicated-VCは手順(1)か(2)で動きます。 手順(1)が使用されているとき、VCsの何らかの数があらかじめ、ATMシグナリングを通して準備されます。 これらのVCsは未使用のVCリストの中に登録されます。 Dedicated-VCが必要であるときに、VCは未使用のVCリストから拾われます。 手順(2)が使用されているとき、それが必要であるたびにDedicated-VCはATMシグナリングを通して設立されます。
The procedure (1) can decrease a time to activate a Dedicated-VC. But the necessary VC resource will increase as it need to prepare additional VCs. Which procedure should be applied to is a matter of local decision in each node, taking the economical requirement and the system responsiveness into account.
手順(1)はDedicated-VCを動かす時間を減少させることができます。 しかし、追加VCsを準備するのが必要であるのに従って、必要なVCリソースは増加するでしょう。 経済的な要件とシステムの反応性をアカウントに取って、手順がどれに適用されるべきであるかは、各ノードにおけるローカルの決定の問題です。
A Dedicated-VC is used as a uni-directional VC, although it is generally bi-directional. This means that packets are transferred only from upstream node to downstream node in the Dedicated-VC. The packets from downstream node to upstream node are transferred through the Default-VC or through another Dedicated-VC.
それは一般に双方向ですが、Dedicated-VCはuni方向のVCとして使用されます。 これは、パケットがDedicated-VCで上流のノードだけから川下のノードまで移されることを意味します。 Default-VCを通して、または、別のDedicated-VCを通して川下のノードから上流のノードまでのパケットを移します。
5.2 VCID Negotiation Procedure
5.2VCID交渉手順
After the Dedicated-VC selection procedure, the upstream node transmits the PROPOSE message to the downstream node through the Dedicated-VC. The PROPOSE message contains a VCID for the Dedicated-VC and IP address (target IP address) of downstream node. When the downstream node accepts the PROPOSE message, it transmits the PROPOSE ACK message to the upstream node through the Default-VC. With this procedure, the upstream and the downstream nodes (both end-points of the Dedicated-VC) can share the same indicator "VCID" for the Dedicated-VC. When the downstream node can not accept the proposal from the upstream node with some reason (e.g., policy), the downstream node sends an ERROR message to the upstream node through the Default-VC.
Dedicated-VC選択手順の後に、上流のノードはDedicated-VCを通してPROPOSEメッセージを川下のノードに送ります。 PROPOSEメッセージは川下のノードのDedicated-VCとIPアドレス(目標IPアドレス)のためのVCIDを含んでいます。 川下のノードがPROPOSEメッセージを受け入れるとき、それはDefault-VCを通してPROPOSE ACKメッセージを上流のノードに送ります。 この手順と、上流と川下のノード(Dedicated-VCの両方のエンドポイント)は専用VCのために同じインディケータ"VCID"を共有できます。 川下のノードが何らかの理由(例えば、方針)で上流のノードから提案を受け入れることができないとき、川下のノードはDefault-VCを通してERRORメッセージを上流のノードに送ります。
The procedure at the downstream node which has received PROPOSE message is;
PROPOSEメッセージを受け取った川下のノードにおける手順はそうです。
1. if(Target IP address of the PROPOSE message isn't equal to my IP
address)
then Goto end.
1. 次に、(PROPOSEメッセージの目標IPアドレスは私のIPアドレスと等しくはありません)ゴトーであるなら、終わってください。
2. if(The PROPOSE message should be refused)
then Send an ERROR(refuse by policy) message. Go to end.
2. 次に、(PROPOSEメッセージは拒否されるべきです)Sendであるなら、ERROR(方針で、拒否する)は通信します。 終わりに行ってください。
3. if(VCID Type in the PROPOSE message isn't known)
then Send an ERROR(unknown VCID Type) message. Go to end.
3. 次に、(PROPOSEメッセージのVCID Typeは知られていません)Sendであるなら、ERROR(未知のVCID Type)は通信します。 終わりに行ってください。
Nagami, et. al. Informational [Page 6] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [6ページ]情報のRFC2129FANP仕様1997年4月
4. if(The VCID in the PROPOSE message is the same as the VCID which
has already been registered for another Dedicated-VC in the node)
then Delete the registered VCID.
Release the old Dedicated-VC.
4. 次に、(PROPOSEメッセージのVCIDはノードの別のDedicated-VCのために既に登録されたVCIDと同じです)Deleteの登録されたVCIDであるなら。 古いDedicated-VCをリリースしてください。
5. if(A VCID is registered for the Dedicated-VC which has received
the PROPOSE message)
then Delete the registered VCID.
5. 次に、(VCIDはPROPOSEメッセージを受け取ったDedicated-VCのために登録されます)Deleteの登録されたVCIDであるなら。
6. Register the mapping between VCID and I/F, VPI, VCI for the
Dedicated-VC.
6. Dedicated-VCのためにVCIDとI/F、VPI、VCIの間にマッピングを登録してください。
7. if(The mapping is successful)
then Send a PROPOSE ACK.
else Send an ERROR(resource unavailable).
7. Send a PROPOSE ACK次に、(マッピングはうまくいっています)ほかのSendである、ERROR(入手できないリソース)。
The upstream node retransmits the PROPOSE message when it neither receive PROPOSE ACK message nor ERROR message. When the upstream node has received neither of the messages even with five retransmissions of the PROPOSE message, the Dedicated-VC picked up through the Dedicated-VC selection procedure should be released. Here, the number of retransmissions (five in this specification)is recommended value and can be modified in the future.
どちらもPROPOSE ACKメッセージを受け取らないとき、上流のノードはPROPOSEメッセージを再送します。または、ERRORメッセージ。 上流のノードがPROPOSEメッセージの5「再-トランスミッション」があってもメッセージのどちらも受けていないとき、Dedicated-VC選択手順で拾われたDedicated-VCはリリースされるべきです。 ここで、「再-トランスミッション」(この仕様による5)の数は、推奨値であり、将来、変更できます。
The purpose of the VCID negotiation procedure is not only to share the VCID information regarding the Dedicated-VC, but also to confirm whether the Dedicated-VC is available and whether the neighbor node operates correctly.
VCID交渉手順の目的は単にDedicated-VCのVCID情報を共有するのではなく、Dedicated-VCが利用可能であるかどうかと、隣人ノードが作動するかどうか正しく確認もすることです。
If the VCID negotiation procedure with a neighbor node always fails, it is considered that the node may not be FANP-capable node. Therefore the upstream node should not try the VCID negotiation procedure to that node for a certain time period.
隣人ノードがあるVCID交渉手順がいつも失敗するなら、ノードがFANPできるノードでないかもしれないと考えられます。 したがって、上流のノードはある期間、VCID交渉手順をそのノードに試みるはずがありません。
5.3 Flow-ID Notification Procedure
5.3流れID通知手順
After the VCID negotiation procedure, the upstream node transmits an OFFER message to the downstream node through the Default-VC. The OFFER message contains the VCID of the Dedicated-VC, the flow-ID of the packet flow transferred through the Dedicated-VC and the refresh interval of a READY message.
VCID交渉手順の後に、上流のノードはDefault-VCを通してOFFERメッセージを川下のノードに送ります。 そして、OFFERメッセージはDedicated-VCのVCIDを含んでいます、Dedicated-VCを通して移されたパケット流動の流れID、READYメッセージの間隔をリフレッシュしてください。
When the downstream node receives the OFFER message from the upstream node, it transmits the READY message to the upstream node through the Default-VC in order to indicate that the OFFER message issued by the upstream node is accepted. By the reception of the READY message, the upstream node realizes that the downstream node can receive IP packets transferred through the Dedicated-VC.
川下のノードが上流のノードからOFFERメッセージを受け取るとき、それは、上流のノードによって発行されたOFFERメッセージが受け入れられるのを示すためにDefault-VCを通してREADYメッセージを上流のノードに送ります。 READYメッセージのレセプションで、上流のノードは、川下のノードがDedicated-VCを通して移されたIPパケットを受けることができるとわかります。
Nagami, et. al. Informational [Page 7] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [7ページ]情報のRFC2129FANP仕様1997年4月
The upstream node retransmits the OFFER message when it does not receive a READY message from the downstream node. When the upstream node has not receive a READY message even with five retransmissions, the Dedicated-VC should be released. Here, the number of retransmissions (i.e., five in this specification) is a recommended value and may be modified in the future.
川下のノードからREADYメッセージを受け取らないとき、上流のノードはOFFERメッセージを再送します。 上流のノードがそうしていないとき、5「再-トランスミッション」があってもREADYメッセージを受け取ってください、そして、Dedicated-VCはリリースされるべきです。 ここで、「再-トランスミッション」(すなわち、この仕様による5)の数は、推奨値であり、将来、変更されるかもしれません。
The node transmits an ERROR message to its neighbor in the following cases. When the node receives the ERROR message, the Dedicated-VC should be released.
ノードは以下の場合における隣人にERRORメッセージを送ります。 ノードがERRORメッセージを受け取るとき、Dedicated-VCはリリースされるべきです。
(a) unknown VCID: The VCID in the message is unknown.
(b) unknown VCID Type: The VCID Type is unknown.
(c) unknown flow-ID Type: the flow-ID Type is unknown.
(a) 未知のVCID: メッセージのVCIDは未知です。 (b) 未知のVCID Type: VCID Typeは未知です。 (c) 未知の流れID Type: 流れID Typeは未知です。
When the downstream node accepts the OFFER message from the upstream node, it must send a READY message to the upstream node within the refresh interval offered by the upstream node. If it can not, the downstream node sends the ERROR message (this refresh interval is not supported) to the upstream node. The downstream node should accept the refresh interval larger than 120 seconds. Therefore the downstream node shouldn't send the ERROR message (this refresh interval is not supported) when the refresh interval in the OFFER message is larger than 120 seconds.
いつ川下のノードが上流のノードからOFFERメッセージを受け入れて、READYメッセージを上流のノードに送らなければならないか、上流のノードによって提供された間隔をリフレッシュしてください。 それがそうすることができないなら、川下のノードがERRORメッセージを送る、(これがリフレッシュする、間隔が支持されない、)、上流のノードに。 川下のノードが受け入れるはずである、120秒より大きい間隔をリフレッシュしてください。 したがって、川下のノードがERRORメッセージを送るはずがない、(これがリフレッシュする、間隔が支持されない、)、いつ、OFFERが通信させるコネが120秒より大きい間隔をリフレッシュしてくださいか。
The following describes the procedure of the node which has received an OFFER message.
以下はOFFERメッセージを受け取ったノードの手順について説明します。
1. if(unknown version in the OFFER message)
then Discard the message. Goto end.
1. 次に、(OFFERメッセージの未知のバージョン)Discardである、メッセージ。 ゴトー終わり。
2. if(unknown VCID Type in the OFFER message)
then Send an ERROR (unknown VCID Type) message. Goto end.
2. 次に、(OFFERメッセージの未知のVCID Type)Sendであるなら、ERROR(未知のVCID Type)は通信します。 ゴトー終わり。
3. if(VCID in the OFFER message has not been registered)
then Send an ERROR (unknown VCID) message. Goto end.
3. 次に、(OFFERメッセージのVCIDは登録されていません)Sendであるなら、ERROR(未知のVCID)は通信します。 ゴトー終わり。
4. if(unknown Flow ID Type in the OFFER message)
then Send an ERROR (unknown Flow ID Type) message. Goto end.
4. 次に、(OFFERメッセージの未知のFlow ID Type)Sendであるなら、ERROR(未知のFlow ID Type)は通信します。 ゴトー終わり。
5. if(refuse Flow ID in the OFFER message)
then Send an ERROR (refused by policy) message. Goto end.
5. 次に、(OFFERメッセージのIDをFlowに拒否します)Sendであるなら、ERROR(方針によって拒否される)は通信します。 ゴトー終わり。
6. if(refuse refresh interval in the OFFER message)
then Send an ERROR(This refresh interval is not supported)
message. Goto end.
6. 次に、(廃物はOFFERメッセージで間隔をリフレッシュします)Sendである、ERROR、(これがリフレッシュする、間隔が支持されない、)、メッセージ。 ゴトー終わり。
Nagami, et. al. Informational [Page 8] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [8ページ]情報のRFC2129FANP仕様1997年4月
7. if(the mapping between Flow ID and VCID already exists and
Flow ID in the OFFER message is different from the registered
Flow ID for the corresponding VCID)
then Do Flow-ID removal procedure. Goto end.
7. 次に、(Flow IDとVCIDの間のマッピングは既に存在しています、そして、対応するVCIDにおいて、OFFERメッセージのFlow IDは登録されたFlow IDと異なっています)Do Flow-ID取り外し手順であるなら。 ゴトー終わり。
8. Do the procedure of receiving the OFFER message.
8. OFFERメッセージを受け取る手順をしてください。
7. if(successful)
then Send a READY message.
else Send an ERROR (resource unavailable) message.
7. (うまくいく)の当時のSend a READYメッセージほかのSendであるなら、ERROR(入手できないリソース)は通信します。
8. end.
8. 終わってください。
The procedure of the node which has received a READY message is described.
READYメッセージを受け取ったノードの手順は説明されます。
1. if(unknown version in the READY message)
then Discard the message. Goto end.
1. 次に、(READYメッセージの未知のバージョン)Discardである、メッセージ。 ゴトー終わり。
2. if(unknown VCID Type in the READY message)
then Send an ERROR (unknown VCID Type) message. Goto end.
2. 次に、(READYメッセージの未知のVCID Type)Sendであるなら、ERROR(未知のVCID Type)は通信します。 ゴトー終わり。
3. if(VCID in the READY message has not been registered)
then Send an ERROR (unknown VCID) message. Goto end.
3. 次に、(READYメッセージのVCIDは登録されていません)Sendであるなら、ERROR(未知のVCID)は通信します。 ゴトー終わり。
4. if(unknown Flow ID Type in the READY message)
then Send an ERROR (unknown Flow ID Type) message. Goto end.
4. 次に、(READYメッセージの未知のFlow ID Type)Sendであるなら、ERROR(未知のFlow ID Type)は通信します。 ゴトー終わり。
5. if((the mapping between Flow ID and VCID doesn't exist)||
(the mapping between Flow ID and VCID already exists and
Flow ID in the READY message is different from registered Flow
ID for the corresponding VCID))
then Send an ERROR (unknown VCID) message. Goto end.
5. (Flow IDとVCIDの間のマッピングは存在していません)| | 次に、(Flow IDとVCIDの間のマッピングは既に存在しています、そして、対応するVCIDにおいて、READYメッセージのFlow IDは登録されたFlow IDと異なっています)Sendであるなら、ERROR(未知のVCID)は通信します。 ゴトー終わり。
6. Do the procedure of receiving the READY message.
6. READYメッセージを受け取る手順をしてください。
7. end.
7. 終わってください。
5.4 Flow ID Refresh Procedure
5.4 Flow IDは手順をリフレッシュします。
While the downstream node receives IP packets through the Dedicated- VC, it should periodically (with a refresh interval) send the READY message to the upstream node. When the downstream node does not receive any IP packet during the refresh interval, it does not send the READY message to the upstream node.
川下のノードがDedicated- VCを通してIPパケットを受けている間、それは定期的にREADYメッセージを上流のノードに送るべきです(aで、間隔をリフレッシュしてください)。 川下のノードがいつの間、どんなIPパケットも受けないか、間隔をリフレッシュしてください、そして、それはREADYメッセージを上流のノードに送りません。
Nagami, et. al. Informational [Page 9] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [9ページ]情報のRFC2129FANP仕様1997年4月
While the upstream node continues to receive READY messages, it realizes that it can transmit the IP packets through the Dedicated- VC. When it does not receive a READY message at all for a predetermined period (dead interval), it removes the mapping between the Flow IP and VCID. The dead interval is defined below.
上流のノードは、READYメッセージを受け取り続けていますが、Dedicated- VCを通してIPパケットを伝えることができるのは換金されます。 予定された期間(死んでいる間隔)全くREADYメッセージを受け取らないとき、それはFlow IPとVCIDの間にマッピングを取り除きます。 死んでいる間隔は以下で定義されます。
When the upstream node falls into failure without the Flow ID removal procedure for a Dedicated-VC, its mapping must be removed by the downstream node. The downstream node removes the mapping between the Flow ID and VCID for the Dedicated-VC when it does not receive any IP packet for a "removal period" (=refresh interval times m).
上流のノードがDedicated-VCのためのFlow ID取り外し手順なしで失敗になるとき、川下のノードでマッピングを取り除かなければなりません。 「取り外しの期間」の間どんなIPパケットも受けないとき(= 間隔回のmをリフレッシュしてください)、川下のノードはDedicated-VCのためにFlow IDとVCIDの間にマッピングを取り除きます。
The refresh interval, the dead interval and the removal period should satisfy the following equation.
間隔をリフレッシュしてください、そして、死んでいる間隔と取り外しの期間は以下の方程式を満たすべきです。
refresh interval < dead interval < removal period (=refresh
interval times m)
間隔の<の死んでいる間隔<取り外しの期間をリフレッシュしてください。(= 間隔回のmをリフレッシュしてください)
The recommended values are:
refresh interval = 2 minutes
dead interval = 6 minutes (=refresh interval x 3)
removal period = 20 minutes (=refresh interval x 10)
推奨値は以下の通りです。 =20分間死んでいる間隔=2分取り外しの期間の6分間(= 間隔x3をリフレッシュする)の間隔=をリフレッシュしてください。(= 間隔x10をリフレッシュしてください)
5.5 Flow ID Removal Procedure
5.5流れID取り外し手順
When the upstream node realizes that the Dedicated-VC is not used, it performs a Flow ID removal procedure.
上流のノードが、Dedicated-VCが使用されていないとわかるとき、それはFlow ID取り外し手順を実行します。
The Flow ID removal procedure differs between the case of PVC/VP configuration and the case of SVC configuration.
Flow ID取り外し手順はPVC/VP構成に関するケースとSVC構成に関するケースの間で異なります。
With the PVC/VP configuration, the upstream node issues a REMOVE message to the downstream node, and the downstream node sends back a REMOVE ACK message to the upstream node. The upstream node retransmits REMOVE messages when it does not receive a REMOVE ACK message. The upstream node assumes that the downstream node is in failure state when it dose not receive any REMOVE ACK message from the downstream node even with five REMOVE message retransmissions.
PVC/VP構成で、上流のノードは川下のノードへのメッセージを削除に発行します、そして、川下のノードは上流のノードにREMOVE ACKメッセージを返送します。 上流ノードは、削除を再送します。それがREMOVE ACKメッセージを受け取らないメッセージ。 上流のノードは、川下のノードがそれであるときに、失敗状態では、投与量が川下のノードから5があってもどんなREMOVE ACKメッセージも受け取らないということであると仮定します。削除、メッセージ「再-トランスミッション」。
Nagami, et. al. Informational [Page 10] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [10ページ]情報のRFC2129FANP仕様1997年4月
With SVC configuration, two procedures are possible. One is that the mapping between the Flow ID and the VCID is removed without the release of the ATM connection, which is the same procedure as the PVC/VP configuration. The other procedure is that the mapping between the Flow ID and the VCID is removed by releasing the VC through ATM signaling. The former procedure can promptly create and delete the mapping between Flow ID and VCID, since the ATM signaling does not have to be performed each time. However, an un-used ATM connections have to be maintained by the node. Which procedure is applied to is a matter of each CSR's local decision, taking the VC resource cost and responsiveness into account.
SVC構成では、2つの手順が可能です。 1つはFlow IDとVCIDの間のマッピングがPVC/VP構成と同じ手順であるATM接続の解放なしで取り除かれるということです。 もう片方の手順はFlow IDとVCIDの間のマッピングがATMシグナリングを通してVCをリリースすることによって取り除かれるということです。 前の手順は、即座にFlow IDとVCIDの間のマッピングを作成して、削除できます、ATMシグナリングがその都度実行される必要はないので。 しかしながら、未使用のATM接続はノードによって維持されなければなりません。 VCリソース費用と反応性を考慮に入れて、手順がどれに適用されているかは、各CSRのローカルの決定の問題です。
The downstream node may want to remove the mapping between the Flow ID and the VCID. When the upstream node receives the REMOVE message, it sends a REMOVE ACK message to the downstream node.
川下のノードはFlow IDとVCIDの間にマッピングを取り除きたがっているかもしれません。 上流のノードが受信する、削除、通信してください、そして、それはREMOVE ACKメッセージを川下のノードに送ります。
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| PROPOSE |
|===============================>|
VCID | [VCID, target IP] |
negotiation | PROPOSE ACK |
|<===============================|
| [VCID] |
| |
| OFFER |
|===============================>|
Flow-ID | [VCID, flow-ID] |
notification | READY |
|<===============================|
| [VCID, flow-ID] |
| |
: : :
: : :
| READY |
|<===============================|
Dedicated-VC | [VCID, flow-ID] |
refresh | READY |
|<===============================|
| [VCID, flow-ID] |
+--+ +--+ |R1|------------------------------|R2| +--+ +--+ | 提案してください。| |===============================>| VCID| [VCID、目標IP]| 交渉| ACKを提案してください。| |<================| | [VCID]| | | | 申し出| |===============================>| 流れID| [VCID、流れID]| 通知| 準備ができる| |<================| | [VCID、流れID]| | | : : : : : : | 準備ができる| |<================| 専用VC| [VCID、流れID]| リフレッシュしてください。| 準備ができる| |<================| | [VCID、流れID]|
Figure 2. Flow ID notification and refresh procedure
図2。 流れID通知、手順をリフレッシュしてください。
Nagami, et. al. Informational [Page 11] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [11ページ]情報のRFC2129FANP仕様1997年4月
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| |
| REMOVE |
|================================>|
| [VCID] |
| |
| REMOVE ACK |
|<================================|
| [VCID] |
+--+ +--+ |R1|------------------------------|R2| +--+ +--+ | | | 削除| |================================>|、| [VCID]| | | | ACKを取り外してください。| |<================| | [VCID]|
(a) Flow ID removal (independent of ATM signaling)
(a) 流れID取り外し(ATMシグナリングから独立する)です。
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| ATM signaling |
| (release) |
|<===============================>|
| |
+--+ +--+ |R1|------------------------------|R2| +--+ +--+ | ATMシグナリング| | (リリース) | |<================>|、|、|
(b) Flow ID removal through ATM signaling
(b) ATMシグナリングを通した流れID取り外し
Figure 3. Flow ID removal procedure
図3。 流れID取り外し手順
6. Message Format
6. メッセージ・フォーマット
FANP control procedure includes seven messages described from 6.2 to 6.8. Among them, a PROPOSE message used for VCID negotiation procedure uses an extended ATM ARP message format defined in RFC1577 [2]. The other messages are encapsulated into IP packets.
FANPコントロール手順は6.2〜6.8まで説明された7つのメッセージを含んでいます。 それらの中では、PROPOSEメッセージはVCID交渉手順用途にRFC1577[2]で定義された拡張ATM ARPメッセージ・フォーマットを使用しました。 他のメッセージはIPパケットにカプセル化されます。
The destination IP address in the IP packet header signifies the neighbor node's IP address and the source IP address signifies sender's IP address. Currently, the protocol ID for these messages is 110(decimal). This protocol ID must be registered by IANA.
IPパケットのヘッダーの送付先IPアドレスは隣人ノードのIPアドレスを意味します、そして、ソースIPアドレスは送付者のIPアドレスを意味します。 現在、これらのメッセージのためのプロトコルIDは110(10進)です。 IANAはこのプロトコルIDを登録しなければなりません。
The reserved field in the following packet format must be zero.
以下のパケット・フォーマットの予約された分野はゼロであるに違いありません。
Nagami, et. al. Informational [Page 12] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [12ページ]情報のRFC2129FANP仕様1997年4月
6.1 Field Format
6.1 フィールド形式
6.1.1 VCID field
6.1.1 VCID分野
VCID type value decides VCID field format. Currently, only type "1" is defined. The VCID field format of VCID type 1 is shown below.
VCIDタイプ価値はVCIDフィールド形式について決めます。 現在、単にタイプしてください。「1インチは定義されます」。 VCIDタイプ1のVCIDフィールド形式は以下に示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESI of upstream node |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 上流のノードのESI| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESI field: ESI of upstream node
ID : upstream node decides unique identifier.
ESIは以下をさばきます。 上流のノードIDのESI: 上流のノードはユニークな識別子について決めます。
6.1.2 Flow ID field
6.1.2 流れID分野
Flow ID type value decides flow-ID field format. Currently, flow-ID type "0" and "1" are defined. The flow ID type value "0" signifies that the flow ID field is null. When flow ID type value is "1", the format shown below is used.
流れIDタイプ価値は流れIDフィールド形式について決めます。 現在の流れIDタイプ、「0インチと「1インチは定義されます」。 流れIDは値をタイプします。「0インチは、流れID分野がヌルであることを意味します」。 流れIDタイプ価値が「以下に示された書式は何1インチも使用されている」とき。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP address : source IP address of flow
Destination IP address : destination IP address of flow
ソースIPアドレス: 流れDestination IPアドレスのソースIPアドレス: 流れの送付先IPアドレス
6.2 PROPOSE message
6.2 PROPOSEメッセージ
PROPOSE message uses the extended ATM-ARP message format [2] to which the VCID type and the VCID field are added. Type & Length fields are set to zero, because the messages don't need sender/target ATM address. This message is transferred from the upstream node to the downstream node through the Dedicated-VC.
VCIDがタイプする拡張ATM-ARPメッセージ・フォーマット[2]とVCIDがさばくPROPOSEメッセージ用途は加えられます。 メッセージが送付者/目標ATMアドレスを必要としないので、タイプとLength分野はゼロに用意ができています。 Dedicated-VCを通して上流のノードから川下のノードまでこのメッセージを移します。
PROPOSE message is transferred from the upstream node to the downstream node through the Dedicated-VC.
Dedicated-VCを通して上流のノードから川下のノードまでPROPOSEメッセージを移します。
Nagami, et. al. Informational [Page 13] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [13ページ]情報のRFC2129FANP仕様1997年4月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type = 0x13 | Protocol Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type&Length 1 | Type&Length 2 | Opereation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length 1 | Type&Length 3 | Type&Length 4 | Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Type |VCID Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハードウェアタイプ=0x13| プロトコルタイプ=0x0800| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプと長さ1| タイプと長さ2| Opereationコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ1| タイプと長さ3| タイプと長さ4| 長さ2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|VCIDの長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type&Length 1 ; Type & Length of sender ATM number = 0
Type&Length 2 ; Type & Length of sender ATM subnumber = 0
Type&Length 3 ; Type & Length of sender ATM number = 0
Type&Length 4 ; Type & Length of sender ATM subnumber =0
Length 1 ; Source IP address length
Length 2 ; Target IP address length
タイプと長さ1。 タイプしてください。そうすれば、送付者ATM番号のLengthは0Type&Length2と等しいです。 タイプしてください。そうすれば、送付者ATM subnumberのLengthは0Type&Length3と等しいです。 タイプしてください。そうすれば、送付者ATM番号のLengthは0Type&Length4と等しいです。 タイプしてください。そうすれば、送付者ATM subnumberのLengthは0Length1と等しいです。 ソースIPアドレス長さLength2。 目標IPアドレスの長さ
Operation code
0x10 = PROPOSE
命令コード0x10はPROPOSEと等しいです。
VCID Type: Currently , VCID Type = 1 is defined.
VCID Length: Length of VCID field
VCID : VCID described previous
VCIDはタイプします: 現在、VCID Type=1は定義されます。 VCIDの長さ: VCID分野VCIDの長さ: 前であることの状態で説明されたVCID
6.3 PROPOSE ACK
6.3はACKを提案します。
PROPOSE ACK messages is transferred through the Default-VC.
Default-VCを通してPROPOSE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Op code = 1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン|オペコード=1| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ=0| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 14] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [14ページ]情報のRFC2129FANP仕様1997年4月
Version
This field indicates the version number of FANP. Currently,
Version = 1
ThisがさばくバージョンはFANPのバージョン番号を示します。 現在のバージョン=1
Operation Code
命令コード
This field indicates the operation code of the message. There
are five operation codes, below.
この分野はメッセージの命令コードを示します。 以下の5つの命令コードがあります。
operation code = 1 : PROPOSE ACK message
命令コード=1: PROPOSE ACKメッセージ
Checksum
This field is the 16 bits checksum for whole body of FANP message.
The checksum algorithm is same as the IP header.
ThisがさばくチェックサムはFANPメッセージの全身のための16ビットのチェックサムです。 チェックサムアルゴリズムはIPヘッダーと同じです。
VCID Type
This field indicates the VCID type. Currently, only "1" is
defined.
VCID Type This分野は、VCIDがタイプするのを示します。 現在、「1インチは定義されるだけです」。
6.4 OFFER message
6.4 OFFERメッセージ
OFFER message is transferred from an upstream node to a downstream node. The following is the message format.
上流のノードから川下のノードまでOFFERメッセージを移します。 ↓これはメッセージ・フォーマットです。
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 = 1 | Op Code = 2 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| オペコード=2| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ| 間隔をリフレッシュしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Refresh Interval
This field indicates the interval of refresh timer. The refresh
interval is represented by second in integer. This field is
used only in OFFER message. Recommended value is 120 (second).
分野が間隔を示すInterval Thisをリフレッシュしてください。タイマをリフレッシュしてください。 間隔をリフレッシュしてください。秒で、整数で表されます。 この分野はOFFERメッセージだけで使用されます。 推奨値は120(2番目)です。
Nagami, et. al. Informational [Page 15] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [15ページ]情報のRFC2129FANP仕様1997年4月
6.5 READY message
6.5 READYメッセージ
READY message is transfered from a downstream node to an upstream node. This message is transferred when the downstream node receives OFFER message. And this message is transferred periodically in each refresh interval. The following is the message format.
READYメッセージは川下のノードから上流のノードまでtransferedされます。 川下のノードがOFFERメッセージを受け取るとき、このメッセージはわたっています。 そして、移されたこのメッセージはそれぞれで定期的に間隔をリフレッシュします。 ↓これはメッセージ・フォーマットです。
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 = 1 | Op Code = 3 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| オペコード=3| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.6 ERROR message
6.6 ERRORメッセージ
ERROR message is transfered from a downstream node to an upstream node or from an upstream node to a downstream node. This message is transferred when some of the fields in the receive message is unknown or refused. When the receive message is the ERROR message, ERROR message isn't sent. VCID type ,VCID, Flow ID Type and Flow ID field in the ERROR message are filled with the same field in the receive message.
ERRORメッセージは川下のノードから上流のノードまで上流のノードから川下のノードまでtransferedされます。 このメッセージが分野のいくつかならわたっている、未知である、または拒否されたメッセージを受け取ってください。 受信してください。いつ、メッセージはERRORメッセージ、メッセージが送られないERRORであるか。 中に同じ分野がある状態でERRORメッセージのVCIDタイプ、VCID、Flow ID Type、およびFlow ID分野がいっぱいにされる、メッセージを受け取ってください。
The following is the message format.
↓これはメッセージ・フォーマットです。
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 = 1 | Op Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| オペコード=4| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ| エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 16] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [16ページ]情報のRFC2129FANP仕様1997年4月
Error Code = 1 : unknown VCID type
= 2 : unknown Flow-ID type
= 3 : unknown VCID
= 4 : resource is unavailable
= 5 : unavailable refresh interval is offered
= 6 : refuse by policy
誤りコード=1: 未知のVCIDは=2をタイプします: 未知のFlow-IDタイプ=3: 未知のVCID=4: リソースは入手できない=5です: リフレッシュしてください。入手できなさ、=6を間隔に提供します: 方針で、拒否してください。
6.7 REMOVE message
6.7に、削除、メッセージ
REMOVE message is transfered from a downstream node to an upstream node or vice versa. This message is transferred to remove the mapping relationship between the flow ID and and the VCID. The node which receives REMOVE message must send REMOVE ACK message, even when VCID in the receive message isn't known .
削除、メッセージはそうです。川下ノードから上流のノードまで逆もまた同様にtransferedしました。 そして、流れIDの間のマッピング関係を取り除くためにこのメッセージを移す、そして、VCID。 削除を受けるノードは通信します。メッセージを受け取ってください。必須がREMOVE ACKメッセージを送る、同等である、VCIDであるなら知られていません。
The following is the message format.
↓これはメッセージ・フォーマットです。
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 = 1 | Op Code = 5 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| オペコード=5| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.8 REMOVE ACK message
6.8 REMOVE ACKメッセージ
REMOVE ACK message is transferred from a downstream node to an upstream node or from an upstream node to a downstream node. The following is the message format.
川下のノードから上流のノードまで上流のノードから川下のノードまでREMOVE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | Op Code = 6 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン=1| オペコード=6| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCIDはタイプします。|流れIDタイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 17] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [17ページ]情報のRFC2129FANP仕様1997年4月
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. References
8. 参照
[1] Katsube, Y., Nagami, K., and H. Esaki, "Router Architecture
Extensions for ATM; overview", Work in Progress.
[1]Katsube、Y.、Nagami、K.、およびH.江崎、「気圧のためのルータアーキテクチャ拡大」。 「概要」、ProgressのWork。
[2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
October 1993.
[2]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、10月1993日
[3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[3] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
Ethernet is a registered trademark of Xerox Corp. All other product names mentioned herein may be trademarks of their respective companies.
イーサネットはAll他の製品が命名する社がここにそれらのそれぞれの会社の商標であるかもしれないと言及したゼロックスの登録商標です。
9. Authors' Addresses
9. 作者のアドレス
Ken-ichi Nagami R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : nagami@isl.rdc.toshiba.co.jp
健一Nagami研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: nagami@isl.rdc.toshiba.co.jp
Yasuhiro Katsube R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : katsube@isl.rdc.toshiba.co.jp
Yasuhiro Katsube研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: katsube@isl.rdc.toshiba.co.jp
Yasuro Shobatake R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 Email : masahata@csl.rdc.toshiba.co.jp
Yasuro Shobatake研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: masahata@csl.rdc.toshiba.co.jp
Akiyoshi Mogi R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : mogi@isl.rdc.toshiba.co.jp
秋吉茂木研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: mogi@isl.rdc.toshiba.co.jp
Nagami, et. al. Informational [Page 18] RFC 2129 FANP Specification April 1997
et Nagami、アル。 [18ページ]情報のRFC2129FANP仕様1997年4月
Shigeo Matsuzawa R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : shigeom@isl.rdc.toshiba.co.jp
Shigeo Matsuzawa研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: shigeom@isl.rdc.toshiba.co.jp
Tatsuya Jinmei R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : jinmei@isl.rdc.toshiba.co.jp
Tatsuya Jinmei研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: jinmei@isl.rdc.toshiba.co.jp
Hiroshi Esaki R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : hiroshi@isl.rdc.toshiba.co.jp
Hiroshi江崎研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: hiroshi@isl.rdc.toshiba.co.jp
Nagami, et. al. Informational [Page 19]
et Nagami、アル。 情報[19ページ]
一覧
スポンサーリンク
