RFC2175 日本語訳

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

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

               MAPOS 16 - Multiple Access Protocol over
                    SONET/SDH with 16 Bit Addressing

MAPOS16--16ビットのアドレシングがあるSonet/SDHの上の複数のアクセス・プロトコル

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 MAPOS 16, a multiple access protocol for
   transmission of network-protocol datagrams, encapsulated in HDLC
   frames with 16 bit addressing, over SONET/SDH.  The primary
   difference with MAPOS version 1 is that it has 16 bit address field
   that offers significant wide address space. 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.

このメモはMAPOS16、HDLCフレームで16ビットで要約されたネットワーク・プロトコルデータグラムのトランスミッションのための複数のアクセス・プロトコルアドレシングを記録します、Sonet/SDHの上で。 MAPOSバージョン1がある第一の違いはそれには重要な広いアドレス空間を提供する16ビット・アドレス分野があるということです。 このドキュメントはIETFワーキンググループの製品ではありません、そして、それは標準化過程ドキュメントではありません。 必ず、標準化過程ドキュメントが受信されるのは広範囲の、そして、徹底的な共同体レビューから利益を得るというわけではありませんでした。

Abstract

要約

   This document describes the protocol MAPOS 16, Multiple Access
   Protocol over SONET/SDH with 16 Bit Addressing, for transmitting
   network-protocol datagrams over SONET/SDH.  The primary difference
   with MAPOS version 1 is that it has 16 bit address field that offers
   significant wide address space. It first describes the major
   differences between MAPOS and MAPOS 16 briefly. Then, it explains the
   header format and its 16 bit address format.

このドキュメントはプロトコルMAPOS16について説明します、16Bit AddressingとSonet/SDHの上のMultiple Accessプロトコル、Sonet/SDHの上にネットワーク・プロトコルデータグラムを送るために。 MAPOSバージョン1がある第一の違いはそれには重要な広いアドレス空間を提供する16ビット・アドレス分野があるということです。 それは最初に、簡潔にMAPOSとMAPOS16の主要な違いについて説明します。 そして、それで、ヘッダー形式とその16ビット・アドレス書式がわかります。

1. Introduction

1. 序論

   MAPOS is a multiple access protocol for transmission of High-level
   Datalink Control (HDLC) frames over the Synchronous Optical Network /
   Synchronous Digital Hierarchy(SONET/SDH)[1][2][3][4]. It provides
   multiple access capability to SONET/SDH, an inherently point-to-point
   link.

MAPOSは同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)[1][2][3][4]の上のHigh-レベルDatalink Control(HDLC)フレームのトランスミッションのための複数のアクセス・プロトコルです。 それはSonet/SDH、本来の二地点間のリンクに複数のアクセス能力を供給します。

   MAPOS version 1[5] focuses on the frame format compatibility with the
   conventional PPP[6], resulting with its narrow 8 bit address field.
   In contrast to MAPOS version 1, MAPOS 16 has a 16 bit address space.

フレームの上のMAPOSバージョン1[5]焦点は従来のPPP[6]との互換性をフォーマットします、狭い8ビット・アドレス分野でなって。 MAPOSバージョン1と対照して、MAPOS16には、16ビットのアドレス空間があります。

Murakami & Maruyama          Informational                      [Page 1]

RFC 2175                        MAPOS 16                       June 1997

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

   In this document, header format and its 16 bit format are described.
   It also explains that 16 bit addressing has minimal influence on the
   conventional MAPOS protocol family such as Node-Switch Protocol[7]
   and Switch-Switch Protocol[8].

本書では、ヘッダー形式とその16ビットの形式は説明されます。 また、それで、16ビットのアドレシングがNode-スイッチプロトコル[7]やSwitch-スイッチプロトコル[8]などの最小量の影響を従来のMAPOSプロトコル家に与えるのがわかります。

2. MAPOS 16 Frame Format

2. MAPOS16フレーム形式

   Like MAPOS version 1, MAPOS 16 framing is based on the HDLC-like
   framing used in PPP-over-SONET/SDH, described in RFC-1662[6].
   However, the address field is extended to 16 bits, and the control
   field in the MAPOS version 1 is omitted for maintain the 32bit
   alignment of the header.

MAPOSバージョン1のように、MAPOS16縁どりはRFC-1662[6]で説明されたPPP過剰Sonet/SDHで使用されるHDLCのような縁どりに基づいています。 しかしながら、アドレス・フィールドは16ビットまで広げられます、そして、バージョン1が省略されるMAPOSの制御フィールドはヘッダーの32ビットの整列を維持します。

   Figure 2 shows the MAPOS 16 frame format.  Logical Link Control
   (LLC), and Sublayer/Sub-Network Access Protocol (SNAP) are not used.
   It does not include the bytes for transparency.  The fields are
   transmitted from left to right.

図2はMAPOS16フレーム形式を示しています。 論理的なLink Control(LLC)、および使用されないサブSublayer/Network Accessプロトコル(SNAP)。 それは透明のためのバイトを含んでいません。 野原は左から右まで伝えられます。

           +----------+---------------------+----------+
           |          |                     |          |
           |   Flag   |       Address       | Protocol |
           | 01111110 |        16bits       |  16 bits |
           +----------+---------------------+----------+
              +-------------+------------+----------+-----------
              |             |            |          | Inter-frame
              | Information |    FCS     |   Flag   | fill or next
              |             | 16/32 bits | 01111110 | address
              +-------------+------------+----------+------------

+----------+---------------------+----------+ | | | | | 旗| アドレス| プロトコル| | 01111110 | 16ビット| 16ビット| +----------+---------------------+----------+ +-------------+------------+----------+----------- | | | | インターフレーム| 情報| FCS| 旗| 次に、いっぱいになってください。| | 16/32ビット| 01111110 | アドレス+-------------+------------+----------+------------

                        Figure 2.  Frame format

図2。 フレーム形式

     Flag Sequence

フラグ・シーケンス

     Flag sequence is used for frame synchronization.  Each frame begins
     and ends with a flag sequence 01111110 (0x7E).  If a frame
     immediately follows another, one flag sequence may be treated as
     the end of the preceding frame and the beginning of the immediately
     following frame.  When the line is idle, the flag sequence is to be
     transmitted continuously on the line.

フラグ・シーケンスはフレーム同期化に使用されます。 各フレームは、フラグ・シーケンス01111110(0x7E)で始まって、終わります。 フレームがすぐに別のものに続くなら、1つのフラグ・シーケンスが前のフレームの端とすぐに次のフレームの始まりとして扱われるかもしれません。 線が使用されていないときに、フラグ・シーケンスは線の上で絶え間なく伝えられることです。

     Address

アドレス

     The address field contains the destination HDLC address.  A frame
     is forwarded by a switch based on this field.  It is 16 bits wide.
     The LSB of the first byte indicates the continuation of this field,
     and must always be 0. The LSB of the second byte indicates the end
     of this field, and must always be 1.  The MSB of the first byte is

アドレス・フィールドは送付先HDLCアドレスを含んでいます。 この分野に基づくスイッチはフレームを進めます。 それは幅16ビットです。 最初のバイトのLSBはこの分野の継続を示して、いつも0歳であるに違いありません。 2番目のバイトのLSBはこの分野の端を示して、いつも1歳であるに違いありません。 最初のバイトのMSBはそうです。

Murakami & Maruyama          Informational                      [Page 2]

RFC 2175                        MAPOS 16                       June 1997

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

     used to indicate if the frame is a unicast or multicast frame.  The
     MSB of 0 means unicast, with the remaining thirteen bits indicating
     the destination node address including two E/A bits. MSB of 1 means
     multicast, with the remaining thirteen bits indicating the group
     address.  The address 0xFEFF means that the frame is a broadcast
     frame. The address (0x0001) is reserved to identify the control
     processor inside a switch.  Frames with an invalid address should
     be silently discarded.

フレームがユニキャストかそれともマルチキャストフレームであるかを示すのにおいて、使用されています。 残っている13ビットが2Eの/を何ビットも含む送付先ノードアドレスを示していて、0のMSBはユニキャストを意味します。 残っている13ビットがグループアドレスを示していて、1のMSBはマルチキャストを意味します。 アドレス0xFEFFは、フレームが放送フレームであることを意味します。 アドレス(0×0001)は、スイッチの中に制御プロセッサを特定するために予約されます。 無効のアドレスがあるフレームは静かに捨てられるべきです。

             +-------------+-+-------------+-+
             | | | | | | | | | | | | | | | | |
             | | node addr |0|  node addr  |1|
             +-+-----------+-+-------------+-+
              ^             ^               ^
              |             |               |
              |             |               +------- EA bit (always 1)
              |             +------- EA bit (always 0)
              1 : broadcast, multicast
              0 : unicast

+-------------+-+-------------+-+ | | | | | | | | | | | | | | | | | | | ノードaddr|0| ノードaddr|1| +-+-----------+-+-------------+-+ ^ ^ ^ | | | | | +------- EAビット(いつも1)| +------- EAは1に噛み付きました(いつも0): 放送、マルチキャスト0: ユニキャスト

                        Figure 3 Address format

図3 Address形式

     Protocol

プロトコル

     The protocol field indicates the protocol to which the datagram
     encapsulated in the information field belongs.  It conforms to the
     ISO 3309 extension mechanism, and the value for this field may be
     obtained from the most recent ``Assigned Numbers'' [9] and ``MAPOS
     Version 1 Assigned Numbers'' [10].

プロトコル分野は情報フィールドで要約されたデータグラムが属するプロトコルを示します。 それは3309年のISO拡大メカニズムに従います、そして、最新の「規定番号」[9]と「MAPOSバージョン1規定番号」[10]からこの分野への値を得るかもしれません。

     Information

情報

     The information field contains the datagram for the protocol
     specified in the protocol field.  The length of this field may
     vary, but shall not exceed 65,280 (64K - 256) octets.

情報フィールドはプロトコル分野で指定されたプロトコルのためのデータグラムを含んでいます。 この分野の長さは、異なるかもしれませんが、6万5280(64K--256)の八重奏を超えていないものとします。

     Frame Check Sequence (FCS)

フレームチェックシーケンス(FCS)

     By default, the frame check sequence (FCS) field is 16-bits long.
     Optionally, 32 bit FCS may be used instead.  The FCS is calculated
     over all bits of the address, protocol, and information fields
     prior to escape conversions.  The least significant octet of the
     result is transmitted first as it contains the coefficient of the
     highest term.

デフォルトで、長い間、フレームチェックシーケンス(FCS)分野は16ビットです。 任意に、32ビットのFCSは代わりに使用されるかもしれません。 FCSはエスケープ変換の前にアドレス、プロトコル、および情報フィールドのすべてのビットの上計算されます。 最初に、最も高い用語の係数を含むとき、結果の最も重要でない八重奏は伝えられます。

Murakami & Maruyama          Informational                      [Page 3]

RFC 2175                        MAPOS 16                       June 1997

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

     Inter-frame fill

インターフレーム中詰め

     A sending station must continuously transmit the flag sequence as
     inter-frame fill after the FCS field.  The inter-frame flag
     sequences must be silently discarded by the receiving station.
     When an under-run occurs during DMA in the sending station, it must
     abort the frame transfer and continuously send the flag sequence to
     indicate the error.

送付ステーションはインターフレーム中詰めとして絶え間なくFCS分野の後にフラグ・シーケンスを送信しなければなりません。 受入れステーションは静かにインターフレームフラグ・シーケンスを捨てなければなりません。 いつ、送付ステーションがDMAの間、中に経営の下では、現れていて、それは、フレーム転送を中止して、誤りを示すために絶え間なくフラグ・シーケンスを送らなければならないか。

3.2 Octet-Synchronous Framing

3.2 八重奏同期の縁どり

   MAPOS 16 uses the same octet stuffing procedure[6] as MAPOS version
   1[5]. Since SONET/SDH provides transparency, Async-Control-
   Character-Map (ACCM) is not used.  HDLC frames are mapped into the
   SONET/SDH payload as follows.

MAPOS16はMAPOSバージョン1[5]として手順[6]を詰める同じ八重奏を使用します。 Sonet/SDHが透明を提供するので、Asyncキャラクター地図を制御している(ACCM)は使用されていません。 HDLCフレームは以下のSonet/SDHペイロードに写像されます。

   Each HDLC frame is separated from another frame by one or more flag
   sequence, 01111110 (0x7E).  An escape sequence is defined to escape
   the flag sequence and itself.  Prior to sending the frame, but after
   the FCS computation, every occurrence of 01111110 (0x7E) other than
   the flags is to be converted to the sequence 01111101 01011110 (0x7D
   0x5E), and the sequence 01111101 (0x7D) is to be converted to the
   sequence 01111101 01011101 (0x7D 0x5D).  Upon receiving a frame, this
   conversion must be reversed prior to FCS computation.

それぞれのHDLCフレームは別のフレームから1つ以上のフラグ・シーケンス、01111110(0x7E)分離されます。 エスケープシーケンスは、フラグ・シーケンスとそれ自体から逃げるために定義されます。 フレームを送る前にもかかわらず、FCS計算の後に、旗以外のあらゆる01111110人(0x7E)の発生が系列01111101 01011110(0x7D 0x5E)に変換されることになっています、そして、系列01111101(0x7D)は系列01111101 01011101(0x7D 0x5D)に変換されることです。 フレームを受けると、FCS計算の前にこの変換を逆にしなければなりません。

4. Influence on MAPOS ARP, UNARP, NSP, and SSP

4. MAPOSアルプ、UNARP、NSP、およびSSPへの影響

   Since all of the MAPOS protocol family, ARP[11], UNARP[11], NSP[7],
   and SSP[8], use 32-bit address field for 8-bit MAPOS address, the
   16-bit addressing has no influence on them.  Each protocol only have
   to place a 16 bit address in the least significant place in their 32
   bit address fields as follows;

MAPOSプロトコル家(アルプ[11]、UNARP[11]、NSP[7]、およびSSP[8])が皆、8ビットのMAPOSアドレスに32ビットのアドレス分野を使用するので、16ビットのアドレシングは影響を全く彼らに与えません。 各プロトコルは以下のそれらの32のビット・アドレス分野で最も重要でない場所に16ビット・アドレスを置くだけでよいです。

   (1) MAPOS ARP and UNARP
    16-bit addresses are placed in the least significant places of the
    32-bit sender and target HDLC addresses.

(1) MAPOS ARPとUNARPの16ビットのアドレスは32ビットの送付者と目標HDLCアドレスの最も重要でない場所に置かれます。

   (2) NSP
    In address assignment packet, a 16-bit address is placed in the
    least significant bytes of the 32-bit address field. The rest of the
    field is padded with zeros.

(2) NSP Inアドレス課題パケット、16ビットのアドレスは32ビットのアドレス分野の最も重要でないバイトに置かれます。 分野の残りはゼロで水増しされます。

   (3) SSP
    In route entry of an SSP packet, the 16-bit MAPOS address is placed
    in the least significant bytes of the 32-bit address field.

(3) SSPパケットのSSP Inルートエントリー、16ビットのMAPOSアドレスは32ビットのアドレス分野の最も重要でないバイトに置かれます。

Murakami & Maruyama          Informational                      [Page 4]

RFC 2175                        MAPOS 16                       June 1997

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

5. Mapping IP Multicast Address to MAPOS 16 Address

5. IPマルチキャストアドレスをMAPOS16アドレスに写像します。

   When transmitting IP multicast[11], the thirteen bits of the HDLC
   address must contain the lowest-order thirteen bits of the IP
   multicast group address.  Exceptions arise when these thirteen bits
   are either all zeros or all ones, in which case the address 1111 1110
   1111 1101 should be used.

IPマルチキャスト[11]を伝えるとき、HDLCアドレスの13ビットはIPマルチキャストグループアドレスの最も少ないオーダー13ビットを含まなければなりません。 これらの13ビットがすべてのゼロかすべて、もののどちらかであるときに例外は起こります、その場合、アドレス1111 1110 1111 1101は使用されるべきです。

6. Security Considerations

6. セキュリティ問題

   Security issues are not discussed in this memo.

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

References

参照

   [1]  CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
        Rates (1990).

[1] CCITT推薦G.707: 同期デジタルハイアラーキビット伝送速度(1990)。

   [2]  CCITT Recommendation G.708: Network Node Interface for
        Synchronous Digital Hierarchy (1990).

[2] CCITT推薦G.708: 同期デジタルハイアラーキ(1990)のためにノードインタフェースをネットワークでつないでください。

   [3]  CCITT Recommendation G.709: Synchronous Multiplexing Structure
        (1990).

[3] CCITT推薦G.709: 同期マルチプレクシング構造(1990)。

   [4]  American National Standard for Telecommunications - Digital
        Hierarchy - Optical Interface Rates and Formats Specification,
        ANSI T1.105-1991.

[4] ANSI T1.105-1991、テレコミュニケーションのための米国標準規格--デジタル階層構造--光学インタフェースは仕様を評定して、フォーマットします。

   [5]  Murakami, K. and M. Maruyama, " MAPOS - Multiple Access Protocol
        over SONET/SDH version 1", RFC2171, June, 1997.

[5] 村上、K.、およびM.丸山、「MAPOS--1997インチ年6月のSonet/SDHバージョン1インチ、RFC2171の上の複数のAccessプロトコル。

   [6]  Simpson, W., editor, "PPP in HDLC-like Framing," RFC1662, July
        1994.

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

   [7]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
        Node Switch Protocol," RFC2173, June, 1997.

[7] 村上、K.、およびM.丸山、「MAPOSバージョン1Extension--、ノードSwitchプロトコル、」、RFC2173、6月、1997

   [8]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
        Switch Switch Protocol," RFC2174, June, 1997.

[8] 村上とK.とM.丸山、「MAPOSバージョン1Extension--Switchプロトコルを切り換える」RFC2174、1997年6月。

   [9]  Reynolds, J. and J. Postel, "ASSIGNED NUMBERS," RFC1700, Oct.
        1994.

[9] レイノルズとJ.とJ.ポステル、「規定番号」、RFC1700、1994年10月。

   [10] Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
        Numbers," RFC2172, June, 1997.

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

   [11] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
        RFC2176, June, 1997.

[11] 村上とK.とM.丸山、「MAPOSバージョン1の上のIPv4」、RFC2176、1997年6月。

Murakami & Maruyama          Informational                      [Page 5]

RFC 2175                        MAPOS 16                       June 1997

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

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ページ]