Network Working Group D. Grossman
Request for Comments: 2684 Motorola, Inc.
Obsoletes: 1483 J. Heinanen
Category: Standards Track Telia
September 1999
Multiprotocol Encapsulation over ATM Adaptation Layer 5
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.
このメモは、それはATMの上にAALタイプ5を介してネットワークの相互接続のトラフィックを伝送するための2つのカプセル化方法を説明するRFC 1483に置き換えられます。第2の方法は、各プロトコルが別々のATM仮想接続を介して行われることを前提とし、一方、第一の方法は、単一のATM仮想接続を介して複数のプロトコルの多重化を可能にします。
Applicability
適用性
This specification is intended to be used in implementations which use ATM networks to carry multiprotocol traffic among hosts, routers and bridges which are ATM end systems.
この仕様は、ATMエンドシステムであるホスト、ルータとブリッジの間でマルチプロトコルトラフィックを運ぶためにATMネットワークを使用する実装に使用されることが意図されます。
Asynchronous Transfer Mode (ATM) wide area, campus and local area networks are used to transport IP datagrams and other connectionless traffic between hosts, routers, bridges and other networking devices. This memo describes two methods for carrying connectionless routed and bridged Protocol Data Units (PDUs) over an ATM network. The "LLC Encapsulation" method allows multiplexing of multiple protocols over a single ATM virtual connection (VC). The protocol type of each PDU is identified by a prefixed IEEE 802.2 Logical Link Control (LLC) header. In the "VC Multiplexing" method, each ATM VC carries PDUs of exactly one protocol type. When multiple protocols need to be transported, there is a separate VC for each.
非同期転送モード（ATM）、ワイドエリア、キャンパスおよびローカルエリアネットワークはホスト、ルータ、ブリッジ、および他のネットワークデバイスとの間のIPデータグラムと他のコネクションレストラフィックを転送するために使用されます。このメモは、コネクションレスルーティングされ、ATMネットワーク上のプロトコルデータユニット（PDU）をブリッジを運ぶための2つの方法について説明します。 「LLCカプセル化」の方法は、単一のATM仮想接続（VC）の上に複数のプロトコルの多重化を可能にします。各PDUのプロトコルタイプは、接頭辞IEEE 802.2論理リンク制御（LLC）ヘッダによって識別されます。 「VC多重化」法では、各ATM VCは、厳密に1つのプロトコルタイプのPDUを運びます。複数のプロトコルを輸送する必要がある場合は、それぞれに別々のVCがあります。
The unit of transport in ATM is a 53 octet fixed length PDU called a cell. A cell consists of a 5 octet header and a 48 byte payload. Variable length PDUs, including those addressed in this memo, must be segmented by the transmitter to fit into the 48 octet ATM cell payload, and reassembled by the receiver. This memo specifies the use of the ATM Adaptation Layer type 5 (AAL5), as defined in ITU-T Recommendation I.363.5 [2] for this purpose. Variable length PDUs are carried in the Payload field of the AAL5 Common Part Convergence Sublayer (CPCS) PDU.
ATMにおける輸送の単位はセルと呼ばれる53オクテットの固定長のPDUです。細胞は、5オクテットのヘッダと48バイトのペイロードで構成されています。このメモで扱われるものを含む可変長のPDUは、48オクテットのATMセルのペイロードに適合するために送信機によってセグメント化され、そして受信機によって再アセンブルされなければなりません。この目的のためのITU-T勧告I.363.5 [2]で定義されるように、このメモは、ATMアダプテーション・レイヤー・タイプ5（AAL5）の使用を指定します。可変長のPDUはAAL5共通部コンバージェンスサブレイヤ（CPCS）PDUのペイロード・フィールドで運ばれます。
This memo only describes how routed and bridged PDUs are carried directly over the AAL5 CPCS, i.e., when the Service Specific Convergence Sublayer (SSCS) of AAL5 is absent. If Frame Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in ITU-T Recommendation I.365.1 [3], is used over the CPCS, then routed and bridged PDUs are carried using the NLPID multiplexing method described in RFC 2427 [4]. The RFC 2427 encapsulation MUST be used in the special case that Frame Relay Network Interworking or transparent mode Service Interworking [9] are used, but is NOT RECOMMENDED for other applications. Appendix A (which is for information only) shows the format of the FR-SSCS-PDU as well as how IP and CLNP PDUs are encapsulated over FR-SSCS according to RFC 2427.
このメモは、AAL5のサービス特定収束サブレイヤ（SSCS）が存在しない、すなわち、場合、AAL5 CPCS上に直接運ばれる方法ルーティングされ、PDUを架橋記述する。 ITU-T勧告I.365.1で定義されているフレームリレーサービス特定コンバージェンスサブレイヤ（FR-SSCS）は、[3]、CPCS上で使用される場合、ルーティングおよびブリッジPDUはRFC 2427に記載しNLPID多重方式を使用して実施されます4]。 RFC 2427のカプセル化は、フレームリレーネットワークインターワーキングまたは透過モードサービスインターワーキングは、[9]を使用していることを、特殊な場合に使用されなければならないが、他の用途にはお勧めできません。 （情報のみのためのものである）付録Aは、IPとCLNP PDUがRFC 2427によればFR-SSCS上にカプセル化されている方法と同様にFR-SSCS-PDUのフォーマットを示します。
This memo also includes an optional encapsulation for use with Virtual Private Networks that operate over an ATM subnet.
また、このメモはATMサブネット上で動作させる仮想プライベートネットワークで使用するためのオプションのカプセル化を含んでいます。
If it is desired to use the facilities which are designed for the Point-to-Point Protocol (PPP), and there exists a point-to-point relationship between peer systems, then RFC 2364, rather than this memo, applies.
それはポイントツーポイントプロトコル（PPP）のために設計された設備を使用することが望ましい、とピアシステム間のポイントツーポイント関係が存在している場合は、RFC 2364、むしろこのメモよりも、適用されます。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [10].
キーワードは、REQUIREDは、、、、彼らは、この文書に表示されたときに、RFC 2119 [10]で説明したように解釈されるべきである、MAY、推奨しません、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
The decision as to whether to use LLC encapsulation or VC-multiplexing depends on implementation and system requirements. In general, LLC encapsulation tends to require fewer VCs in a multiprotocol environment. VC multiplexing tends to reduce fragmentation overhead (e.g., an IPV4 datagram containing a TCP control packet with neither IP nor TCP options exactly fits into a single cell).
LLCカプセル化またはVC-多重化を使用するかどうかの決定は、実装し、システム要件によって異なります。一般的には、LLCカプセル化は、マルチプロトコル環境では少ないのVCを必要とする傾向があります。 VC多重化（例えば、IPやTCPオプションもないとのTCP制御パケットを含むIPV4データグラムが正確に単一のセルに収まる）断片化のオーバーヘッドを減少させる傾向があります。
When two ATM end systems wish to exchange connectionless PDUs across an ATM Permanent Virtual Connection (PVC), selection of the multiplexing method is done by configuration. ATM connection control signalling procedures are used to negotiate the encapsulation method when ATM Switched Virtual Connections (SVCs) are to be used. [5] and [8] specify how this negotiation is done.
2つのATMエンドシステムはATM永久仮想接続（PVC）を横切っコネクションPDUを交換したい場合、多重化方法の選択は、構成によって行われます。 ATMは、仮想接続（SVCを）交換するときATM接続制御シグナリング手順は、カプセル化方法を交渉するために使用され使用されます。 [5]及び[8]この交渉がどのように行われるかを指定します。
For both multiplexing methods, routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU.
両方の多重化方式のため、ルーティング及びPDUはAAL5 CPCS-PDUのペイロードフィールド内にカプセル化されなければならないブリッジ。
ITU-T Recomendation I.363.5 [2] provides the complete definition of the AAL5 PDU format and procedures at the sender and receiver. The AAL5 message mode service, in the non-assured mode of operation MUST be used. The corrupted delivery option MUST NOT be used. A reassembly timer MAY be used. The following description is provided for information.
ITU-T Recomendation I.363.5 [2]は送信側と受信側でAAL5 PDUフォーマットおよび手順の完全な定義を提供します。操作の非保証モードでAAL5メッセージモードサービスを使用しなければなりません。破損した配信オプションを使用してはいけません。再構築タイマーを使用することができます。以下の記述は、情報のために提供されます。
The format of the AAL5 CPCS-PDU is shown below:
AAL5 CPCS-PDUのフォーマットを以下に示します。
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------
The Payload field contains user information up to 2^16 - 1 octets.
1オクテット - ペイロードフィールドは、2 ^ 16までのユーザー情報が含まれています。
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such that the last 48 octet cell payload created by the SAR sublayer will have the CPCS-PDU Trailer right justified in the cell.
パッドフィールドパッドCPCS-PDUは、SARサブレイヤによって作成された最後の48オクテットのセルのペイロードは、細胞におけるCPCS-PDUトレーラーが右寄せになりますようにATMセルに正確に収まるようにします。
The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field is not used by the multiprotocol ATM encapsulation described in this memo and MAY be set to any value.
CPCS-UU（ユーザ対ユーザ指示）フィールドは透過ユーザ情報にCPCSユーザを転送するために使用されます。フィールドは、このメモに記載マルチATMカプセル化によって使用されず、任意の値に設定してもよいです。
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. This field MUST be coded as 0x00.
CPI（共通部インジケータ）フィールドは64ビットにCPCS-PDUトレーラを整列させます。このフィールドは、0x00のようにコード化されなければなりません。
The Length field indicates the length, in octets, of the Payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 is used for the abort function.
Lengthフィールドは、ペイロードフィールドのオクテットで、長さを示します。 Lengthフィールドの最大値は65535オクテットです。 0x00のように符号化された長さフィールドは、アボート機能のために使用されます。
The CRC field is used to detect bit errors in the CPCS-PDU. A CRC-32 is used.
CRCフィールドは、CPCS-PDU内のビット誤りを検出するために使用されます。 CRC-32が使用されます。
LLC Encapsulation is needed when more than one protocol might be carried over the same VC. In order to allow the receiver to properly process the incoming AAL5 CPCS-PDU, the Payload Field contains information necessary to identify the protocol of the routed or bridged PDU. In LLC Encapsulation, this information MUST be encoded in an LLC header placed in front of the carried PDU.
複数のプロトコルが同じVC上で伝送されるかもしれないときLLCカプセル化が必要とされています。受信機が正しく受信AAL5 CPCS-PDUを処理することを可能にするために、ペイロードフィールドは、ルーティング又はブリッジPDUのプロトコルを識別するために必要な情報を含みます。 LLCカプセル化では、この情報を搭載PDUの前に置かれたLLCヘッダで符号化されなければなりません。
Although this memo only deals with protocols that operate over LLC Type 1 (unacknowledged connectionless mode) service, the same encapsulation principle also applies to protocols operating over LLC Type 2 (connection-mode) service. In the latter case the format and contents of the LLC header would be as described in IEEE 802.1 and IEEE 802.2.
このメモは、唯一のLLCタイプ1（未確認コネクションレスモード）サービス上で動作プロトコルを扱うが、同じカプセル化原理は、LLCタイプ2（接続モード）サービス上で動作するプロトコルに適用されます。後者の場合、LLCヘッダのフォーマット及び内容はとしてIEEE 802.1およびIEEE 802.2に記載されるであろう。
In LLC Encapsulation, the protocol type of routed PDUs MUST be identified by prefixing an IEEE 802.2 LLC header to each PDU. In some cases, the LLC header MUST be followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header. In LLC Type 1 operation, the LLC header MUST consist of three one octet fields:
LLCカプセル化では、ルーテッドPDUのプロトコルタイプは、各PDUにIEEE 802.2 LLCヘッダを付けることによって同定されなければなりません。いくつかのケースでは、LLCヘッダはIEEE 802.1aサブネットワーク接続ポイント（SNAP）ヘッダが続かなければなりません。 LLCタイプ1動作では、LLCヘッダは、三個の1つのオクテットフィールドで構成しなければなりません。
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+
In LLC Encapsulation for routed protocols, the Control field MUST be set to 0x03, specifying a Unnumbered Information (UI) Command PDU.
ルーティングされたプロトコルのためのLLCカプセル化では、制御フィールドは、非番号情報（UI）コマンドPDUを指定して、0x03のに設定しなければなりません。
The LLC header value 0xFE-FE-03 MUST be used to identify a routed PDU in the ISO NLPID format (see [6] and Appendix B). For NLPID-formatted routed PDUs, the content of the AAL5 CPCS-PDU Payload field MUST be as follows:
LLCヘッダ値0xFEの-FE-03（[6]および付録Bを参照）ISO NLPID形式でルーティングPDUを識別するために使用されなければなりません。次のようにNLPIDフォーマットルーテッドPDUに対して、AAL5 CPCS-PDUペイロードフィールドの内容でなければなりません。
Payload Format for Routed NLPID-formatted PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| NLPID (1 octet) |
+-------------------------------+
| . |
| PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+
The routed protocol MUST be identified by a one octet NLPID field that is part of Protocol Data. NLPID values are administered by ISO and ITU-T. They are defined in ISO/IEC TR 9577 [6] and some of the currently defined ones are listed in Appendix C.
ルーティングプロトコルは、プロトコルデータの一部である1つのオクテットNLPIDフィールドによって識別されなければなりません。 NLPID値は、ISOとITU-Tによって投与されます。これらは、[6] ISO / IEC TR 9577で定義されており、現在定義されているもののいくつかは、付録Cに記載されています
An NLPID value of 0x00 is defined in ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it has no significance within the context of this encapsulation scheme, a NLPID value of 0x00 MUST NOT be used.
$ 00のNLPID値がNullのネットワークレイヤまたは非アクティブセットとしてISO / IEC TR 9577で定義されています。それは、このカプセル化スキームの文脈の中で意味はありませんので、0x00のNLPIDの値を使用してはいけません。
Although there is a NLPID value (0xCC) that indicates IP, the NLPID format MUST NOT be used for IP. Instead, IP datagrams MUST be identified by a SNAP header, as defined below.
IPを示すNLPID値（0xCC）があるが、NLPIDフォーマットは、IPのために使用してはいけません。以下に定義される代わりに、IPデータグラムは、SNAPヘッダによって識別されなければなりません。
The presence of am IEEE 802.1a SNAP header is indicated by the LLC header value 0xAA-AA-03. A SNAP header is of the form
AM IEEE 802.1a SNAPヘッダの存在は、LLCヘッダーの値0xAAを-AA-03で示されています。 SNAPヘッダの形式であります
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+
The SNAP header consists of a three octet Organizationally Unique Identifier (OUI) and a two octet Protocol Identifier (PID). The OUI is administered by IEEE and identifies an organization which administers the values which might be assigned to the PID. The SNAP header thus uniquely identifies a routed or bridged protocol. The OUI value 0x00-00-00 indicates that the PID is an EtherType.
SNAPヘッダは、三オクテット組織固有識別子（OUI）および2つのオクテットプロトコル識別子（PID）から成ります。 OUIは、IEEEによって投与し、PIDに割り当てられる可能性がある値を管理する組織を識別しています。 SNAPヘッダは、このように一意にルーティング又はブリッジプロトコルを識別する。 PIDは、イーサタイプであることを示す0x00-00-00 OUI値。
The format of the AAL5 CPCS-PDU Payload field for routed non-NLPID Formatted PDUs MUST be as follows:
次のようにルーティングされた非NLPIDフォーマット済みのPDUのためのAAL5 CPCS-PDUペイロードフィールドのフォーマットでなければなりません。
Payload Format for Routed non-NLPID formatted PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-NLPID formatted PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
In the particular case of an IPv4 PDU, the Ethertype value is 0x08- 00, and the payload format MUST be:
IPv4のPDUの特定の場合では、イーサタイプ値は0x08- 00で、ペイロード・フォーマットでなければなりません。
Payload Format for Routed IPv4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IPv4 PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
This format is consistent with that defined in RFC 1042 [7].
このフォーマットは、[7] RFC 1042で定義されたものと一致しています。
In LLC Encapsulation, bridged PDUs are encapsulated by identifying the type of the bridged media in the SNAP header. The presence of the SNAP header MUST be indicated by the LLC header value 0xAA-AA-03. The OUI value in the SNAP header MUST be the 802.1 organization code 0x00-80-C2. The type of the bridged media MUST be specified by the two octet PID. The PID MUST also indicate whether the original Frame Check Sequence (FCS) is preserved within the bridged PDU. Appendix B provides a list of media type (PID) values that can be used in ATM encapsulation.
LLCカプセル化では、PDUはSNAPヘッダにブリッジメディアの種類を識別することによって、カプセル化され架橋。 SNAPヘッダの存在は、LLCヘッダーの値0xAAを-AA-03によって示さなければなりません。 SNAPヘッダ内OUI値は802.1組織コード0x00-80-C2でなければなりません。ブリッジメディアの種類は2オクテットPIDで指定する必要があります。 PIDはまた、元のフレームチェックシーケンス（FCS）が架橋PDU内に保存されているかどうかを示す必要があります。付録Bは、ATMカプセル化に使用することができるメディアタイプ（PID）値のリストを提供します。
The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST have one of the following formats. The necessary number of padding octets MUST be added after the PID field in order to align the Ethernet/802.3 LLC Data field, 802.4 Data Unit field, 802.5 Info field, FDDI Info field or 802.6 Info field (respectively) of the bridged PDU to begin at a four octet boundary. The bit ordering of the MAC address MUST be the same as it would be on the LAN or MAN (e.g., in canoncial form for bridged Ethernet/IEEE 802.3 PDUs, but in 802.5/FDDI format for bridged 802.5 PDUs).
ブリッジPDUを運ぶAAL5 CPCS-PDUペイロードフィールドは、次の形式のいずれかでなければなりません。開始するブリッジPDUのパディングオクテット必要な数のイーサネット/ 802.3 LLCデータフィールドを位置合わせするために、PIDフィールドの後に追加されなければならない、802.4データ単位フィールド、802.5情報フィールド、FDDI情報フィールドまたは802.6 Infoフィールド（それぞれ） 4つのオクテット境界で。 MACアドレスのビット順序は、LANやMAN上であろうと同じである（ブリッジイーサネット/ IEEE 802.3 PDUに対してcanoncial形で、例えば、しかし架橋802.5 PDUに対して802.5 / FDDI形式）しなければなりません。
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
The Ethernet/802.3 physical layer requires padding of frames to a minimum size. A bridge that uses uses the Bridged Ethernet/802.3 encapsulation format with the preserved LAN FCS MUST include padding. A bridge that uses the Bridged Ethernet/802.3 encapsulation format without the preserved LAN FCS MAY either include padding, or omit it. When a bridge receives a frame in this format without the LAN FCS, it MUST be able to insert the necessary padding (if none is already present) before forwarding to an Ethernet/802.3 subnetwork.
イーサネット/ 802.3物理レイヤは、最小サイズのフレームのパディングが必要です。使用するブリッジは、パディングを含まなければなりません保存LAN FCSをブリッジイーサネット/ 802.3カプセル化フォーマットを使用します。保存LAN FCSを含まないブリッジイーサネット/ 802.3カプセル化フォーマットを使用してブリッジにはパディングが含まれ、またはそれを省略してもよい（MAY）のいずれか。ブリッジは、LAN FCSなしの形式でフレームを受信した場合、（いずれも既に存在しない場合）、イーサネット/ 802.3サブネットワークに転送する前に、必要なパディングを挿入することができなければなりません。
Payload Format for Bridged 802.4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
Payload Format for Bridged 802.5 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| PAD 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
+-------------------------------+
Since the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork, it is treated by this encapsulation as the last octet of the three octet PAD field. It MAY be set to any value by the sending bridge and MUST be ignored by the receiving bridge.
802.5アクセス・コントロール（AC）フィールドはローカル802.5サブネットワーク外全く意味を持たないので、それは、三オクテットPADフィールドの最後のオクテットとしてカプセル化することによって治療されます。これは、送信ブリッジによって任意の値に設定することができ、受信ブリッジは無視しなければなりません。
Payload Format for Bridged FDDI PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
+-------------------------------+
Payload Format for Bridged 802.6 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ ------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
In bridged 802.6 PDUs, the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame. Therefore, the same PID value is used regardless of the presence or absence of the CRC-32 in the PDU.
架橋802.6のPDUでは、CRC-32の存在は、MACフレームのヘッダ内のCIBビットによって示されます。したがって、同一のPID値にかかわらず、PDUにCRC-32の存在下または非存在下のに使用されます。
The Common Protocol Data Unit (PDU) Header and Trailer are conveyed to allow pipelining at the egress bridge to an 802.6 subnetwork. Specifically, the Common PDU Header contains the BAsize field, which contains the length of the PDU. If this field is not available to the egress 802.6 bridge, then that bridge cannot begin to transmit the segmented PDU until it has received the entire PDU, calculated the length, and inserted the length into the BAsize field. If the field is available, the egress 802.6 bridge can extract the length from the BAsize field of the Common PDU Header, insert it into the corresponding field of the first segment, and immediately transmit the segment onto the 802.6 subnetwork. Thus, the bridge can begin transmitting the 802.6 PDU before it has received the complete PDU.
共通のプロトコルデータユニット（PDU）ヘッダとトレーラは802.6サブネットワークへの出口ブリッジでパイプライン化を可能にするように搬送されます。具体的には、共通のPDUヘッダはPDUの長さを含むBAsizeフィールドを含んでいます。このフィールドは、出口802.6ブリッジに利用できない場合、それは、全体のPDUを受信した長さを計算し、BAsizeフィールドに長さを挿入するまで、そのブリッジは、セグメント化されたPDUを送信し始めることができません。フィールドが利用可能である場合、出力802.6ブリッジは、共通PDUヘッダのBAsizeフィールドの長さを抽出する第一セグメントの対応するフィールドに挿入し、そして直ちに802.6サブネットワーク上のセグメントを送信することができます。したがって、ブリッジは、それが完全なPDUを受信した前802.6 PDUの送信を開始することができます。
Note that the Common PDU Header and Trailer of the encapsulated frame should not be simply copied to the outgoing 802.6 subnetwork because the encapsulated BEtag value may conflict with the previous BEtag value transmitted by that bridge.
カプセル化されたBEtag値はそのブリッジによって送信前BEtag値と競合する可能性があるため、一般的なPDUヘッダおよびカプセル化されたフレームのトレイラーが単に発信802.6サブネットワークにコピーされるべきではないことに留意されたいです。
An ingress 802.6 bridge can abort an AAL5 CPCS-PDU by setting its Length field to zero. If the egress bridge has already begun transmitting segments of the PDU to an 802.6 subnetwork and then notices that the AAL5 CPCS-PDU has been aborted, it may immediately generate an EOM cell that causes the 802.6 PDU to be rejected at the receiving bridge. Such an EOM cell could, for example, contain an invalid value in the Length field of the Common PDU Trailer.
入口802.6ブリッジはゼロにその長さフィールドを設定することにより、AAL5 CPCS-PDUを中止することができます。出口ブリッジは既に802.6サブネットワークにPDUのセグメントを送信し始め、その後、AAL5 CPCS-PDUが中止されたことを通知している場合、それは直ちに802.6 PDUが受信ブリッジに拒否させるEOMセルを生成してもよいです。このようなEOMセルは、例えば、一般的なPDUトレーラーの長さフィールドに無効な値が含まれている可能性があります。
Payload Format for BPDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
VC Multiplexing creates a binding between an ATM VC and the type of the network protocol carried on that VC. Thus, there is no need for protocol identification information to be carried in the payload of each AAL5 CPCS-PDU. This reduces payload overhead and can reduce per-packet processing. VC multiplexing can improve efficiency by reducing the number of cells needed to carry PDUs of certain lengths.
VC多重化は、ATM VCおよびそのVC上に担持ネットワークプロトコルのタイプとの間の結合を生成します。したがって、各AAL5 CPCS-PDUのペイロードで搬送されるプロトコル識別情報は不要です。これは、ペイロードのオーバーヘッドを低減し、パケットあたりの処理を減らすことができます。 VC多重化は、特定の長さのPDUを運ぶために必要な細胞の数を減少させることによって効率を向上させることができます。
For ATM PVCs, the type of the protocol to be carried over each PVC MUST be determined by configuration. For ATM SVCs, the negotiations specified in RFC 1755 [5] MUST be used.
ATMのPVCに、各PVC上で搬送されるプロトコルのタイプは、構成によって決定されなければなりません。 ATM SVCの場合、RFC 1755で指定された交渉は、[5]を使用しなければなりません。
PDUs of routed protocols MUST be carried as the only content of the Payload of the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU Payload field thus becomes:
ルーティングプロトコルのPDUはAAL5 CPCS-PDUのペイロードのコンテンツのみとして実行されなければなりません。 AAL5 CPCS-PDUペイロードフィールドのフォーマットは、このようになります。
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
PDUs of bridged protocols MUST be carried in the Payload of the AAL5 CPCS-PDU exactly as described in section 5.2, except that only the fields after the PID field MUST be included. The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST, therefore, have one of the following formats.
ブリッジプロトコルのPDUはPIDフィールドの後のフィールドのみを含まなければならないことを除いて、セクション5.2で説明したとおりにAAL5 CPCS-PDUのペイロードに実行されなければなりません。ブリッジPDUを運ぶAAL5 CPCS-PDUペイロードフィールドは、従って、以下の形式のいずれかでなければなりません。
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Payload Format for Bridged 802.4/802.5/FDDI PDUs
+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Note that the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork. It can thus be regarded as the last octet of the three octet PAD field, which in case of 802.5 can be set to any value (XX).
802.5アクセス・コントロール（AC）フィールドはローカル802.5サブネットワーク外全く意味を持たないことに留意されたいです。従って、802.5の場合には任意の値（XX）に設定することができる3つのオクテットPADフィールドの最後のオクテットとみなすことができます。
Payload Format for Bridged 802.6 PDUs
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
Payload Format for BPDUs
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
In case of Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs the presense or absence of the trailing LAN FCS shall be identified implicitly by the VC, since the PID field is not included. PDUs with the LAN FCS and PDUs without the LAN FCS are thus considered to belong to different protocols even if the bridged media type would be the same.
PIDフィールドが含まれていないので、イーサネット、802.3、802.4、802.5、およびFDDI PDUの場合にpresenseまたは末尾LAN FCSの不在は、VCによって暗黙的に識別されなければなりません。 LAN FCSなしLAN FCSとのPDUとPDUには、このように、ブリッジメディアタイプが同じになる場合でも、異なるプロトコルに属していると考えられています。
A bridge with an ATM interface that serves as a link to one or more other bridge MUST be able to flood, forward, and filter bridged PDUs.
一の以上の他のブリッジへのリンクとして機能するATMインタフェースを有するブリッジは、前方、フラッディングできなければならない、そしてフィルタはPDUをブリッジ。
Flooding is performed by sending the PDU to all possible appropriate destinations. In the ATM environment this means sending the PDU through each relevant VC. This may be accomplished by explicitly copying it to each VC or by using a point-to-multipoint VC.
フラッディングは、すべての可能な適切な宛先にPDUを送信することにより行われます。 ATM環境では、これは、各関連VCを通じてPDUを送信することを意味します。これは、明示的に各VCにコピーするか、ポイントツーマルチポイントVCを使用することによって達成することができます。
To forward a PDU, a bridge MUST be able to associate a destination MAC address with a VC. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a VC. Therefore, ATM bridges must provide enough information to allow an ATM interface to dynamically learn about foreign destinations beyond the set of ATM stations.
PDUを転送するには、ブリッジは、VCと、宛先MACアドレスを関連付けることができなければなりません。静的にVCを持つすべての可能な宛先MACアドレスの関連付けを設定するには、ブリッジを必要とするのは無理、おそらく不可能です。したがって、ATMブリッジは、ATMインターフェイスを動的ATM局のセットを超えた外国の目的地について学ぶことを可能にする十分な情報を提供しなければなりません。
To accomplish dynamic learning, a bridged PDU MUST conform to the encapsulation described in section 5. In this way, the receiving ATM interface will know to look into the bridged PDU and learn the association between foreign destination and an ATM station.
動的学習を達成するために、ブリッジPDUがこのようにセクション5に記載のカプセル化に適合しなければならない、受信したATMインタフェースは、ブリッジPDUに見て、外国の宛先とATM局との間の関連付けを学習することを知っているであろう。
The encapsulation defined in this section applies only to Virtual Private Networks (VPNs) that operate over an ATM subnet.
このセクションで定義されたカプセル化は唯一のATMのサブネット上で動作し、仮想プライベートネットワーク（VPN）に適用されます。
A mechanism for globally unique identification of Virtual Private multiprotocol networks is defined in [11]. The 7-octet VPN-Id consists of a 3-octet VPN-related OUI (IEEE 802-1990 Organizationally Unique Identifier), followed by a 4-octet VPN index which is allocated by the owner of the VPN-related OUI. Typically, the VPN-related OUI value is assigned to a VPN service provider, which then allocates VPN index values for its customers.
仮想プライベートマルチネットワークのグローバルに一意に識別するためのメカニズムが[11]で定義されています。 7オクテットVPN-IDは、VPN関連OUIの所有者によって割り当てられる4オクテットVPNインデックスに続く3オクテットVPN関連OUI（IEEE 802から1990組織固有識別子）、から成ります。典型的には、VPN関連OUI値は、その顧客のためのVPNインデックス値を割り当てるVPNサービスプロバイダに割り当てられます。
The format of the VPN encapsulation header is as follows:
次のようにVPNカプセル化ヘッダのフォーマットは次のとおりです。
VPN Encapsulation Header
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-5E |
+-------------------------------+
| PID 0x00-08 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| VPN related OUI (3 octets) |
+-------------------------------+
| VPN Index (4 octets) |
+-------------------------------+
| |
| (remainder of PDU) |
| |
+-------------------------------+
When the encapsulation header is used, the remainder of the PDU MUST be structured according to the appropiate format described in section 5 or 6 (i.e., the VPN encapsulation header is prepended to the PDU within an AAL5 CPCS SDU).
カプセル化ヘッダが使用される場合、PDUの残りの部分はセクション5又は6に記載のappropiateフォーマットに従って構成されなければならない（すなわち、VPNカプセル化ヘッダはAAL5 CPCS SDU内のPDUの先頭に付加されています）。
When a LLC-encapsulated routed or bridged PDU is sent within a VPN using ATM over AAL5, a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 5.1 and 5.2, respectively.
ルーティングLLCカプセル化またはPDU架橋をAAL5上ATM用いてVPN内で送信されると、VPNカプセル化ヘッダは、セクションそれぞれ5.1および5.2で定義された適切なルーティング又はブリッジPDUのフォーマットの前に付加されなければなりません。
When a routed or bridged PDU is sent within a VPN using VC multiplexing, the VPN identifier MAY either be specified a priori, using ATM connection control signalling or adminstrative assignment to an ATM interface, or it MAY be indicated using an encapsulation header.
ルーティングまたはPDU架橋はVC多重化を使用してVPN内で送信されると、VPN識別子は、ATMインターフェイスにATM接続制御シグナリングまたはの管理用の割り当てを使用して、事前に指定されてもよいか、それがカプセル化ヘッダを使用して示すことができます。
If the VPN is identified using ATM connection control signalling, all PDUs carried by the ATM VC are associated with the same VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively. If a PDU is received containing a VPN encapsulation header when the VPN has been identified using ATM signalling, the receiver MAY drop it and/or take other actions which are implementation specific. Specification of the mechanism in ATM connection control signalling for carrying VPN identifiers is outside the scope of this Memo.
VPNは、ATM接続制御シグナリングを使用して識別された場合、ATM VCによって運ばれるすべてのPDUが同じVPNに関連付けられています。この場合には、ルーティングとブリッジPDUのペイロードフォーマットはセクションそれぞれ6.1および6.2で定義されなければならないので。 VPNは、ATMシグナリングを使用して同定された場合にPDUをVPNカプセル化ヘッダを含む受信された場合、受信機は、それをドロップ及び/又は実装固有である他のアクションをとることができます。 VPN識別子を運ぶためのシグナリングATM接続制御メカニズムの仕様は、このメモの範囲外です。
If a VPN identifier is administratively assigned to an ATM interface, then all PDUs carried by any ATM VCs within that interface are associated with that VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively. If a PDU is received containing a VPN encapsulation header when the VPN identifier has been administratively assigned, the receiver MAY drop it and/or take other actions which are implementation specific. Specification of mechanisms (such as MIBs) for assigning VPN identifiers to ATM interfaces is outside the scope of this memo.
VPN識別子が管理ATMインターフェイスに割り当てられている場合、そのインタフェース内の任意のATMのVCによって運ばれるすべてのPDUがそのVPNに関連付けられています。この場合には、ルーティングとブリッジPDUのペイロードフォーマットはセクションそれぞれ6.1および6.2で定義されなければならないので。 PDUは、VPN識別子が管理割り当てられている場合、VPNカプセル化ヘッダを含む受信された場合、受信機は、それをドロップ及び/又は実装固有である他のアクションをとることができます。 ATMインターフェイスにVPN識別子を割り当てるための（例えば、MIBのような）機構の仕様は、このメモの範囲外です。
If the VPN identifier is to be indicated using an encapsulation header, then a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 6.1 and 6.2, respectively.
VPN識別子がカプセル化ヘッダを使用して示されるべきである場合、VPNカプセル化ヘッダは、セクションそれぞれ6.1および6.2で定義された適切なルーティング又はブリッジPDUのフォーマットの前に付加されなければなりません。
This memo defines mechanisms for multiprotocol encapsulation over ATM. There is an element of trust in any encapsulation protocol: a receiver must trust that the sender has correctly identified the protocol being encapsulated. There is no way to ascertain that the sender did use the proper protocol identification (nor would this be desirable functionality). The encapsulation mechanisms described in this memo are believed not to have any other properties that might be exploited by an attacker. However, architectures and protocols operating above the encapsulation layer may be subject to a variety of attacks. In particular, the bridging architecture discussed in section 7 has the same vulnerabilities as other bridging architectures.
このメモはATM上のマルチプロトコルカプセル化のためのメカニズムを定義します。任意のカプセル化プロトコルの信頼の要素があります：受信側は送信側が正しくカプセル化されたプロトコルを識別していることを信頼しなければなりません。送信者が適切なプロトコル識別を使用しました（でも、これは望ましい機能だろう）ことを確認する方法はありません。このメモで説明したカプセル化メカニズムは、攻撃者によって悪用される可能性のある他の特性を有することがないと考えられています。しかし、封入層の上に動作アーキテクチャおよびプロトコルは、攻撃の様々な被写体であってもよいです。具体的には、セクション7で説明したブリッジ・アーキテクチャは、他のブリッジングアーキテクチャと同じ脆弱性を有しています。
System security may be affected by the properties of the underlying ATM network. The ATM Forum has published a security framework [12] and a security specification [13] which may be relevant.
システムセキュリティは、基礎となるATMネットワークの特性によって影響を受ける可能性があります。 ATMフォーラムは、セキュリティフレームワーク[12]と関連し得るセキュリティ仕様[13]を発表しています。
Acknowledgements
謝辞
This memo replaces RFC 1483, which was developed by the IP over ATM working group, and edited by Juha Heinanen (then at Telecom Finland, now at Telia). The update was developed in the IP-over-NBMA (ION) working group, and Dan Grossman (Motorola) was editor and also contributed to the work on RFC 1483.
このメモはATMワーキンググループオーバーIPによって開発され、そして（今テリアで、その後テレコムフィンランドで、）ユハHeinanenによって編集されたRFC 1483に代わるものです。更新は、IP-オーバーNBMA（ION）ワーキンググループで開発された、とダン・グロスマン（モトローラ）は、エディタだったともRFC 1483での作業に貢献しました。
This material evolved from RFCs [1] and [4] from which much of the material has been adopted. Thanks to their authors Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello, and C. Lawrence. Other key contributors to the work included Brian Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN Technology).
この材料は、[1]のRFCから進化して、[4]材料の多くが採用されました。その作者テリー・ブラッドリー、Caralynブラウン、アンディMalis、デイブPiscitello、およびC.ローレンスに感謝します。仕事への他の重要な貢献者はブライアン・カーペンター（CERN）、ラオCherukuri（IBM）、ジョエル・ハルパーン（その後、ネットワークシステムで）、（現在ノキアのサン・マイクロシステムズ、）ボブHindenとゲイリーケスラー（MAN技術）を含んでいました。
The material concerning VPNs was developed by Barbara Fox (Lucent) and Bernhard Petri (Siemens).
VPNの関連材料はバーバラ・フォックス（ルーセント）とベルンハルト・ペトリ（シーメンス）によって開発されました。
References
リファレンス
[1] Piscitello, D. and C. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991.
[1] Piscitello、D.およびC.ローレンス、 "SMDSサービスオーバーIPデータグラムの送信"、RFC 1209、1991年3月。
[2] ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification", August 1996.
[2] ITU-T勧告I.363.5、1996年8月、 "B-ISDN ATMアダプテーションレイヤ（AAL）5仕様を入力"。
[3] ITU-T Recommendation I.365.1, "Frame Relaying Service Specific Convergence Sublayer (SSCS), November 1993.
[3] ITU-T勧告I.365.1、「フレームサービス特定コンバージェンスサブレイヤ（SSCS）、1993年11月をリレー。
[4] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.
[4]ブラウン、C.とA. Malis、 "フレームリレー上のマルチインターコネクト"、RFC 2427、1998年9月。
[5] Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[5]ペレスM.、Liaw、F.、マンキン、E.、グロスマン、D.およびA. Malis、 "ATMオーバーIP用のATMシグナリングサポート"、RFC 1755、1995年2月。
[6] Information technology - Telecommunications and Information Exchange Between Systems, "Protocol Identification in the Network Layer". ISO/IEC TR 9577, October 1990.
[6]情報技術 - 電気通信及びシステム間の情報交換、「ネットワーク層におけるプロトコルの識別」。 ISO / IEC TR 9577、1990年10月。
[7] Postel, J. and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[7]ポステル、J.、およびJ.レイノルズ、 "IEEE 802のネットワーク上のIPデータグラムの送信の規格"、STD 43、RFC 1042、1988年2月。
[8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331, April 1998.
[8]マー、M.、 "ATMシグナリングオーバーIP - SIG 4.0アップデート"、RFC 2331、1998年4月。
[9] ITU-T Recommendation I.555, "Frame Relay Bearer Service Interworking", September 1997.
[9] ITU-T勧告I.555、 "フレームリレーベアラサービスインターワーキング"、1997年9月。
[10] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10]ブラドナーの、S. "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[11]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、RFC 2685、1999年9月。
[12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998.
[12] ATMフォーラム、 "ATMセキュリティフレームワークのバージョン1.0"、AF-SEC-0096.000、1998年2月。
[13] The ATM Forum, "ATM Security Specification v1.0", af-sec-0100.001, February 1999.
[13] ATMフォーラム、 "ATMのセキュリティ仕様v1.0を"、AF-SEC-0100.001、1999年2月。
Appendix A. Multiprotocol Encapsulation over FR-SSCS
FR-SSCSオーバー付録A.マルチプロトコルのカプセル化
ITU-T Recommendation I.365.1 defines a Frame Relaying Specific Convergence Sublayer (FR- SSCS) to be used on the top of the Common Part Convergence Sublayer CPCS) of the AAL type 5 for Frame Relay/ATM interworking. The service offered by FR-SSCS corresponds to the Core service for Frame Relaying as described in I.233.
ITU-T勧告I.365.1フレームリレー/ ATMインターワーキングのためのAALタイプ5の共通部分収束サブレイヤCPCSの上に使用される特定収束サブレイヤ（FR-SSCS）を中継フレーム）を定義します。 I.233で説明したようにFR-SSCSによって提供されるサービスは、フレーム中継のためのコアサービスに対応しています。
An FR-SSCS-PDU consists of Q.922 Address field followed by Q.922 Information field. The Q.922 flags and the FCS are omitted, since the corresponding functions are provided by the AAL. The figure below shows an FR-SSCS-PDU embedded in the Payload of an AAL5 CPCS-PDU.
FR-SSCS-PDUは、Q.922情報フィールドに続くQ.922アドレスフィールドで構成されています。対応する機能は、AALによって提供されるのでQ.922フラグおよびFCSは、省略されています。以下の図は、AAL5 CPCS-PDUのペイロードに埋め込まれたFR-SSCS-PDUを示します。
FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
+-------------------------------+ -------
| Q.922 Address Field | FR-SSCS-PDU Header
| (2-4 octets) |
+-------------------------------+ -------
| . |
| . |
| Q.922 Information field | FR-SSCS-PDU Payload
| . |
| . |
+-------------------------------+ -------
| AAL5 CPCS-PDU Trailer |
+-------------------------------+
Routed and bridged PDUs are encapsulated inside the FR-SSCS-PDU as defined in RFC 2427. The Q.922 Information field starts with a Q.922 Control field followed by an optional Pad octet that is used to align the remainder of the frame to a convenient boundary for the sender. The protocol of the carried PDU is then identified by prefixing the PDU by an ISO/IEC TR 9577 Network Layer Protocol ID (NLPID).
RFC 2427で定義されるようにルーティングされ、ブリッジPDUはQ.922情報フィールドは、フレームの残りの部分を整列させるために使用されるオプションのパッドオクテット続いQ.922 Controlフィールドで始まりFR-SSCS-PDU内にカプセル化されています送信者のための便利な境界。実施PDUのプロトコルは、その後、ISO / IEC TR 9577ネットワークレイヤプロトコルID（NLPID）によってPDUを付けることによって識別されます。
In the particular case of an IP PDU, the NLPID is 0xCC and the FR-SSCS-PDU has the following format:
IP PDUの特定の場合では、NLPIDは0xCCであり、FR-SSCS-PDUは、次の形式を有します。
FR-SSCS-PDU Format for Routed IP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0xCC |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
Note that according to RFC 2427, the Q.922 Address field MUST be either 2 or 4 octets, i.e., a 3 octet Address field MUST NOT be used.
RFC 2427によれば、Q.922アドレスフィールドは2つのまたは4オクテット、即ち、3オクテットアドレスフィールドは使用してはいけませんのいずれかでなければなりません。
In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR-SSCS-PDU has the following format:
CLNP PDUの特定の場合では、NLPIDは0x81とし、FR-SSCS-PDUは、次の形式を有します。
FR-SSCS-PDU Format for Routed CLNP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0x81 |
+-------------------------------+
| . |
| Rest of CLNP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
Note that in case of ISO protocols the NLPID field forms the first octet of the PDU itself and MUST not be repeated.
ISOの場合にNLPIDフィールドはPDU自体の最初のオクテットを形成し、繰り返さないしなければならないプロトコルことに留意されたいです。
The above encapsulation applies only to those routed protocols that have a unique NLPID assigned. For other routed protocols (and for bridged protocols), it is necessary to provide another mechanism for easy protocol identification. This can be achieved by using an NLPID value 0x80 to indicate that an IEEE 802.1a SubNetwork Attachment Point (SNAP) header follows.
上記のカプセル化は唯一の割り当てられた固有のNLPIDを持っているそれらのルーティングプロトコルに適用されます。他のルーティングプロトコルのための（及び架橋プロトコールのため）、簡単なプロトコル識別のための別の機構を設ける必要があります。これは、IEEE 802.1aサブネットワーク接続ポイント（SNAP）ヘッダが続くことを示すためにNLPID値は0x80を使用することによって達成することができます。
See RFC 2427 for more details related to multiprotocol encapsulation over FRCS.
FRCS以上のマルチプロトコルのカプセル化に関連する詳細については、RFC 2427を参照してください。
Appendix B. List of Locally Assigned values of OUI 00-80-C2
OUI 00から80-C2のローカルに割り当てられた値の付録B.一覧
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-05 0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs
Appendix C. Partial List of NLPIDs
付録C. NLPIDsの部分的なリスト
0x00 Null Network Layer or Inactive Set (not used with ATM)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC Internet IP
Appendix D. Applications of multiprotocol encapsulation
マルチプロトコルのカプセル化の付録D.アプリケーション
Mutiprotocol encapsulation is necessary, but generally not sufficient, for routing and bridging over the ATM networks. Since the publication of RFC 1483 (the predecessor of this memo), several system specifications were developed by the IETF and the ATM Forum to address various aspects of, or scenarios for, bridged or routed protocols. This appendix summarizes these applications.
Mutiprotocolカプセル化は、ルーティングとATMネットワーク上でブリッジするため、十分に必要であるが、一般的ではありません。 RFC 1483（このメモの前身）の刊行以来、いくつかのシステム仕様は、様々な側面に対処するためにIETFとATMフォーラムによって開発された、またはシナリオの、架橋またはプロトコルをルーティングしました。この付録では、これらのアプリケーションをまとめたものです。
1) Point-to-point connection between routers and bridges -- multiprotocol encapsulation over ATM PVCs has been used to provide a simple point-to-point link between bridges and routers across an ATM network. Some amount of manual configuration (e.g., in lieu of INARP) was necessary in these scenarios.
1）ルータとブリッジ間のポイントツーポイント接続を - のATM PVC上のマルチプロトコルのカプセル化は、ATMネットワークを介してブリッジとルーターの間の単純なポイントツーポイントリンクを提供するために使用されてきました。 （がInARPの代わりに、例えば、）手動設定のいくつかの量は、これらのシナリオで必要でした。
2) Classical IP over ATM -- RFC 2225 (formerly RFC 1577) provides an environment where the ATM network serves as a logical IP subnet (LIS). ATM PVCs are supported, with address resolution provided by INARP. For ATM SVCs, a new form of ARP, ATMARP, operates over the ATM network between a host (or router) and an ATMARP server. Where servers are replicated to provide higher availability or performance, a Server Synchronization Cache Protocol (SCSP) defined in RFC 2335 is used. Classical IP over ATM defaults to the LLC/SNAP encapsulation.
ATM上2）古典的なIP - RFC 1577 2225（旧RFC）は、ATMネットワークは、論理IPサブネット（LIS）として機能する環境を提供します。 ATM PVCはがInARPによって提供されるアドレス分解能で、サポートされています。 ATM SVCの場合、ARP、ATMARP、新しい形のは、ホスト（またはルータ）とATMARPサーバ間のATMネットワーク上で動作します。サーバはより高い可用性やパフォーマンスを提供するために複製された場合は、RFC 2335で定義されたサーバーの同期キャッシュ・プロトコル（SCSP）が使用されています。 LLC / SNAPカプセル化へのクラシカルIP over ATMをデフォルトとします。
3) LAN Emulation -- The ATM Forum LAN Emulation specification provides an environment where the ATM network is enhanced by LAN Emulation Server(s) to behave as a bridged LAN. Stations obtain configuration information from, and register with, a LAN Emulation Configuration Server; they resolve MAC addresses to ATM addresses through the services of a LAN Emulation Server; they can send broadcast and multicast frames, and also send unicast frames for which they have no direct VC to a Broadcast and Unicast Server. LANE uses the VC multiplexing encapsulation foramts for Bridged Etherent/802.3 (without LAN FCS) or Bridged 802.5 (without LAN FCS) for the Data Direct, LE Multicast Send and Multicast Forward VCCS. However, the initial PAD field described in this memo is used as an LE header, and might not be set to all '0'.
3）LANエミュレーション - ATMフォーラムLANエミュレーション仕様では、ATMネットワークがブリッジLANとして動作するようにLANエミュレーションサーバ（複数可）によって強化された環境を提供します。駅は、から構成情報を取得し、そして、LANエミュレーション構成サーバに登録します。 ATMは、LANエミュレーションサーバーのサービスを介してアドレスに、彼らは、MACアドレスを解決します。彼らは、ブロードキャストおよびマルチキャストフレームを送信し、また、彼らは、ブロードキャストおよびユニキャストサーバーに直接VCを持っていないいるユニキャストフレームを送信することができます。レーンはデータダイレクト、LEマルチキャストのための送信およびマルチキャスト転送VCCSブリッジEtherent / 802.3（LAN FCSなし）のためのVC多重カプセル化foramtsを使用するか（LAN FCSなし）802.5架橋しました。しかしながら、このメモで説明した初期PADフィールドは、LEヘッダーとして使用され、そして全てに設定されていない可能性があります「0」。
4) Next Hop Resolution Protocol (NHRP) -- In some cases, the constraint that Classical IP over ATM serve a single LIS limits performance. NHRP, as defined in RFC 2332, extends Classical to allow 'shortcuts' over a an ATM network that supports several LISs.
4）ネクストホップ解決プロトコル（NHRP） - いくつかのケースでは、制約は、ATMを介したClassical IPは、単一のLIS限界性能を提供します。 NHRPは、RFC 2332で定義されているように、いくつかのLISをサポートしているATMネットワーク上のショートカット機能を可能にするために古典的な拡張します。
5) Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over ATM Specification integrates LANE and NHRP to provide a generic bridging/routing environment.
5）ATM上のマルチプロトコル（MPOA） - ATMの仕様を超えるATMフォーラムマルチプロトコルは、一般的なブリッジング/ルーティング環境を提供するために、LANEとNHRPを統合しています。
6) IP Multicast -- RFC 2022 extends Classical IP to support IP multicast. A multicast address resolution server (MARS) is used possibly in conjunction with a multicast server to provide IP multicast behavior over ATM point-to-multipoint and/or point to point virtual connections.
6）IPマルチキャスト - RFC 2022は、IPマルチキャストをサポートするために、古典的なIPを拡張します。マルチキャストアドレス解決サーバ（MARS）は仮想接続を指すようにATMポイントツーマルチポイントおよび/またはポイント上にIPマルチキャスト動作を提供するために、マルチキャストサーバと連携して、おそらく使用されています。
7) PPP over ATM -- RFC 2364 extends multiprotocol over ATM to the case where the encapsulated protocol is the Point-to-Point protocols. Both the VC based multiplexing and LLC/SNAP encapsulations are used. This approach is used when the ATM network is used as a point-to-point link and PPP functions are required.
ATM上7）PPP - RFC 2364は、カプセル化されたプロトコルは、ポイントツーポイントプロトコルである場合にATM上のマルチプロトコルを拡張します。 VCベースの多重化およびLLC / SNAPカプセル化の両方が使用されています。 ATMネットワークは、ポイントツーポイントリンクとして使用されるとき、このアプローチが使用され、PPP機能が必要とされます。
Appendix E Differences from RFC 1483
RFC 1483からの付録Eの違い
This memo replaces RFC 1483. It was intended to remove anachronisms, provide clarifications of ambiguities discovered by implementors or created by changes to the base standards, and advance this work through the IETF standards track process. A number of editorial improvements were made, the RFC 2119 [10] conventions applied, and the current RFC boilerplate added. The following substantive changes were made. None of them is believed to obsolete implementations of RFC 1483:
このメモは、それは、時代錯誤を削除曖昧実装によって発見またはベース基準への変更によって作成されたの明確化を提供し、IETF標準トラックプロセスを通じて、この作業を進めることを意図していたRFC 1483に置き換えられます。編集多くの改良が行われた、RFC 2119 [10]規則が適用され、現在のRFCボイラープレートを追加しました。以下の実質的な変更が行われました。それらのいずれも、RFC 1483の旧式の実装に信じられません。
-- usage of NLPID encapsulation is clarified in terms of the RFC 2119 conventions
- NLPIDのカプセル化の使用は、RFC 2119の規則の観点から明らかになりました
-- a pointer to RFC 2364 is added to cover the case of PPP over ATM
- RFC 2364へのポインタは、ATM上のPPPの場合をカバーするために添加されます
-- RFC 1755 and RFC 2331 are referenced to describe how encapsulations are negotiated, rather than a long-obsolete CCITT (now ITU-T) working document and references to work then in progress
- RFC 1755およびRFC 2331には、かなり進行して、その後動作するように文書と参照を作業長い時代遅れCCITT（現ITU-T）よりも、カプセル化がネゴシエートされている方法を説明するために参照されています
-- usage of AAL5 is now a reference to ITU-T I.363.5. Options created in AAL5 since the publication of RFC 1483 are selected.
- AAL5の使用は、現在ITU-TのI.363.5への参照です。 RFC 1483の出版以来、AAL5で作成されたオプションが選択されています。
-- formatting of routed NLPID-formatted PDUs (which are called "routed ISO PDUs" in RFC 1483) is clarified
- （RFC 1483で「ルーティングされたISOのPDU」と呼ばれている）でルーティングNLPIDフォーマットのPDUのフォーマットが明らかになりました
-- clarification is provided concerning the use of padding between the PID and MAC destination address in bridged PDUs and the bit ordering of the MAC address.
- 明確にブリッジのPDUにおけるPIDとMAC宛先アドレスとMACアドレスのビット順序との間のパディングの使用に関する設けられています。
-- clarification is provided concerning the use of padding of Ethernet/802.3 frames
- 明確化は、イーサネット/ 802.3フレームのパディングの使用について提供されます
-- a new encapuslation for VPNs is added
- VPN用の新しいカプセル化が追加されます
-- substantive security considerations were added
- 実質的なセキュリティ上の考慮事項が追加されました
-- a new appendix D provides a summary of applications of multiprotocol over ATM
- 新しい付録Dは、ATM上のマルチプロトコルのアプリケーションの概要を提供
Authors' Addresses
著者のアドレス
Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048
ダン・グロスマンモトローラ社20カボットブルバードマンスフィールド、MA 02048
EMail: dan@dma.isg.mot.com
メールアドレス：dan@dma.isg.mot.com
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
ユハわらテリアフィンランドMyyrmäentie2 01600ヴァンター、フィンランド
EMail: jh@telia.fi
メールアドレス：jh@telia.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。