RFC2176 日本語訳

Network Working Group                                        K. Murakami
Request for Comments: 2176                                   M. Maruyama
Category: Informational                                 NTT Laboratories
                                                               June 1997

コメントを求めるワーキンググループK.村上の要求をネットワークでつないでください: 2176年のM.丸山カテゴリ: 情報のNTT研究所1997年6月

                       IPv4 over MAPOS Version 1

MAPOSバージョン1の上のIPv4

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.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Authors' Note

作者の注意

   This memo documents a mechanism for supporting Version 4 of the
   Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol
   over SONET/SDH.  This document 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.

このメモは、Sonet/SDHの上でMultiple Accessプロトコルのバージョン1でインターネットプロトコル(IPv4)のバージョン4をサポートするためにメカニズムを記録します。 このドキュメントはIETFワーキンググループの製品ではありません、そして、それは標準化過程ドキュメントではありません。 必ず、標準化過程ドキュメントが受信されるのは広範囲の、そして、徹底的な共同体レビューから利益を得るというわけではありませんでした。

Abstract

要約

   This document describes a protocol for transmission of the Internet
   Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS)
   version 1. MAPOS is a link layer protocol and provides multiple
   access capability over SONET/SDH links. IP runs on top of MAPOS. This
   document explains IP datagram encapsulation in HDLC frame of MAPOS,
   and the Address Resolution Protocol (ARP).

このドキュメントはインターネットプロトコルバージョン4(IPv4)の送信のためにMultiple Access Over Sonet/SDH(MAPOS)バージョン1の上でプロトコルについて説明します。 MAPOSはリンクレイヤプロトコルであり、Sonet/SDHリンクの上に複数のアクセス能力を供給します。 IPをMAPOSの上で経営しています。 このドキュメントで、MAPOSのHDLCフレームのIPデータグラムカプセル化、およびAddress Resolutionプロトコル(ARP)がわかります。

1. Introduction

1. 序論

   Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed
   link-layer protocol that provides multiple access capability over
   SONET/SDH. Its frame format is based on the HDLC-like framing [2] for
   PPP.  A component called "Frame Switch" [1] allows multiple nodes to
   be connected together in a star topology to form a LAN. Using long
   haul SONET/SDH links, the nodes on such a "SONET-LAN" can span over a
   wide geographical area. The Internet Protocol (IP) [3] datagrams are
   transmitted in MAPOS HDLC frames [1].

Sonet/SDH(MAPOS)[1]の上の複数のAccessプロトコルがSonet/SDHの上に複数のアクセス能力を供給する高速リンク層プロトコルです。 フレーム形式はPPPのためのHDLCのような縁ど[2]りに基づいています。 「フレームスイッチ」[1]と呼ばれるコンポーネントで、複数のノードが、LANを形成するためにスタートポロジーで一緒に接続します。 長期Sonet/SDHリンクを使用して、そのような「Sonet-LAN」のノードは広い地理的な領域にわたってわたることができます。 インターネットプロトコル(IP)[3]データグラムはMAPOS HDLCフレーム[1]で送られます。

   This document describes a protocol for transmission of IP datagrams
   over MAPOS version 1 [1]. It explains IP datagram encapsulation in
   HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for
   mapping between IP address and HDLC address.

このドキュメントはIPデータグラムのトランスミッションのためにMAPOSバージョン1[1]の上でプロトコルについて説明します。 それで、IPアドレスとHDLCアドレスの間でMAPOSのHDLCフレーム、およびマッピングのためのARP(アドレスResolutionプロトコル)でIPデータグラムカプセル化がわかります。

Murakami & Maruyama          Informational                      [Page 1]

RFC 2176                         MAPOS                         June 1997

[1ページ]RFC2176MAPOS1997年6月の情報の村上と丸山

2. Frame Format for Encapsulating IP Datagrams

2. IPデータグラムをカプセル化するためのフレーム形式

   An IP datagram is transmitted in a MAPOS HDLC frame.  The protocol
   field of the frame must contain the value 0x0021 (hexadecimal) as
   defined by the "MAPOS Version 1 Assigned Numbers" [4].  The
   information field contains the IP datagram.

IPデータグラムはMAPOS HDLCフレームで送られます。 フレームのプロトコル分野は「MAPOSバージョン1規定番号」[4]によって定義されるように値0x0021の(16進)を含まなければなりません。 情報フィールドはIPデータグラムを含んでいます。

   The information field may be one to 65,280 octets in length; the
   MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets.  Although
   the large MTU size can suppress the overhead of IP header processing,
   it may cause fragmentation anywhere along the path from the source to
   the destination and result in performance degradation. To cope with
   the issue, Path MTU discovery [5] may be used.

情報フィールドは長さが1〜6万5280の八重奏であるかもしれません。 MAPOSのMTU(最大のTransmission Unit)は6万5280の八重奏です。 大きいMTUサイズはIPヘッダー処理のオーバーヘッドを抑圧できますが、それは経路に沿ってどこでも性能退行で断片化をソースから目的地と結果まで引き起こすかもしれません。 問題に対処するために、Path MTU発見[5]は使用されるかもしれません。

3. Address Mapping

3. アドレス・マッピング

   This section explains MAPOS ARP and the mapping of special addresses.

このセクションは特別なアドレスに関するMAPOS ARPとマッピングについて説明します。

3.1 ARP cache

3.1 ARPキャッシュ

   Each node on a MAPOS network maintains an "ARP cache" that maps
   destination IP addresses to their corresponding 8-bit HDLC addresses.
   Entries are added to this cache either manually or by the Address
   Resolution Protocol described below.  Entries are removed from this
   cache manually, by the UNARP mechanism, or by ARP cache validation
   mechanism.  An implementation must provide a mechanism for manually
   adding or removing arbitrary ARP cache entries.

MAPOSネットワークの各ノードはそれらの対応する8ビットのHDLCアドレスに送付先IPアドレスを写像する「ARPキャッシュ」を維持します。 エントリーは手動か以下で説明されたAddress Resolutionプロトコルによってこのキャッシュに加えられます。 UNARPメカニズム、またはARPキャッシュ合法化メカニズムはこのキャッシュからエントリーを手動で取り除きます。 実装は手動で任意のARPキャッシュエントリーを加えるか、または取り除くのにメカニズムを提供しなければなりません。

3.2 Address Resolution Protocol (ARP)

3.2 アドレス解決プロトコル(アルプ)

   This subsection describes MAPOS ARP protocol and its packet format.

この小区分はMAPOS ARPプロトコルとそのパケット・フォーマットについて説明します。

3.2.1 Overview

3.2.1 概要

   The MAPOS ARP is similar to that for ethernet.  Prior to sending an
   IP datagram, the node must know the destination HDLC address
   corresponding to the destination IP address. When its ARP cache does
   not contain the corresponding entry, it uses ARP to translate the IP
   address to the HDLC address. That is, it broadcasts an ARP request
   containing the destination IP address.  In response to the request,
   the node which has the IP address sends an ARP reply containing the
   HDLC address. The returned HDLC address is stored in the ARP cache.

イーサネットに、MAPOS ARPはそれと同様です。 IPデータグラムを送る前に、ノードは送付先IPアドレスに対応する送付先HDLCアドレスを知らなければなりません。 ARPキャッシュが対応するエントリーを含んでいないと、それは、IPアドレスをHDLCアドレスに翻訳するのにARPを使用します。 すなわち、それは送付先IPアドレスを含むARP要求を放送します。 要求に対応して、IPアドレスを持っているノードはHDLCアドレスを含むARP回答を送ります。 返されたHDLCアドレスはARPキャッシュで保存されます。

3.2.2 ARP Frame Format

3.2.2 ARPフレーム形式

   The protocol field for an ARP frame must contain 0xFE01 (hexadecimal)
   as defined by the "MAPOS Version 1 Assigned Numbers" [4]. The
   information field contains the ARP packet as shown below.

ARPフレームへのプロトコル分野は「MAPOSバージョン1規定番号」[4]によって定義されるように0xFE01(16進)を含まなければなりません。 情報フィールドは以下に示すようにARPパケットを含んでいます。

Murakami & Maruyama          Informational                      [Page 2]

RFC 2176                         MAPOS                         June 1997

[2ページ]RFC2176MAPOS1997年6月の情報の村上と丸山

           +-------------------------+------------------------+
           |  Hardware Address Space | Protocol Address Space |
           |       (25:MAPOS)        |     (2048 in Dec)      |
           |    16 bits              |   16 bits              |
           +------------+------------+------------------------+
           | Hard Addr  | Proto Addr |   Operation Code       |
           | Length (4) | Length (4) |(1:Request 2:Response)  |
           |   8 bits   |   8 bits   |         16 bits        |
           +------------+------------+------------------------+
           |    Sender HDLC Address        32 bits            |
           +--------------------------------------------------+
           |    Sender IP Address          32 bits            |
           +--------------------------------------------------+
           |    Target HDLC Address        32 bits            |
           +--------------------------------------------------+
           |    Target IP Address          32 bits            |
           +--------------------------------------------------+

+-------------------------+------------------------+ | ハードウェア・アドレススペース| プロトコルアドレス空間| | (25: MAPOS) | (12月の2048) | | 16ビット| 16ビット| +------------+------------+------------------------+ | 固いAddr| プロトAddr| 命令コード| | 長さ(4)| 長さ(4)|(1: 要求2: 応答) | | 8ビット| 8ビット| 16ビット| +------------+------------+------------------------+ | 送付者HDLC Address32ビット| +--------------------------------------------------+ | 送付者IP Address32ビット| +--------------------------------------------------+ | HDLC Addressを32ビット狙ってください。| +--------------------------------------------------+ | IP Addressを32ビット狙ってください。| +--------------------------------------------------+

                      Figure 5  ARP packet format

図5 ARPパケット・フォーマット

     Hardware Address Space (16 bits)

ハードウェア・アドレススペース(16ビット)

     The hardware address space for MAPOS ARP is 25 in Decimal as
     assigned by IANA [6].

IANA[6]によって割り当てられるようにMAPOS ARPのためのハードウェア・アドレススペースはDecimalの25です。

     Protocol Address Space (16 bits)

プロトコルアドレス空間(16ビット)

     The protocol address space for IP is 2048 in Decimal.

IPのためのプロトコルアドレス空間はDecimalの2048です。

     Hardware Address Length (8 bits)

ハードウェア・アドレスの長さ(8ビット)

     The hardware address length is 4.

ハードウェア・アドレスの長さは4です。

     Protocol Address Length (8 bits)

プロトコルアドレスの長さ(8ビット)

     The protocol address length for IP is 4.

IPのためのプロトコルアドレスの長さは4です。

     Operation Code (16 bits)

命令コード(16ビット)

     The operation code is 1 for request and 2 for response.

命令コードは、要求のための1と応答のための2です。

     Sender hardware (HDLC) Address (32 bits)

送付者ハードウェア(HDLC)アドレス(32ビット)

     Contains the sender's HDLC address in an ARP request, and the
     target HDLC address in an ARP response.  The 8-bit HDLC address is
     placed in the least significant place of the 32-bit field. The
     remaining bits should be zero.

ARP要求に送付者のHDLCアドレスを含んでいて、ARP応答に目標HDLCアドレスを含んでいます。 8ビットのHDLCアドレスは32ビットの分野の最も重要でない場所に置かれます。 残っているビットはゼロであるべきです。

Murakami & Maruyama          Informational                      [Page 3]

RFC 2176                         MAPOS                         June 1997

[3ページ]RFC2176MAPOS1997年6月の情報の村上と丸山

     Sender Protocol (IP) Address (32 bits)

送付者プロトコル(IP)アドレス(32ビット)

     Contains the sender's IP address in an ARP request, and the target
     IP address in an ARP response.

ARP要求に送付者のIPアドレスを含んでいて、ARP応答に目標IPアドレスを含んでいます。

     Target hardware (HDLC) Address (32 bits)

目標ハードウェア(HDLC)アドレス(32ビット)

     Contains unknown target HDLC address (all zeros) in an ARP request,
     and sender's HDLC address in an ARP response.  The 8-bit HDLC
     address is placed in the least significant place of the 32-bit
     field.  The remaining bits should be zero.

ARP要求に未知の目標HDLCアドレス(すべてのゼロ)を含んでいて、ARP応答に送付者のHDLCアドレスを含んでいます。 8ビットのHDLCアドレスは32ビットの分野の最も重要でない場所に置かれます。 残っているビットはゼロであるべきです。

     Target Protocol (IP) Address (32 bits)

目標プロトコル(IP)アドレス(32ビット)

     Contains the target IP address in an ARP request, and the sender's
     IP address in an ARP response.

ARP要求に目標IPアドレスを含んでいて、ARP応答に送付者のIPアドレスを含んでいます。

3.3 UNARP

3.3 UNARP

   An implementation MUST provide an UNARP mechanism to flush obsolete
   ARP cache entries.  The mechanism is similar to the ARP extension
   described in [7].  When a node detects that its port has came up, it
   MUST broadcast an UNARP packet.  It forces every other node to clear
   the obsolete ARP entry which was created by the node previously
   connected to the switch port. An UNARP is an ARP clear request with
   the following values:

実装は、時代遅れのARPキャッシュエントリーを洗い流すためにUNARPメカニズムを提供しなければなりません。 メカニズムは[7]で説明されたARP拡張子と同様です。 ノードがそれを検出するとき、ポートがそうした、来る、上がって、それはUNARPパケットを放送しなければなりません。 それによって、他のあらゆるノードがやむを得ず以前にスイッチポートに接続されたノードによって作成された時代遅れのARPエントリーをクリアします。 UNARPは以下の値があるARPの明確な要求です:

     Hardware Address Space          :       25
     Protocol Address Space          :       2048
     Hardware Address Length         :       4
     Protocol Address Length         :       4
     Operation Code                  :       23 (MAPOS-UNARP)
     Sender hardware (HDLC) Address  :       HDLC address of the node
     Sender Protocol (IP) Address    :       IP address of the node
     Target hardware (HDLC) Address  :       all 1
     Target Protocol (IP) Address    :       255.255.255.255 (broadcast)

ハードウェア・アドレススペース: 25 アドレス空間について議定書の中で述べてください: 2048年のハードウェア・アドレスの長さ: 4 アドレスの長さについて議定書の中で述べてください: 4命令コード: 23 (MAPOS-UNARP)送付者ハードウェア(HDLC)アドレス: ノードSenderプロトコル(IP)アドレスのHDLCアドレス: ノードTargetハードウェア(HDLC)アドレスのIPアドレス: すべての1つのTargetプロトコル(IP)アドレス: 255.255.255.255 (放送)

     Hardware Address Space (16 bits)

ハードウェア・アドレススペース(16ビット)

     The hardware address space for MAPOS ARP is 25 in Decimal as
     assigned by IANA [6].

IANA[6]によって割り当てられるようにMAPOS ARPのためのハードウェア・アドレススペースはDecimalの25です。

     Operation Code (16 bits)

命令コード(16ビット)

     The operation code is 23 for MAPOS-UNARP in Decimal as assigned by
     IANA [6].

IANA[6]によって割り当てられるように命令コードはDecimalのMAPOS-UNARPのための23です。

Murakami & Maruyama          Informational                      [Page 4]

RFC 2176                         MAPOS                         June 1997

[4ページ]RFC2176MAPOS1997年6月の情報の村上と丸山

   The node MUST send three UNARP packets at 30 seconds intervals.  The
   receiving node of the packet MUST clear the ARP cache entry
   associated with the Sender Protocol (IP) Address, if and only if the
   corresponding Hardware (HDLC) Address is not equal to that contained
   in the UNARP packet.  That is, if both the Sender Hardware (HDLC)
   Address and the Sender Protocol(IP) Address match those of the cached
   entry, the entry is left unchanged.

30秒の間隔を置いて、ノードは3つのUNARPパケットを送らなければなりません。 そして、パケットの受信ノードがSenderプロトコル(IP)アドレスに関連しているARPキャッシュエントリーをクリアしなければならない、対応するHardware(HDLC)アドレスがUNARPパケットに含まれたそれと等しくない場合にだけ。 すなわち、Sender Hardware(HDLC)アドレスとSenderプロトコル(IP)アドレスの両方がキャッシュされたエントリーのものに合っているなら、エントリーは変わりがないままにされます。

3.4 ARP Cache Validation

3.4 ARPキャッシュ合法化

   An implementation MUST provide a mechanism to remove out-of-date
   cache entries and it SHOULD provide options to configure the timeout
   value [8].  One approach is to periodically time-out the cache
   entries, even if they are in use.  This approach involves ARP cache
   timeouts in the order of a minute or less.

実装は時代遅れなキャッシュエントリーとそれを取り除くメカニズムを提供しなければなりません。SHOULDはタイムアウト値[8]を構成するオプションを提供します。 定期的には1つのアプローチがある、タイムアウト、キャッシュエントリーそれらが使用中であっても。 このアプローチはARPキャッシュタイムアウトに1分以下の注文にかかわります。

   Furthermore, when the link is lost on an interface, all ARP cache
   entries associated with the interface MUST be removed immediately.
   Causes for link loss includes conditions such as loss of carrier and
   out-of-synchronization.

すぐにインタフェースでリンクをなくすとき、その上、インタフェースに関連しているすべてのARPキャッシュエントリーを取り除かなければなりません。 リンクの損失の原因は同期の外にキャリヤーの損失などの状態を含んでいます。

3.5 IP Broadcast and multicast

3.5 IP Broadcastとマルチキャスト

   In broadcast and multicast frames, the most significant bit of the
   HDLC address must be 1 [1].  In addition, the least significant bit
   must always be 1 to indicate the end of the field [1].

放送とマルチキャストフレームでは、HDLCアドレスの最も重要なビットは1[1]であるに違いありません。 さらに、いつも最下位ビットは分野[1]の端を示す1であるに違いありません。

   In the case of IP broadcast, the remaining six bits of the HDLC
   address must be all 1s.  That is, it should be mapped to the HDLC
   broadcast address 0xFF (hexadecimal).

IP放送の場合では、HDLCアドレスの残っている6ビットはすべて1であるに違いありません。 すなわち、それはHDLC放送演説0xFF(16進)に写像されるべきです。

   In the case of IP multicast, the remaining six bits of the HDLC
   address must contain the lowest-order six bits of the IP multicast
   group address.  It resembles IP multicast extension for ethernet
   described in [9].  Exceptions arise when these six bits are either
   all zeros or all ones, in which case they should be altered to the
   bit sequence 111110.

IPマルチキャストの場合では、HDLCアドレスの残っている6ビットはIPマルチキャストグループアドレスの最も少ないオーダー6ビットを含まなければなりません。 それは[9]で説明されたイーサネットのためのIPマルチキャスト拡大に類似しています。 これらの6ビットがすべてのゼロかすべて、もののどちらかであるときに例外は起こります、その場合、それらが噛み付いている系列111110に変更されるべきです。

4. Security Considerations

4. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Murakami & Maruyama          Informational                      [Page 5]

RFC 2176                         MAPOS                         June 1997

[5ページ]RFC2176MAPOS1997年6月の情報の村上と丸山

References

参照

   [1]   Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
         over SONET/SDH, Version 1," RFC-2171, June 1997.

[1] 村上、K.、およびM.丸山、「MAPOS--複数のアクセスがSonet/SDH、バージョン1の上で議定書を作る」、RFC-2171、6月1997日

   [2]   Simpson, W., editor, "PPP in HDLC-like Framing," RFC-1662,
         July 1994.

[2] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、RFC-1662、1994年7月。

   [3]   Postel, J., "Internet Protocol (IP)," RFC-791, September 1981.

[3] ポステル、J.、「インターネットプロトコル(IP)」、RFC-791、1981年9月。

   [4]   Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
         Numbers," RFC-2172, June 1997.

[4] 丸山とM.とK.村上、「MAPOSバージョン1規定番号」、RFC-2172、1997年6月。

   [5]   Mogul, J. and S. Deering, "Path MTU Discovery," RFC-1191,
         Nov. 1990.

[5] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC-1191、1990年11月。

   [6]   IANA, "IANA-Assignments",
         http://www.iana.org/iana/assignments.html

[6]IANA、「IANA-課題」、 http://www.iana.org/iana/assignments.html

   [7]   Malkin, G., "ARP Extension - UNARP," RFC-1868, November 1995.

[7] マルキン、G.、「ARP拡張子--、UNARP、」、RFC-1868、11月1995日

   [8]   Braden, R., "Requirements for Internet Hosts - Communication
         Layers," RFC-1122, October 1989.

[8] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、RFC-1122、10月1989日

   [9]   Deering, S., "Host Extensions for IP Multicasting," RFC-1112,
         August 1989.

[9] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC-1112、1989年8月。

Acknowledgements

承認

   The authors would like to acknowledge the contributions and
   thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
   Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.

作者はジョン・P.マレイニイ、クラーク・ブリーマー、Masayuki小林、ポール・フランシス、吉田俊昭、およびTakahiro Sajimaの貢献と考え深い提案を承諾したがっています。

Author's Address

作者のアドレス

     Ken Murakami
     NTT Software Laboratories
     3-9-11, Midori-cho
     Musashino-shi
     Tokyo-180, Japan
     E-mail: murakami@ntt-20.ecl.net

ケン村上NTTソフトウェア研究所3 9-11テロの美土里町武蔵野市東京-180、日本メール: murakami@ntt-20.ecl.net

     Mitsuru Maruyama
     NTT Software Laboratories
     3-9-11, Midori-cho
     Musashino-shi
     Tokyo-180, Japan
     E-mail: mitsuru@ntt-20.ecl.net

Mitsuru丸山NTTソフトウェア研究所3 9-11テロの美土里町武蔵野市東京-180、日本メール: mitsuru@ntt-20.ecl.net

Murakami & Maruyama          Informational                      [Page 6]

村上と丸山Informationalです。[6ページ]