RFC2171 日本語訳

2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K.Murakami, M. Maruyama. June 1997. (Format: TXT=17480 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

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

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

       MAPOS - Multiple Access Protocol over SONET/SDH  Version 1

MAPOS--Sonet/SDHバージョン1の上の複数のアクセス・プロトコル

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

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

Authors' Note

作者の注意

   This memo documents a multiple access protocol for transmission of
   network-protocol datagrams, encapsulated in High-Level Data Link
   Control (HDLC) frames, 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.

このメモはHigh-レベルData Link Control(HDLC)フレームでカプセル化されたネットワーク・プロトコルデータグラムのトランスミッションのためにSonet/SDHの上に複数のアクセス・プロトコルを記録します。 このドキュメントはIETFワーキンググループの製品ではありません、そして、それは標準化過程ドキュメントではありません。 必ず、標準化過程ドキュメントが受信されるのは広範囲の、そして、徹底的な共同体レビューから利益を得るというわけではありませんでした。

Abstract

要約

   This document describes the protocol MAPOS, Multiple Access Protocol
   over SONET/SDH, for transmitting network-protocol datagrams over
   SONET/SDH.  It focuses on the core protocol -- other documents listed
   in the bibliography may be referenced in conjunction with this
   document to provide support and services for protocols at higher
   layers.

このドキュメントは、Sonet/SDHの上にネットワーク・プロトコルデータグラムを送るためにSonet/SDHの上でプロトコルMAPOS、Multiple Accessプロトコルについて説明します。 それはコアプロトコルに焦点を合わせます--図書目録にリストアップされた他のドキュメントは、より高い層のプロトコルのためのサポートとサービスを提供するためにこのドキュメントに関連して参照をつけられるかもしれません。

1. Introduction

1. 序論

1.1 SONET/SDH

1.1 Sonet/SDH

   The Synchronous Optical Network/Synchronous Digital Hierarchy
   (SONET/SDH) [1][2][3][4] family of ITU-T standard protocols are
   designed to provide common, simple, and flexible interface for
   broadband optical fiber transmission systems.  It enables direct
   octet-synchronous multiplexing of lower rate tributaries.
   SONET/SDH-compliant transmission systems are widely deployed by
   telephone carriers world wide.

ITU-T標準プロトコルの同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)[1][2][3][4]ファミリーは、一般的で、簡単で、フレキシブルなインタフェースを広帯域の光ファイバ伝動装置に供給するように設計されています。それは低料金支流のダイレクト八重奏同期のマルチプレクシングを可能にします。 SDH Sonet/対応することの伝動装置は世界中の回線業者によって広く配布されます。

   This document defines the MAPOS protocol -- a method for transmitting
   HDLC frames over SONET/SDH. The protocol provides multiple access
   capability to SONET/SDH, an inherently point-to-point link. This
   enables construction of seamless networking environment using
   SONET/SDH as transmission media for both LAN and WAN.

このドキュメントはMAPOSプロトコルを定義します--Sonet/SDHの上にHDLCフレームを伝えるためのメソッド。 プロトコルはSonet/SDH、本来の二地点間のリンクに複数のアクセス能力を供給します。 これは、LANとWANの両方にトランスミッションメディアとしてSonet/SDHを使用することでシームレスのネットワーク環境の工事を可能にします。

Murakami & Maruyama          Informational                      [Page 1]

RFC 2171                         MAPOS                         June 1997

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

1.2 Possible Configurations

1.2 可能な構成

   The MAPOS protocol provides multiple access, broadcast / multicast-
   capable switched LAN environment using SONET/SDH lines as
   transmission media.  Possible configurations of MAPOS system are
   shown in the following diagrams.  In (a), two end nodes are connected
   to each other.  Figure (b) shows a star-topology "SONET-LAN" where
   multiple end nodes are connected to an HDLC frame switch. The frame
   switch forwards packets between nodes and provides multiple access
   capability. In (c), multiple frame switches are linked together,
   creating a switching cluster.

MAPOSプロトコルは複数のアクセス、トランスミッションメディアとしてSonet/SDH系列を使用する放送/マルチキャストのできる切り換えられたLAN環境を提供します。 MAPOSシステムの可能な構成は以下のダイヤグラムで示されます。(a)では、2つのエンドノードが互いに接されます。 図(b)は、複数のエンドノードがどこでHDLCフレームスイッチに接続されるかをスタートポロジー「Sonet-LAN」に示します。 フレームスイッチは、ノードの間にパケットを送って、複数のアクセス能力を提供します。 (c)では、切り換えクラスタを作成して、複数のフレームスイッチが結びつけられます。

           +------+                                +------+
           | Node +--------------------------------+ Node |
           +------+                                +------+

+------+ +------+ | ノード+--------------------------------+ ノード| +------+ +------+

                    (a) Point-to-Point configuration

(a) ポイントからポイントへの構成

Murakami & Maruyama          Informational                      [Page 2]

RFC 2171                         MAPOS                         June 1997

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

           +------+                                +---------------+
           | Node +--------------------------------+               |
           +------+                                |               |
                                                   |               |
           +------+                                |               |
           | Node +--------------------------------+               |
           +------+                                |               |
                                                   | Frame Switch  |
           +------+                                |               |
           | Node +--------------------------------+               |
           +------+                                |               |
                                                   |               |
           +------+                                |               |
           | Node +--------------------------------+               |
           +------+                                +---------------+

+------+ +---------------+ | ノード+--------------------------------+ | +------+ | | | | +------+ | | | ノード+--------------------------------+ | +------+ | | | フレームスイッチ| +------+ | | | ノード+--------------------------------+ | +------+ | | | | +------+ | | | ノード+--------------------------------+ | +------+ +---------------+

                 (b) Point-to-Multipoint configuration

(b) ポイントから多点への構成

           +--------+                      +--------+
           | Frame  +----------------------+ Frame  |
           | Switch +--------+    +--------+ Switch |
           +--+-----+      +-+----+-+      +--------+
              |            | Frame  |                      +--------+
           +--+-----+      | Switch |      +--------+      | Frame  |
           | Frame  |      +-----+--+      | Frame  +------+ Switch |
           | Switch |            +---------+ Switch |      ++-------+
           +-------++                      +--------+       |
                   |________________________________________|

+--------+ +--------+ | フレーム+----------------------+ フレーム| | スイッチ+--------+ +--------+ スイッチ| +--+-----+ +-+----+-+ +--------+ | | フレーム| +--------+ +--+-----+ | スイッチ| +--------+ | フレーム| | フレーム| +-----+--+ | フレーム+------+ スイッチ| | スイッチ| +---------+ スイッチ| ++-------+ +-------++ +--------+ | |________________________________________|

                  (c) Switching cluster configuration

(c) 切り換えクラスタ構成

                   Figure 1. Possible configurations

図1。 可能な構成

   Each port on a switch has an unique identifier within the switch. A
   node connected to a switch port must inherit the address of the port.
   That is, the node address is equal to the port identifier and is
   unique within the switch.

スイッチの上の各ポートはスイッチの中にユニークな識別子を持っています。 スイッチポートに接続されたノードはポートのアドレスを引き継がなければなりません。 すなわち、ノードアドレスは、ポート識別子と等しく、スイッチの中にユニークです。

   In a switch cluster, a node address is subnetted. The high-order
   bits, the part where the corresponding bits in the "subnet mask" are
   1, indicate the switch address.  The remaining low-order bits
   indicate the unique node address within the switch. The two fields
   form an unique address for a given node.

スイッチクラスタでは、ノードアドレスは「副-網で覆」われます。 高位のビット(「サブネットマスク」の対応するビットが1である部分)はスイッチアドレスを示します。 残っている下位のビットはスイッチの中にユニークなノードアドレスを示します。 2つの分野が与えられたノードのためのユニークなアドレスを形成します。

   In either case, the address may be configured manually into a node
   interface, or automatically by the address assignment mechanism
   described in [5].

どちらの場合ではも、アドレスは、手動でノードインタフェースに構成されるか、または[5]でアドレス割当機構によって自動的に説明されるかもしれません。

Murakami & Maruyama          Informational                      [Page 3]

RFC 2171                         MAPOS                         June 1997

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

   Note that any two components may be connected either directly, or via
   a long-haul SONET/SDH leased line.

どんな2つのコンポーネントも直接か長期Sonet/SDH専用線を通して接続されるかもしれないことに注意してください。

1.3 Packet Transmission

1.3パケット伝送

   The protocol is connection-less -- when a node wish to communicate
   with some other node, it simply fills-in the destination address of
   an HDLC frame, places it in one or more SONET/SDH payloads, and sends
   it over a SONET/SDH link.

プロトコルはコネクションレスです--ある他のノードとコミュニケートするというノード願望であるときに、それは、単にHDLCフレームの送付先アドレスに記入して、1個以上のSonet/SDHペイロードにそれを置いて、Sonet/SDHリンクの上にそれを送ります。

   The switch forwards the frame to its destination based on the
   destination address. In a switch cluster, the frame may be forwarded
   by multiple switches and is eventually delivered to the specified
   node.  Broadcast and multicast are also supported. Frames with an
   invalid destination address are silently discarded.

スイッチは送付先アドレスに基づく目的地にフレームを送ります。 スイッチクラスタでは、フレームは、複数のスイッチによって送られるかもしれなくて、結局、指定されたノードに提供されます。 また、放送とマルチキャストはサポートされます。 無効の送付先アドレスがあるフレームは静かに捨てられます。

   Like ethernet, the multiple access capability is provided by a switch
   or a switch cluster. Since MAPOS is a link layer protocol, it is
   independent of the upper layer protocols. That is, it can support any
   network layer protocols such as IP. MAPOS IPv4 support is described
   in [6].

イーサネットのように、スイッチかスイッチクラスタは複数のアクセス能力を提供します。 MAPOSがリンクレイヤプロトコルであるので、それは上側の層のプロトコルから独立しています。 すなわち、それは、どんなネットワーク層もIPなどのプロトコルであるとサポートすることができます。 MAPOS IPv4サポートは[6]で説明されます。

2. Physical Layer

2. 物理的な層

   This protocol treats the underlying end-to-end SONET/SDH transmission
   link as if it was a plain, transparent channel.  It sends HDLC frames
   in SONET/SDH payloads, and expects them to arrive at the other end
   unaltered.

このプロトコルはまるでそれが明瞭で、見え透いたチャンネルであるかのように終わりから終わりへの基本的なSonet/SDHトランスミッションリンクを扱います。 それは、Sonet/SDHのHDLCフレームにペイロードを送って、非変更されたもう一方の端に到着すると予想します。

   Each node and switch should terminate SONET/SDH overhead such as
   section overhead, line overhead, and path overhead according to the
   specification of SONET/SDH. Unfortunately, SONET and SDH overhead
   interpretations are not identical. In addition, some SONET/SDH
   implementations utilize some overhead bytes in proprietary manner.

各ノードとスイッチはSonet/SDHの仕様通りにセクションオーバーヘッドや、系列オーバーヘッドや、経路オーバーヘッドなどのSonet/SDHオーバーヘッドを終えるはずです。 残念ながら、SonetとSDHの頭上の解釈は同じではありません。 さらに、いくつかのSonet/SDH実装が独占方法でいくつかのオーバーヘッドバイトを利用します。

   The detail of the interpretation is beyond the scope of this
   document.  Appendix A describes some of the most significant
   differences among SONET, SDH, and their implementations that often
   causes interoperability problems.  Implementors of SONET/SDH
   interfaces are strongly encouraged to be aware of such differences,
   and provide workaround options in their products.

解釈の詳細はこのドキュメントの範囲を超えています。 付録Aはそれがしばしば相互運用性問題を引き起こすSonet、SDH、およびそれらの実装の中で最も重要な違いのいくつかについて説明します。Sonet/SDHインタフェースの作成者は、そのような違いを知って、回避策オプションをそれらの製品に供給するよう強く奨励されます。

Murakami & Maruyama          Informational                      [Page 4]

RFC 2171                         MAPOS                         June 1997

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

3. Data Link Layer

3. データ・リンク層

3.1 HDLC Frame Format

3.1 HDLCフレーム形式

   MAPOS uses the same HDLC-like framing as used in PPP-over-SONET,
   described in RFC-1662[7].  Figure 2 shows the 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.

MAPOSはRFC-1662[7]で説明されたPPP過剰Sonetに使用されるのと同じHDLCのような縁どりを使用します。 図2はフレーム形式を示しています。 論理的なLink Control(LLC)、および使用されないサブSublayer/Network Accessプロトコル(SNAP)。 それは透明のためのバイトを含んでいません。 野原は左から右まで伝えられます。

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

+----------+----------+----------+----------+ | | | | | | 旗| アドレス| コントロール| プロトコル| | 01111110 | 8ビット| 00000011 | 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 8 bits wide.
     The LSB indicates the end of this field, and must always be 1.  The
     MSB is used to indicate if the frame is a unicast or a multicast
     frame.  The MSB of 0 means unicast, with the remaining six bits
     indicating the destination node address. MSB of 1 means multicast,
     with the remaining six bits indicating the group address.  The
     address 11111111 (0xFF) means that the frame is a broadcast frame.
     The address 00000001 (0x01) is reserved to identify the control
     processor inside a switch.  Frames with an invalid address should
     be silently discarded.

アドレス・フィールドは送付先HDLCアドレスを含んでいます。 この分野に基づくスイッチはフレームを進めます。 それは幅8ビットです。 LSBはこの分野の端を示して、いつも1歳であるに違いありません。 MSBは、フレームがユニキャストかそれともマルチキャストフレームであるかを示すのに使用されます。 残っている6ビットが送付先ノードアドレスを示していて、0のMSBはユニキャストを意味します。 残っている6ビットがグループアドレスを示していて、1のMSBはマルチキャストを意味します。 アドレス11111111(0xFF)は、フレームが放送フレームであることを意味します。 アドレス00000001(0×01)は、スイッチの中に制御プロセッサを特定するために予約されます。 無効のアドレスがあるフレームは静かに捨てられるべきです。

Murakami & Maruyama          Informational                      [Page 5]

RFC 2171                         MAPOS                         June 1997

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

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

+-------------+-+ | | | | | | | | | | | ノードaddr|1| +-+-----------+-+ ^ ^ | | | +------- EAビット(いつも1)| 1 : 放送、マルチキャスト0: ユニキャスト

                        Figure 3 Address format

図3 Address形式

     Control

コントロール

     The control field contains single octet 00000011 (0x03) which, in
     HDLC nomenclature, means that the frame is an Unnumbered
     Information (UI) with the Poll/Final (P/F) bit set to zero.  Frames
     with any other control field values should be silently discarded.

制御フィールドはフレームがゼロに設定されたPoll/最終的な(P/F)ビットがあるUnnumbered情報(UI)であることをHDLC用語体系で意味するただ一つの八重奏00000011(0×03)を含んでいます。 いかなる他の制御フィールド値があるフレームも静かに捨てられるべきです。

     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" [8] and "MAPOS
     Version 1 Assigned Numbers" [9].

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

     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, control, 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はエスケープ変換の前にアドレス、コントロール、プロトコル、および情報フィールドのすべてのビットの上計算されます。 最初に、最も高い用語の係数を含むとき、結果の最も重要でない八重奏は伝えられます。

     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.

送付ステーションはインターフレーム中詰めとして絶え間なくFCS分野の後にフラグ・シーケンスを送信しなければなりません。 受入れステーションは静かにインターフレームフラグ・シーケンスを捨てなければなりません。

Murakami & Maruyama          Informational                      [Page 6]

RFC 2171                         MAPOS                         June 1997

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

     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.

いつ、送付ステーションがDMAの間、中に経営の下では、現れていて、それは、フレーム転送を中止して、誤りを示すために絶え間なくフラグ・シーケンスを送らなければならないか。

3.2 Octet-Synchronous Framing

3.2 八重奏同期の縁どり

   MAPOS uses an octet stuffing procedure because it treats SONET/SDH as
   a byte-oriented synchronous link.  Since SONET/SDH provides
   transparency, Async-Control-Character-Map (ACCM) is not used.  HDLC
   frames are mapped into the SONET/SDH payload as follows.

バイト指向の同期リンクとしてSonet/SDHを扱うので、MAPOSは八重奏詰め物の手順を用います。 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. Further Reading

4. 一層の読書

   To fully utilize MAPOS protocol, it is useful to reference other
   documents[5][6][9][10] in conjunction with this document.

MAPOSプロトコルを完全に利用するために、それはこのドキュメントに関連して他の参照ドキュメント[5][6][9][10]の役に立ちます。

5. Security Considerations

5. セキュリティ問題

   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, "A MAPOS version 1 Extension -
        Node Switch Protocol," RFC2173, June, 1997.

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

Murakami & Maruyama          Informational                      [Page 7]

RFC 2171                         MAPOS                         June 1997

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

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

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

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

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

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

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

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

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

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

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

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 8]

RFC 2171                         MAPOS                         June 1997

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

APPENDIX A.  Differences among SONET, SDH, and their Implementations

Sonet、SDH、および彼らのImplementationsの中のAPPENDIX A.Differences

   This section briefly describes the major differences among SONET
   which is an ANSI standard, SDH, an ITU-T standard, and their
   implementations.

このセクションはANSI規格と、SDHと、ITU-T規格と、それらの実装であるSonetの中で簡潔に主要な違いについて説明します。

     AU pointer (H1, H2, H3)

AU指針(H1、H2、H3)

     The AU pointer consists of bytes H1, H2, and H3. The bits 5 and 6
     of the H1 byte are called "SS bits," and are used to indicate the
     offset into the payload where the beginning of a SPE is located.
     (Note that "SPE" is a SONET term -- SDH calls it "VC.")  In the
     case of OC-3c, SONET sets the SS bits of the second and the third
     H1 bytes to 0, whereas SDH sets them to 10 for AU-4, and 01 for
     AU-31.  Although the SS bits may be ignored at the receiving
     station, some transmission systems discards SONET/SDH frames with
     SS bits that it doesn't expect -- the sending station should be
     aware of this, and include a configuration option to handle it.

AU指針はバイトのH1、H2、およびH3から成ります。 H1バイトのビット5と6は、「SSビット」と呼ばれて、SPEの始まりが位置しているペイロードにオフセットを示すのに使用されます。 ("SPE"がSonet用語であることに注意してください--SDHは、それを"VC"と呼びます。) OC-3cの場合では、SDHはAU-4のための10、およびAU-31のための01にそれらを設定しますが、Sonetは2番目のSSビットと3番目のH1バイトを0に設定します。 SSビットは受入れステーションで無視されるかもしれません、Sonet/SDHがそれが予想しないSSビットで縁どるいくつかの伝動装置破棄--送付ステーションは、これを意識していて、それを扱うために設定オプションを含めるべきですが。

     Z1 and Z2

Z1とZ2

     The Z bytes are reserved in SONET/SDH.  Some transmission systems,
     however, use them in a proprietary manner.  SONET uses Z1 for Line
     Error Monitoring.  NTT, a carrier in Japan, utilized Z1 for
     Automatic Protection Switching (APS.)

ZバイトはSonet/SDHで予約されます。 しかしながら、いくつかの伝動装置が独占方法でそれらを使用します。 Sonetは線Error MonitoringにZ1を使用します。 NTT(日本の運送業者)はAutomatic Protection SwitchingにZ1を利用しました。(APS。)

     DCC Bytes

DCCバイト

     The D bytes are called the Data Communication channel (DCC), and
     are defined for maintenance and operations.  However, some carriers
     and vendors use them in a proprietary manner.  For example, NTT's
     STM-1 UNI uses the D4, D5, and D6 bytes to transfer section and
     path maintenance information.

Dバイトは、Data Communicationチャンネル(DCC)と呼ばれて、メインテナンスと操作のために定義されます。 しかしながら、いくつかのキャリヤーとベンダーが独占方法でそれらを使用します。 例えば、NTTのSTM-1 UNIは、セクションと経路メインテナンス情報を移すのにD4、D5、およびD6バイトを使用します。

Murakami & Maruyama          Informational                      [Page 9]

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

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

WindowsでMySQLを再起動する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る