[要約] RFC 2684は、ATM Adaptation Layer 5上での多プロトコルカプセル化に関する仕様であり、ATMネットワーク上で異なるプロトコルをカプセル化するための方法を提供します。目的は、ATMネットワークでの異なるプロトコルの相互運用性を実現することです。
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
ATM適応レイヤー上のマルチプロトコルカプセル化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.
Copyright（c）The Internet Society（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.
このメモはRFC 1483に取って代わります。これは、ATMを超えるAALタイプ5にネットワーク相互接続トラフィックを運ぶための2つのカプセル化方法について説明しています。最初の方法では、単一のATM仮想接続にわたって複数のプロトコルを多重化することができますが、2番目の方法では、各プロトコルが個別の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 Multiplexing」メソッドでは、各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 Common Part Combrayence Sublayer（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 CPCSの上にルーティングとブリッジされたPDUがどのように直接運ばれるか、つまりAAL5のサービス固有の収束サブレイヤー（SSC）が存在しない場合にのみ説明します。ITU-Tの推奨I.365.1 [3]で定義されているように、フレームリレーサービス固有の収束サブレイヤー（FR-SSCS）がCPCを介して使用される場合、RFC 2427で説明されているNLPID多重化方法を使用してルーティングおよびブリッジされたPDUを運ぶ場合4]。RFC 2427カプセル化は、フレームリレーネットワークインターワーキングまたは透明モードサービスインターワーキング[9]を使用する特別なケースで使用する必要がありますが、他のアプリケーションには推奨されません。付録A（情報専用）は、FR-SSCS-PDUの形式と、RFC 2427に従ってFR-SSCを介してIPおよびCLNP 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].
キーワードは、このドキュメントに登場する場合、RFC 2119 [10]に記載されているように解釈される場合、必要な、必要、必要は、推奨されない、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨されない、または推奨されないようにしてはなりません。
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オプションも1つのセルに正確に収まることはありません）を含む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接続制御シグナル伝達手順は、ATMスイッチされた仮想接続（SVC）を使用する場合のカプセル化方法をネゴシエートするために使用されます。[5]および[8]は、この交渉がどのように行われるかを指定します。
For both multiplexing methods, routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU.
両方の多重化方法について、ルーティングされた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推奨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.
ペイロードフィールドには、最大2^16-1オクテットのユーザー情報が含まれています。
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をパッドにしてATMセルに正確に収まり、SARサブレイヤーによって作成された最後の48個のオクテットセルペイロードがCPCS-PDUトレーラーをセルで正当化するようにします。
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（共通部品インジケーター）フィールドは、CPCS-PDUトレーラーを64ビットに並べます。このフィールドは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.
長さフィールドは、ペイロードフィールドの長さをオクテット内の長さを示します。長さフィールドの最大値は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.
LLCカプセル化が必要な場合、同じVCを複数のプロトコルを運ぶ可能性があります。受信機が着信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 Type 1（UnackNowledged Connectionless Mode）サービスで動作するプロトコルのみを扱っていますが、同じカプセル化の原則は、LLC Type 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ヘッダーは3つの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カプセル化では、コントロールフィールドを0x03に設定して、非数情報（UI）コマンドPDUを指定する必要があります。
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を使用して、ISO NLPID形式でルーティングされたPDUを識別する必要があります（[6]および付録Bを参照）。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.
ルーティングされたプロトコルは、プロトコルデータの一部であるOne Octet NLPIDフィールドによって識別される必要があります。NLPID値はISOおよびITU-Tによって管理されます。それらはISO/IEC TR 9577 [6]で定義されており、現在定義されているもののいくつかは付録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.
0x00のNLPID値は、ISO/IEC TR 9577でNULLネットワークレイヤーまたは非アクティブセットとして定義されます。このカプセル化スキームのコンテキスト内で重要ではないため、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データグラムをスナップヘッダーによって識別する必要があります。
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スナップヘッダーの存在は、LLCヘッダー値0xAA-AA-03で示されています。スナップヘッダーはフォームです
+------+------+------+------+------+
| 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.
スナップヘッダーは、3つのOctet組織的に一意の識別子（OUI）と2つのOctetプロトコル識別子（PID）で構成されています。OUIはIEEEによって管理され、PIDに割り当てられる可能性のある値を管理する組織を識別します。したがって、スナップヘッダーは、ルーティングまたはブリッジ付きプロトコルを一意に識別します。OUI値0x00-00-00は、PIDが倫理であることを示しています。
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の特定のケースでは、EtherType値は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].
この形式は、RFC 1042 [7]で定義されている形式と一致しています。
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は、スナップヘッダーのブリッジメディアのタイプを識別することによりカプセル化されます。スナップヘッダーの存在は、LLCヘッダー値0xAA-AA-03で示さなければなりません。スナップヘッダーのOUI値は、802.1組織コード0x00-80-C2でなければなりません。ブリッジメディアのタイプは、2つのOctet 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ペイロードフィールドには、次の形式のいずれかが必要です。イーサネット/802.3 LLCデータフィールド、802.4データユニットフィールド、802.5情報フィールド、FDDI情報フィールド、または802.6情報フィールド（それぞれ）のブリッジングPDUの[それぞれ）を整列させるために、必要なパディングオクテットをPIDフィールドの後に追加する必要があります。4オクテットの境界で。MACアドレスのビット順序は、LANまたはMANの場合と同じでなければなりません（たとえば、ブリッジ付きイーサネット/IEEE 802.3 PDUの場合は、Bridged 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を使用したBridged Ethernet/802.3カプセル化形式を使用する必要があります。保存されたLAN FCSを使用せずにブリッジされたイーサネット/802.3カプセル化形式を使用するブリッジには、パディングが含まれるか、省略できます。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 Access Control（AC）フィールドはローカル802.5サブネットワーク以外では重要ではないため、このカプセル化により3つのオクテットパッドフィールドの最後のオクテットとして扱われます。送信ブリッジによって任意の価値に設定され、受信ブリッジによって無視されなければなりません。
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.
Bridged 802.6 PDUSでは、CRC-32の存在は、MACフレームのヘッダーにCIBビットによって示されます。したがって、PDUのCRC-32の有無に関係なく、同じPID値が使用されます。
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）ヘッダーとトレーラーは、Egress Bridgeで802.6サブネットワークにパイプラインを可能にするために伝えられます。具体的には、一般的なPDUヘッダーには、PDUの長さを含むBasizeフィールドが含まれています。このフィールドが出口802.6ブリッジで利用できない場合、そのブリッジは、PDU全体を受け取り、長さを計算し、長さをベース化場に挿入するまで、セグメント化されたPDUを送信し始めることができません。フィールドが利用可能な場合、出力802.6ブリッジは、一般的なPDUヘッダーのベース化フィールドから長さを抽出し、最初のセグメントの対応するフィールドに挿入し、すぐにセグメントを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値は、その橋から送信された以前のベータグ値と矛盾する可能性があるため、カプセル化されたフレームの一般的な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を中止できます。出口橋がすでにPDUのセグメントを802.6サブネットワークに送信し始めている場合、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 SVCSの場合、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.
Bridgedプロトコルの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 Access Control（AC）フィールドは、ローカル802.5サブネットワーク以外では重要ではないことに注意してください。したがって、これは、802.5の場合は任意の値（xx）に設定できる3つのオクテットパッドフィールドの最後のオクテットと見なすことができます。
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.
イーサネットの場合、802.3、802.4、802.5、およびFDDI PDUSの場合、PIDフィールドは含まれていないため、後続のLAN FCのプレセンスまたは不在はVCによって暗黙的に特定されるものとします。したがって、LAN FCを使用しないLAN FCと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.
1つ以上の他のブリッジへのリンクとして機能する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を転送するには、ブリッジが宛先MACアドレスをVCに関連付けることができなければなりません。すべての可能な宛先MACアドレスの関連性をVCと静的に構成するために橋を要求することは不合理であり、おそらく不可能です。したがって、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-OCTET VPN-IDは、3-OCTET VPN関連のOUI（IEEE 802-1990組織的に一意の識別子）で構成され、その後、VPN関連OUIの所有者によって割り当てられる4-OCTET VPNインデックスが続きます。通常、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.
AAL5を介してATMを使用してLLCカプセル化されたルーティングまたはブリッジされたPDUが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.
VCマルチプレックスを使用してルーティングまたはブリッジされたPDUが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シグナリングを使用して識別されたときにVPNカプセル化ヘッダーを含むPDUを受信した場合、受信機はそれをドロップしたり、実装固有の他のアクションをとることがあります。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 VCSによって運ばれるすべてのPDUは、そのVPNに関連付けられています。この場合、ルーティングおよびブリッジされたPDUのペイロード形式は、それぞれセクション6.1と6.2で定義されている必要があります。VPN識別子が管理上割り当てられたときにVPNカプセル化ヘッダーを含むPDUを受信した場合、受信者はそれをドロップしたり、実装固有の他のアクションをとることがあります。VPN識別子をATMインターフェイスに割り当てるためのメカニズム（MIBSなど）の仕様は、このメモの範囲外です。
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によって開発されたRFC 1483に取って代わり、Juha Heinanen（当時はTelecom Finland、現在はTelia）によって編集されています。このアップデートはIP-Over-NBMA（ION）ワーキンググループで開発され、Dan Grossman（Motorola）が編集者であり、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).
この材料は、材料の多くが採用されているRFC [1]および[4]から進化しました。著者のテリー・ブラッドリー、キャラリン・ブラウン、アンディ・マリス、デイブ・ピシテロ、C・ローレンスに感謝します。この作品へのその他の重要な貢献者には、ブライアンカーペンター（CERN）、ラオチェルクリ（IBM）、ジョエルハルパーン（当時ネットワークシステム）、ボブヒンデン（現在はノキアのサンマイクロシステム）、ゲイリーケスラー（マンテクノロジー）が含まれます。
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. Lawrence、「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、「B-ISDN ATM適応層（AAL）タイプ5仕様」、1996年8月。
[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] Brown、C。and A. Malis、「Multiprotocol Interconnect over Frame Relay」、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] Perez M.、Liaw、F.、Mankin、E.、Grossman、D。、およびA. Malis、「ATM上のIPのサポートのサポート」、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] Postel、J。およびJ. Reynolds、「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] Maher、M。、「IP Over ATM Signaling -Sig 4.0 Update」、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] Bradner、S。「要件レベルを示すためのRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[11] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、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月。
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-SSC）をリレーするフレームを定義します。FR-SSCが提供するサービスは、i.233で説明されているように、フレームリレーのコアサービスに対応しています。
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フラグとFCは省略されています。以下の図は、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は、FR-SSCS-PDU内にカプセル化されます。Q.922情報フィールドは、Q.922制御フィールドから始まり、その後、フレームの残りを整列するために使用されるオプションのパッドオクテットが続きます。送信者にとって便利な境界。その後、伝達された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が割り当てられているルーティングされたプロトコルにのみ適用されます。他のルーティングされたプロトコル（およびブリッジ型プロトコルの場合）の場合、簡単なプロトコル識別のための別のメカニズムを提供する必要があります。これは、NLPID値0x80を使用してIEEE 802.1Aサブネットワークアタッチメントポイント（SNAP）ヘッダーがフォローすることを示すことで実現できます。
See RFC 2427 for more details related to multiprotocol encapsulation over FRCS.
FRCS上のマルチプロトコルカプセル化に関連する詳細については、RFC 2427を参照してください。
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
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
0x00ヌルネットワークレイヤーまたは非アクティブセット（ATMで使用されていない）0x80スナップ0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xccインターネットIP
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.
2) ATM上のクラシックIP -RFC 2225（以前のRFC 1577）は、ATMネットワークが論理IPサブネット（LIS）として機能する環境を提供します。ATM PVCはサポートされており、アドレス解像度はINARPによって提供されます。ATM SVCの場合、ARPの新しい形式、ATMARPは、ホスト（またはルーター）とATMARPサーバーの間のATMネットワークを介して動作します。サーバーがより高い可用性またはパフォーマンスを提供するために複製されている場合、RFC 2335で定義されたサーバー同期キャッシュプロトコル（SCSP）が使用されます。ATM上のクラシックIPは、LLC/SNAPカプセル化にデフォルトです。
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エミュレーション仕様は、LANエミュレーションサーバーによってATMネットワークが強化され、ブリッジ付きLANとして動作する環境を提供します。ステーションLANエミュレーション構成サーバーから構成情報を取得し、登録します。それらは、LANエミュレーションサーバーのサービスを介してATMアドレスへのMACアドレスを解決します。ブロードキャストとマルチキャストフレームを送信することも、ブロードキャストおよびユニキャストサーバーに直接VCを持たないユニキャストフレームを送信できます。Laneは、VC Multiplexing Etherent/802.3（LAN FCSなし）にVC多重化カプセル化FORAMTSを使用するか、データダイレクト、LEマルチキャスト送信、およびマルチキャストフォワードVCCに802.5（LAN FCSなし）を使用します。ただし、このメモで説明されている最初のパッドフィールドは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) Next Hop Resolution Protocol（NHRP） - 場合によっては、ATM上のクラシックIPが単一のLISがパフォーマンスを制限するという制約がパフォーマンスを制限します。RFC 2332で定義されているNHRPは、いくつかのLISSをサポートする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フォーラムマルチプロトコルは、レーンと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.
7) PPP Over ATM-RFC 2364は、ATM上のマルチプロトコルを、カプセル化されたプロトコルがポイントツーポイントプロトコルである場合に拡張します。VCベースの多重化とLLC/SNAPカプセルの両方が使用されます。このアプローチは、ATMネットワークがポイントツーポイントリンクとして使用され、PPP関数が必要な場合に使用されます。
Appendix E Differences from RFC 1483
付録E RFC 1483との違い
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:
このメモはRFC 1483に取って代わりました。時代錯誤を削除し、実装者によって発見された曖昧さの明確化を提供するか、基本基準の変更によって作成された曖昧さの明確化を提供し、IETF標準のトラックプロセスを通じてこの作業を進めます。多くの編集上の改善が行われ、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
-ATM上のPPPのケースをカバーするために、RFC 2364へのポインターが追加されます
-- 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
- ルーティングされたNLPID形式のPDUのフォーマット（RFC 1483で「ルーティングされたISO 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.
- Bridged 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
Dan Grossman Motorola、Inc。20 Cabot Blvd.マンスフィールド、マサチューセッツ州02048
EMail: dan@dma.isg.mot.com
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vanta、フィンランド
EMail: jh@telia.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。