RFC2684 日本語訳
2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5. D.Grossman, J. Heinanen. September 1999. (Format: TXT=51390 bytes) (Obsoletes RFC1483) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Grossman
Request for Comments: 2684 Motorola, Inc.
Obsoletes: 1483 J. Heinanen
Category: Standards Track Telia
September 1999
コメントを求めるワーキンググループD.グロースマン要求をネットワークでつないでください: 2684 モトローラは以下を時代遅れにします。 1483年のJ.Heinanenカテゴリ: 標準化過程冬胞子堆1999年9月
Multiprotocol Encapsulation over ATM Adaptation Layer 5
気圧適合層5の上のMultiprotocolカプセル化
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
このメモはRFC1483を取り替えます。 それはAALタイプ5でネットワーク内部連絡交通をATMの上まで運ぶための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ネットワークを使用する実現、ルータ、および橋でこの仕様が使用されることを意図します。
1. Introduction
1. 序論
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.
非同期なTransfer Mode(ATM)の広い領域、キャンパス、およびローカル・エリア・ネットワークは、ホストと、ルータと、橋と他のネットワーク装置の間のIPデータグラムと他のコネクションレスな交通を輸送するのに使用されます。 このメモはコネクションレスな発送されて橋を架けられたプロトコルData Units(PDUs)をATMネットワークの上まで運ぶための2つの方法を説明します。 方法が多重送信するのを許容する単独のATM仮想接続(VC)の上の複数のプロトコルの「LLCカプセル化。」 それぞれのPDUのプロトコルタイプは前に置かれたIEEE802.2Logical Link Control(LLC)ヘッダーによって特定されます。 「VCマルチプレクシング」方法で、各ATM VCはまさに1つのプロトコルタイプのPDUsを運びます。 複数のプロトコルが、輸送される必要があるとき、それぞれのための別々のVCがあります。
Grossman & Heinanen Standards Track [Page 1] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[1ページ]。
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の輸送のユニットはセルと呼ばれる長さのPDUが修理された53八重奏です。 セルは5八重奏ヘッダーと48バイトのペイロードから成ります。 このメモに記述されたものを含む可変長PDUsを送信機によって区分されて、48八重奏ATMセルペイロードを収まって、受信機で組み立て直さなければなりません。このメモはATM Adaptation Layerタイプ5(AAL5)の使用を指定します、ITU-T Recommendation I.363.5で[2] このために定義されるように。 可変長PDUsはAAL5 Common Part Convergence 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.
このメモは発送されて橋を架けられたPDUsがどう運ばれるかを直接AAL5 CPCSに説明するだけです、すなわち、AAL5のService Specific Convergence Sublayer(SSCS)が欠けているとき。 ITU-T Recommendation I.365.1[3]で定義されるFrame Relay Service Specific Convergence Sublayer(フラン-SSCS)がCPCSの上で使用されて、次に、発送されて、橋を架けられるなら、PDUsは、RFC2427[4]で説明された方法を多重送信しながらNLPIDを使用することで運ばれます。 Frame Relay Network Interworkingか透過モードService Interworking[9]が特別なケースですが、しかし、使用されて、2427年のカプセル化を使用しなければならないRFCは他のアプリケーションのためのNOT RECOMMENDEDです。 付録A(情報だけのためのものです)はRFCに従ったフラン-SSCSの上のIPとCLNP PDUsがどう要約されるかと同様にフラン-SSCS-PDU2427年の書式を示しています。
This memo also includes an optional encapsulation for use with Virtual Private Networks that operate over an ATM subnet.
また、このメモはATMサブネットの上で作動するVirtual兵士のNetworksとの使用のための任意のカプセル化を含んでいます。
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.
施設を使用するのが必要であるなら、同輩システムの間にPointからポイントへのプロトコル(PPP)のために設計されていて、二地点間関係を存在させるもの(当時のこのメモよりむしろRFC2364)が適用されます。
2. Conventions
2. コンベンション
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].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[10]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. Selection of the Multiplexing Method
3. マルチプレクシング方法の選択
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カプセル化は、「マルチ-プロトコル」環境で、より少ないVCsを必要とする傾向があります。 VCマルチプレクシングは、断片化オーバーヘッドを下げる傾向があります(例えば、どちらもIPかTCPオプションがあるTCPコントロールパケットを含むIPV4データグラムはまさに単細胞に収まります)。
Grossman & Heinanen Standards Track [Page 2] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[2ページ]。
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 Permanent Virtual Connection(PVC)の向こう側にコネクションレスなPDUsを交換したがっているとき、構成でマルチプレクシング方法の選択をします。 ATM接続コントロール合図手順は、ATM Switched Virtualコネクションズ(SVCs)が使用されていることであるときにカプセル化方法を交渉するのに用いられます。 [5]と[8]は、この交渉がどのように完了しているかを指定します。
4. AAL5 PDU Format
4. AAL5 PDU形式
For both multiplexing methods, routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU.
両方のマルチプレクシング方法において、AAL5 CPCS-PDUの有効搭載量分野の中で発送されて橋を架けられたPDUsを要約しなければなりません。
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) |
+-------------------------------+ -------
AAL5 CPCS-PDU形式+-------------------------------+ | . | | . | | CPCS-PDU有効搭載量| | 最大2^16--1八重奏) | | . | | . | +-------------------------------+ | PAD(0--47の八重奏) | +-------------------------------+ ------- | CPCS-UU(1つの八重奏) | +-------------------------------+ | CPI(1つの八重奏) | +-------------------------------+ CPCS-PDUトレーラ| 長さ(2つの八重奏) | +-------------------------------| | CRC(4つの八重奏) | +-------------------------------+ -------
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.
PAD分野は、セルの中でSAR副層によって作成された最後の48八重奏セルペイロードでCPCS-PDU Trailer権利を正当化するようにちょうどATMセルに収まるようにCPCS-PDUを水増しします。
Grossman & Heinanen Standards Track [Page 3] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[3ページ]。
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ユーザをユーザー情報に移すのに使用されます。 分野は、このメモで説明されたmultiprotocol ATMカプセル化によって使用されないで、どんな値にも設定されるかもしれません。
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. This field MUST be coded as 0x00.
CPI(一般的なPart Indicator)分野はCPCS-PDUトレーラを64ビットに並べます。 0×00としてこの分野をコード化しなければなりません。
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の八重奏です。 0×00としてコード化されたLength分野は放棄機能に使用されます。
The CRC field is used to detect bit errors in the CPCS-PDU. A CRC-32 is used.
CRC分野は、CPCS-PDUに噛み付いている誤りを検出するのに使用されます。 CRC-32は使用されています。
5. LLC Encapsulation
5. LLCカプセル化
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.
1つ以上のプロトコルが同じVCの上まで運ばれるかもしれないとき、LLC Encapsulationが必要です。 受信機が適切に入って来るAAL5 CPCS-PDUを処理するのを許容するために、有効搭載量Fieldは発送されたか橋を架けられたPDUのプロトコルを特定するのに必要な情報を含んでいます。 LLC Encapsulationでは、運ばれた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 Type1(不承認のコネクションレスなモード)サービスの上で作動するプロトコルに対処するだけですが、また、同じカプセル化原則はLLC Type2(接続モード)サービスの上で作動するプロトコルに適用されます。 後者の場合には、LLCヘッダーの形式とコンテンツがIEEE802.1とIEEE802.2で説明されるようにあるでしょう。
5.1. LLC Encapsulation for Routed Protocols
5.1. 発送されたプロトコルのためのLLCカプセル化
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 Encapsulationでは、IEEE802.2LLCヘッダーを各PDUへ前に置くことによって、発送されたPDUsのプロトコルタイプを特定しなければなりません。 いくつかの場合、IEEE 802.1a SubNetwork Attachment Point(SNAP)ヘッダーはLLCヘッダーについて来なければなりません。 LLC Type1操作では、LLCヘッダーは1つの八重奏がさばく3から成らなければなりません:
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+
+------+------+------+ | 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 Encapsulationでは、Control分野を0×03に設定しなければなりません、Unnumbered情報(UI)コマンドPDUを指定して。
Grossman & Heinanen Standards Track [Page 4] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[4ページ]。
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:
ISO NLPID形式で発送されたPDUを特定するのにLLCヘッダー値の0xFE-FE-03を使用しなければなりません([6]とAppendix Bを見てください)。 NLPIDによってフォーマットされた発送されたPDUsに関しては、AAL5 CPCS-PDU有効搭載量分野の内容は以下の通りであるに違いありません:
Payload Format for Routed NLPID-formatted PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| NLPID (1 octet) |
+-------------------------------+
| . |
| PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+
発送されたNLPIDによってフォーマットされたPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xFE-FE-03| +-------------------------------+ | NLPID(1つの八重奏)| +-------------------------------+ | . | | PDU| | (最大2^16--4つの八重奏) | | . | +-------------------------------+
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.
プロトコルDataの一部である1つの八重奏NLPID分野で発送されたプロトコルを特定しなければなりません。 NLPID値はISOとITU-Tによって管理されます。 それらはISO/IEC TRで定義されて、9577[6]と現在定義されたもののいくつかがAppendix 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.
0×00のNLPID値はISO/IEC TR9577でNull Network LayerかInactive Setと定義されます。 このカプセル化計画の文脈の中に意味を全く持っていないので、0×00の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)がありますが、IPにNLPID形式を使用してはいけません。 代わりに、SNAPヘッダーは以下で定義されるとして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
IEEE 802.1a SNAPはヘッダーです。存在、LLCヘッダー値の0xAA-AA-03によって示されます。 SNAPヘッダーはフォームのものです。
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+
+------+------+------+------+------+ | 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ヘッダーは3八重奏Organizationally Unique Identifier(OUI)と2八重奏プロトコルIdentifier(PID)から成ります。 OUIはIEEEによって管理されて、割り当てられるかもしれない値をPIDに施す組織を特定します。 その結果、SNAPヘッダーは唯一発送されたか橋を架けられたプロトコルを特定します。 OUIは0×00 00-00を評価します。PIDがEtherTypeであることを示します。
Grossman & Heinanen Standards Track [Page 5] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[5ページ]。
The format of the AAL5 CPCS-PDU Payload field for routed non-NLPID Formatted PDUs MUST be as follows:
発送された非NLPID Formatted PDUsのための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) |
| . |
+-------------------------------+
Routed非NLPIDのための有効搭載量FormatはPDUs+をフォーマットしました。-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 00-00| +-------------------------------+ | EtherType(2つの八重奏)| +-------------------------------+ | . | | 非NLPIDはPDUをフォーマットしました。| | (最大2^16--9つの八重奏) | | . | +-------------------------------+
In the particular case of an IPv4 PDU, the Ethertype value is 0x08- 00, and the payload format MUST be:
IPv4 PDUの特定の場合では、Ethertype値は0×08 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) |
| . |
+-------------------------------+
発送されたIPv4 PDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 00-00| +-------------------------------+ | EtherType0×08-00| +-------------------------------+ | . | | IPv4 PDU| | (最大2^16--9つの八重奏) | | . | +-------------------------------+
This format is consistent with that defined in RFC 1042 [7].
この形式はRFC1042[7]で定義されるそれと一致しています。
5.2. LLC Encapsulation for Bridged Protocols
5.2. 橋を架けられたプロトコルのためのLLCカプセル化
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 Encapsulationでは、橋を架けられたPDUsは、SNAPヘッダーの橋を架けられたメディアのタイプを特定することによって、要約されます。 LLCヘッダー値の0xAA-AA-03はSNAPヘッダーの存在を示さなければなりません。 SNAPヘッダーのOUI値は0×00 802.1組織コード80-C2でなければなりません。 2八重奏PIDは橋を架けられたメディアのタイプを指定しなければなりません。 また、PID MUSTは、オリジナルのFrame Check Sequence(FCS)が橋を架けられたPDUの中に保存されるかどうかを示します。 付録BはATMカプセル化に使用できるメディアタイプ(PID)値のリストを提供します。
Grossman & Heinanen Standards Track [Page 6] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[6ページ]。
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 MUSTを運ぶAAL5 CPCS-PDU有効搭載量分野は以下の形式の1つを持っています。 PID分野の後に4八重奏境界で始める橋を架けられたPDUのイーサネット/802.3LLC Data分野、802.4Data Unit分野、802.5Info分野、FDDI Info分野または802.6Info分野(それぞれ)を並べるために詰め物八重奏の必要な数を加えなければなりません。 MACアドレスを注文するビットはそれがLANかMAN(例えば、canoncialでは、橋を架けられたイーサネット/IEEE802.3PDUsのために形成しますが、802.5橋を架けられたPDUsのための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) |
+-------------------------------+
イーサネット/802.3橋を架けられたPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-01か0×00-07| +-------------------------------+ | 0×00-00を水増ししてください。| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(PIDが01 0×00-歳であるなら)| +-------------------------------+
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 MUSTがあるイーサネット/802.3カプセル化形式がそっと歩くのを含むBridgedを使用します。 保存されたLAN FCS MAYなしでBridgedイーサネット/802.3カプセル化形式を使用する橋は、そっと歩くのを含んでいるか、またはそれを忘れます。 橋がLAN FCSなしでこの形式でフレームを受けるとき、それは推進の前に必要な詰め物(なにも既に存在していないなら)をイーサネット/802.3サブネットワークに挿入できなければなりません。
Grossman & Heinanen Standards Track [Page 7] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[7ページ]。
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) |
+-------------------------------+
802.4橋を架けられたPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-02か0×00-08| +-------------------------------+ | 0×00 00-00を水増ししてください。| +-------------------------------+ | フレームControl(1つの八重奏)| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(PIDが02 0×00-歳であるなら)| +-------------------------------+
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) |
+-------------------------------+
802.5橋を架けられたPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-03か0×00-09| +-------------------------------+ | 0×00 00-XXを水増ししてください。| +-------------------------------+ | フレームControl(1つの八重奏)| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(PIDが03 0×00-歳であるなら)| +-------------------------------+
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.5Access Control(西暦)分野が地方の802.5サブネットワークの外に意味を全く持っていないので、それは3八重奏PAD分野の最後の八重奏としてこのカプセル化によって扱われます。 それを送付橋によってどんな値にも設定されるかもしれなくて、受信橋で無視しなければなりません。
Grossman & Heinanen Standards Track [Page 8] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[8ページ]。
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) |
+-------------------------------+
橋を架けられたFDDI PDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-04か0×00 0A| +-------------------------------+ | 0×00 00-00を水増ししてください。| +-------------------------------+ | フレームControl(1つの八重奏)| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(PIDが04 0×00-歳であるなら)| +-------------------------------+
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 |
| |
+-------------------------------+
802.6橋を架けられたPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID、0×00 0B| +---------------+---------------+ ------ | 予約されます。| BEtag| 一般的な+---------------+---------------+ PDU| BAsize| ヘッダー+-------------------------------+ ------- | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | | | 一般的なPDUトレーラ| | | +-------------------------------+
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橋を架けられたPDUsでは、CRC-32の存在はMACフレームのヘッダーでCIBビットによって示されます。 したがって、同じPID値はPDUのCRC-32の存在か不在にかかわらず使用されます。
Grossman & Heinanen Standards Track [Page 9] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[9ページ]。
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.
CommonプロトコルData Unit(PDU)ヘッダーとTrailerは、出口橋に802.6サブネットワークにパイプライン処理を許容するために運ばれます。 明確に、Common PDU HeaderはBAsize分野を含んでいます。(それは、PDUの長さを含みます)。 この分野が802.6が橋を架ける出口に利用可能でないなら、BAsize分野に全体のPDUを受けて、長さについて計算して、長さを挿入するまで、その橋は区分されたPDUを伝え始めることができません。 分野が利用可能であるなら、802.6が橋を架ける出口は、Common PDU HeaderのBAsize分野から長さを抽出して、最初のセグメントの対応する分野にそれを挿入して、すぐに、802.6サブネットワークにセグメントを伝えることができます。 したがって、橋は、完全なPDUを受ける前に802.6PDUを伝え始めることができます。
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値と闘争するかもしれないので要約のフレームのCommon PDU HeaderとTrailerが出発している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橋は、Length分野をゼロに設定することによって、AAL5 CPCS-PDUを中止できます。 出口橋が既にPDUのセグメントを802.6サブネットワークに伝え始めたか、そして、次にAAL5 CPCS-PDUが持っている通知が中止されて、それはすぐに、受信橋で802.6PDUを拒絶させるEOMセルを発生させるかもしれません。 例えば、そのようなEOMセルはCommon PDU TrailerのLength分野に無効の値を保管するかもしれません。
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) |
| |
+-------------------------------+
BPDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-0E| +-------------------------------+ | | | 定義されるBPDU| | 802.1(d)か802.1(g)| | | +-------------------------------+
6. VC Multiplexing
6. VCマルチプレクシング
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 MultiplexingはそのVCで運ばれたネットワーク・プロトコルのATM VCとタイプの間で結合を作成します。 したがって、プロトコル識別情報がそれぞれのAAL5 CPCS-PDUのペイロードで運ばれる必要は全くありません。 これは、ペイロードオーバーヘッドを下げて、1パケットあたりの処理を抑えることができます。 VCマルチプレクシングは、ある長さのPDUsを運ぶのに必要であるセルの数を減少させることによって、能率を増進できます。
Grossman & Heinanen Standards Track [Page 10] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[10ページ]。
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 PVCs、各PVC MUSTの上まで運ばれるべきプロトコルのタイプには、構成で、決定してください。 ATM SVCsのために、RFC1755[5]で指定された交渉を使用しなければなりません。
6.1. VC Multiplexing of Routed Protocols
6.1. 発送されたプロトコルのVCマルチプレクシング
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:
AAL5 CPCS-PDUの有効搭載量の唯一の内容として発送されたプロトコルのPDUsを運ばなければなりません。 その結果、AAL5 CPCS-PDU有効搭載量分野の形式はなります:
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
発送されたPDUs+のための有効搭載量形式-------------------------------+ | . | | 運ばれたPDU| | (最大2^16--1八重奏) | | . | | . | +-------------------------------+
6.2. VC Multiplexing of Bridged Protocols
6.2. 橋を架けられたプロトコルのVCマルチプレクシング
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.
セクション5.2のちょうど説明されるとしてのAAL5 CPCS-PDUの有効搭載量で橋を架けられたプロトコルのPDUsを運ばなければなりません、次々とPID分野だけを含まなければならないのを除いて。 AAL5 CPCS-PDU有効搭載量分野が橋を架けられたPDU MUSTを運んで、したがって、以下の形式の1つを持ってください。
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
イーサネット/802.3橋を架けられたPDUs+のための有効搭載量形式-------------------------------+ | 0×00-00を水増ししてください。| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(VCの依存するオプション)| +-------------------------------+
Grossman & Heinanen Standards Track [Page 11] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[11ページ]。
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) |
+-------------------------------+
橋を架けられた802.4/802.5/FDDI PDUs+のための有効搭載量形式-------------------------------+ | 0×00 00-00か0×00 00-XXを水増ししてください。| +-------------------------------+ | フレームControl(1つの八重奏)| +-------------------------------+ | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | LAN FCS(VCの依存するオプション)| +-------------------------------+
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.5Access Control(西暦)分野が地方の802.5サブネットワークの外に意味を全く持っていないことに注意してください。 その結果、それを3八重奏PAD分野の最後の八重奏と見なすことができます。(802.5の場合に、どんな値(XX)にも分野を設定できます)。
Payload Format for Bridged 802.6 PDUs
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
802.6橋を架けられたPDUs+のための有効搭載量形式---------------+---------------+ ------- | 予約されます。| BEtag| 一般的な+---------------+---------------+ PDU| BAsize| ヘッダー+-------------------------------+ ------- | MAC送付先アドレス| +-------------------------------+ | | | (MACフレームの残り) | | | +-------------------------------+ | | | 一般的なPDUトレーラ| | | +-------------------------------+
Payload Format for BPDUs
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
BPDUs+のための有効搭載量形式-------------------------------+ | | | 定義されるBPDU| | 802.1(d)か802.1(g)| | | +-------------------------------+
Grossman & Heinanen Standards Track [Page 12] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[12ページ]。
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の場合には、引きずっているLAN FCSの「前-感覚」か不在がVCによってそれとなく特定されるものとします、PID分野が含まれていないので。 橋を架けられたメディアタイプが同じであっても、LAN FCSとPDUsとLAN FCSのないPDUsが異なったプロトコルに属すとこのようにして考えられます。
7. Bridging in an ATM Network
7. 気圧ネットワークにおける橋を架けること
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インタフェースがある橋はPDUsに橋を架けました。
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に関連づけることができなければなりません。 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 MUSTを達成するには、セクション5で説明されたカプセル化に従ってください。 このように、受信ATMインタフェースは橋を架けられたPDUを調べて、外国目的地とATMステーションとの協会を学ぶのを知るでしょう。
8. Virtual Private Network (VPN) identification
8. 仮想の兵士のNetwork(VPN)識別
The encapsulation defined in this section applies only to Virtual Private Networks (VPNs) that operate over an ATM subnet.
このセクションで定義されたカプセル化はATMサブネットの上で作動するVirtual兵士のNetworks(VPNs)だけに適用されます。
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.
Virtual兵士の「マルチ-プロトコル」ネットワークのグローバルにユニークな識別のためのメカニズムは[11]で定義されます。 7八重奏のVPN-イドはVPN関連のOUIの所有者によって割り当てられる4八重奏のVPNインデックスがあとに続いた3八重奏のVPN関連のOUI(IEEE802-1990Organizationally Unique Identifier)から成ります。 通常、VPNの関連するOUI価値はVPNサービスプロバイダーに配属されます。(次に、それは、顧客のためにインデックス値をVPNに割り当てます)。
Grossman & Heinanen Standards Track [Page 13] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[13ページ]。
8.1 VPN Encapsulation Header
8.1 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) |
| |
+-------------------------------+
VPNカプセル化ヘッダー+-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUIの0×00 00-5のE| +-------------------------------+ | PID0×00-08| +-------------------------------+ | パッド0x00| +-------------------------------+ | VPNはOUI(3つの八重奏)を関係づけました。| +-------------------------------+ | VPN Index(4つの八重奏)| +-------------------------------+ | | | (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 MUSTでは、セクション5か6で説明されたappropiate形式に従って、構造化されてくださいか(すなわち、VPNカプセル化ヘッダーはAAL5 CPCS SDUの中のPDUにprependedされます)。
8.2 LLC-encapsulated routed or bridged PDUs within a VPN
8.2 VPNの中のLLCによって要約された発送されたか橋を架けられたPDUs
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.
VPNの中でAAL5の上でATMを使用することでLLCによって要約された発送されたか橋を架けられたPDUを送るとき、セクション5.1と5.2でそれぞれ定義された適切な発送されたか橋を架けられたPDU書式にVPNカプセル化ヘッダーをprependedしなければなりません。
8.3 VC multiplexing of routed or bridged PDUs within a VPN
8.3 VPNの中の発送されたか橋を架けられたPDUsのVCマルチプレクシング
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.
VPNの中でVCマルチプレクシングを使用することで発送されたか橋を架けられたPDUを送るとき、示された使用がカプセル化ヘッダーであったかもしれないならATM接続コントロール合図かadminstrative課題をATMインタフェース、またはそれに使用して、先験的にVPN識別子を指定するかもしれません。
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
VPNがATM接続コントロール合図を使用することで特定されるなら、ATM VCによって運ばれたすべてのPDUsが同じVPNに関連しています。 この場合、発送されて橋を架けられたPDUsのペイロード形式がセクション6.1と6.2でそれぞれ定義されるようにあるに違いありません。 PDUがVPNがあったとき、VPNカプセル化ヘッダーを含むのにおいて受け取られているなら
Grossman & Heinanen Standards Track [Page 14] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[14ページ]。
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.
ATM合図を使用することで特定されて、受信機は、他の実現特有の行動を、止める、そして/または、取るかもしれません。 このMemoの範囲の外に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によっても運ばれたすべてのPDUsがそのVPNに関連しています。 この場合、発送されて橋を架けられたPDUsのペイロード形式がセクション6.1と6.2でそれぞれ定義されるようにあるに違いありません。 PDUが行政上VPN識別子を割り当ててあるとき、VPNカプセル化ヘッダーを含むのにおいて受け取られているなら、受信機は、他の実現特有の行動を、止める、そして/または、取るかもしれません。 このメモの範囲の外にATMインタフェースへの識別子をVPNに割り当てるためのメカニズム(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識別子がカプセル化ヘッダーを使用することで示されることであるなら、セクション6.1と6.2でそれぞれ定義された適切な発送されたか橋を架けられたPDU書式にVPNカプセル化ヘッダーをprependedしなければなりません。
9. Security Considerations
9. セキュリティ問題
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 Forumはセキュリティフレームワーク[12]と関連するかもしれないセキュリティ仕様[13]を発表しました。
Grossman & Heinanen Standards Track [Page 15] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[15ページ]。
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.
ユハHeinanen(そしてテレコムフィンランドにおける現在、Teliaの)によってATMワーキンググループの上でIPによって開発されたRFC1483を取り替えて、編集されたこのメモ。 アップデートがIP過剰NBMA(ION)ワーキンググループで開発されて、ダン・グロースマン(モトローラ)は、エディタであり、また、RFC1483への作業に貢献しました。
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).
この材料は材料の多くが採用されたRFCs[1]と[4]から発展しました。 彼らの作者テリーブラッドリー(Caralynブラウン)のアンディMalis、デーヴPiscitello、およびC.ローレンスをありがとうございます。 仕事への他の主要な貢献者はブライアンCarpenter(CERN)、ラオCherukuri(IBM)、ジョエル・アルペルン(次にNetwork Systemsで)、ボブHinden(現在、ノキアのサン・マイクロシステムズ)、およびゲーリー・ケスラー(MAN Technology)を入れました。
The material concerning VPNs was developed by Barbara Fox (Lucent) and Bernhard Petri (Siemens).
VPNsに関する材料はバーバラフォックス(透明な)とバーンハード・ペトリ(シーメンス)によって発生されました。
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データグラムの送信」、RFC1209、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気圧適合層の(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] ブラウンとC.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC2427、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、「気圧でのIPの気圧合図サポート」RFC1755(1995年2月)。
[6] Information technology - Telecommunications and Information
Exchange Between Systems, "Protocol Identification in the
Network Layer". ISO/IEC TR 9577, October 1990.
[6]情報技術--テレコミュニケーションと情報Exchange Between Systems、「ネットワーク層における識別について議定書の中で述べてください。」 1990年10月のISO/IEC TR9577。
[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.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、STD43、RFC1042、1988年2月。
[8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331,
April 1998.
[8] マーヘル、M.、「気圧でのIP、4.0がアップデートする合図--SIG、」、RFC2331、4月1998日
Grossman & Heinanen Standards Track [Page 16] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[16ページ]。
[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. 「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[11]フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-
0096.000, February 1998.
[12] 「気圧セキュリティフレームワークバージョン1インチと、af秒-0096.000と、1998年2月」ATM Forum。
[13] The ATM Forum, "ATM Security Specification v1.0", af-sec-
0100.001, February 1999.
[13] ATM Forum、「ATM Security Specification v1.0"、af秒-0100.001、1999年2月。」
Grossman & Heinanen Standards Track [Page 17] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[17ページ]。
Appendix A. Multiprotocol Encapsulation over FR-SSCS
付録A.Multiprotocolカプセル化、フラン-SSCS
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.
Common Part Convergence Sublayer CPCSの先端で使用されるべきRecommendation I.365.1が定義するITU-tのa Frame Relaying Specific Convergence Sublayer(フランSSCS)) AALでは、Frame Relay/ATMの織り込むために5をタイプしてください。 フラン-SSCSによって提供されたサービスはI.233で説明されるようにFrame RelayingのためのCoreサービスに対応しています。
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.
フラン-SSCS-PDUはQ.922情報分野があとに続いたQ.922 Address分野から成ります。 対応する機能がAALによって提供されるので、Q.922旗とFCSは省略されます。 フラン-SSCS-PDUがAAL5 CPCS- 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 |
+-------------------------------+
AAL5 CPCS-PDU+の有効搭載量におけるフラン-SSCS-PDU-------------------------------+ ------- | Q.922アドレス・フィールド| フラン-SSCS-PDUヘッダー| (2-4 八重奏) | +-------------------------------+ ------- | . | | . | | Q.922情報フィールド| フラン-SSCS-PDU有効搭載量| . | | . | +-------------------------------+ ------- | AAL5 CPCS-PDUトレーラ| +-------------------------------+
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).
発送されて橋を架けられたPDUsはRFCで定義されるフラン-SSCS-PDU2427年に要約されます。 Q.922情報分野はQ.922 Control野原から始まります、続いて、送付者のためにフレームの残りを便利な境界に並べるのに使用される任意のPad八重奏から始まります。 そして、運ばれたPDUのプロトコルは、ISO/IEC TR9577Network Layer Protocol ID(NLPID)のそばにPDUを前に置くことによって、特定されます。
Grossman & Heinanen Standards Track [Page 18] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[18ページ]。
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です、そして、フラン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) |
| . |
+-------------------------------+
発送されたIP PDUs+のためのフラン-SSCS-PDU形式-------------------------------+ | Q.922 Addr分野| | (2か4つの八重奏) | +-------------------------------+ | 0×03 (Q.922コントロール)| +-------------------------------+ | NLPID 0xCC| +-------------------------------+ | . | | IP PDU| | (最大2^16--5つの八重奏) | | . | +-------------------------------+
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.
RFC2427によると、Q.922 Address分野が2か4つの八重奏であるに違いないというメモ、すなわち、3八重奏Address分野を使用してはいけません。
In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR- SSCS-PDU has the following format:
CLNP PDUの特定の場合では、NLPIDは0×81です、そして、フラン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) |
| . |
+-------------------------------+
発送されたCLNP PDUs+のためのフラン-SSCS-PDU形式-------------------------------+ | Q.922 Addr分野| | (2か4つの八重奏) | +-------------------------------+ | 0×03 (Q.922コントロール)| +-------------------------------+ | NLPID0x81| +-------------------------------+ | . | | CLNP PDUの残り| | (最大2^16--5つの八重奏) | | . | +-------------------------------+
Note that in case of ISO protocols the NLPID field forms the first octet of the PDU itself and MUST not be repeated.
NLPIDがさばくISOプロトコルの場合のそれが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 SubNetwork Attachment Point(SNAP)ヘッダーが続くのを示すのにNLPID値0x80を使用することによって、これを達成できます。
Grossman & Heinanen Standards Track [Page 19] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[19ページ]。
See RFC 2427 for more details related to multiprotocol encapsulation over FRCS.
FRCSの上で「マルチ-プロトコル」カプセル化に関連するその他の詳細に関してRFC2427を見てください。
Appendix B. List of Locally Assigned values of OUI 00-80-C2
OUI00-80-C2のLocally Assigned値の付録B.List
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
保存されたFCSメディアのない保存されたFCSと共に------------------ ----------------- -------------- 0×00-05の0×00-02の0×00-03の0×00-09 802.5の0×00-04の0×00-08 802.4の0×00 0A FDDIの0×00イーサネット0×00-01 0×00-07 802.3/0Bの802.6の0×00 0Dが0×00-0EのBPDUsを断片化します。
Appendix C. Partial List of NLPIDs
NLPIDsの付録のC.の部分的なリスト
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
0×00 ヌルNetwork LayerかInactive Set(ATMと共に使用されない)0×80SNAP0x81ISO CLNP0x82ISO ESIS0x83ISO ISIS0xCCインターネットIP
Appendix D. Applications of multiprotocol encapsulation
「マルチ-プロトコル」カプセル化の付録D.Applications
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ネットワークを切り抜けるのに十分ではありません。 RFC1483(このメモの前任者)の公表以来、いくつかのシステム仕様が種々相を記述するためにIETFとATM Forumによって開発された、シナリオ、橋を架けられたか発送されたプロトコル。 この付録はこれらのアプリケーションをまとめます。
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 PVCsの上の「マルチ-プロトコル」カプセル化は、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--RFC2225(以前RFC1577)はATMネットワークが論理的なIPサブネット(LIS)として機能するところに環境を提供します。 アドレス解決がINARPによって提供されている状態で、ATM PVCsは支持されます。 ATM SVCsに関しては、新しいフォームのアルプ(ATMARP)はホスト(または、ルータ)とATMARPサーバの間のATMネットワークの上で運転します。サーバが、より高い有用性か性能を提供するために模写されるところでは、RFC2335で定義されたServer Synchronization Cacheプロトコル(SCSP)は使用されています。 ATMの上の古典的なIPはLLC/SNAPカプセル化をデフォルトとします。
Grossman & Heinanen Standards Track [Page 20] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[20ページ]。
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 Emulation--ATM Forum LAN Emulation仕様はATMネットワークが橋を架けられたLANとして振る舞うためにLAN Emulation Server(s)によって高められるところに環境を提供します。 駅は、LAN Emulation Configuration Serverに設定情報を得て、登録します。 彼らはLAN Emulation ServerのサービスでATMアドレスにMACアドレスを決議します。 彼らは、放送とマルチキャストフレームを送って、また、それらがどんなダイレクトVCもBroadcastとUnicast Serverに持っていないユニキャストフレームを送ることができます。レーンは、Data Direct、LE Multicast Send、およびMulticast Forward VCCSにBridged Etherent/802.3(LAN FCSのない)かBridged802.5のためにカプセル化foramtsを多重送信しながら(LAN FCSなしで)、VCを使用します。 しかしながら、このメモで説明された初期の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に役立つという規制は性能を制限します。 RFC2332で定義されるNHRPは、ATMの上の'近道'に数個のLISsを支持するネットワークを許容するためにClassicalを広げています。
5) Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over
ATM Specification integrates LANE and NHRP to provide a generic
bridging/routing environment.
5) 気圧(MPOA)でのMultiprotocol -- ATM Specificationの上のATM Forum Multiprotocolは、一般的な橋を架ける/ルーティング環境を提供するためにレインと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 Multicast--RFC2022は、IPマルチキャストを支持するためにClassical IPを広げています。 マルチキャストアドレス解決サーバ(火星)は、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) ATMの上のPPP--RFC2364はATMの上で要約のプロトコルがPointからポイントへのプロトコルであるケースに「マルチ-プロトコル」を広げています。 VCのベースのマルチプレクシングとLLC/SNAPカプセル化の両方が使用されています。 ポイントツーポイント接続とPPP機能が必要であるようにATMネットワークが使用されているとき、このアプローチは使用されています。
Appendix E Differences from RFC 1483
RFC1483からの付録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:
このメモはRFC1483を取り替えます。 それは、時代錯誤を取り除いて、作成者によって発見されたか、またはベース規格への変化によって作成されたあいまいさの明確化を提供して、IETF標準化過程の過程でこの仕事を進めることを意図しました。 多くの編集の改良をしました、そして、RFC2119[10]コンベンションは適用されました、そして、現在のRFCの決まり文句は加えました。 以下の実質的な変更は行われました。 それらのどれかがRFC1483の実現を時代遅れにすると信じられていません:
Grossman & Heinanen Standards Track [Page 21] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[21ページ]。
-- usage of NLPID encapsulation is clarified in terms of the RFC 2119
conventions
-- NLPIDカプセル化の用法はRFC2119コンベンションに関してはっきりさせられます。
-- a pointer to RFC 2364 is added to cover the case of PPP over ATM
-- RFC2364へのポインタは、PPPに関するケースをATMの上にカバーするために加えられます。
-- 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
-- RFC1755とRFC2331は、カプセル化がその時進行中で働くためにどう長い時代遅れの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の参照です。 RFC1483の公表以来AAL5で作成されたオプションは選択されます。
-- formatting of routed NLPID-formatted PDUs (which are called
"routed ISO PDUs"
in RFC 1483) is clarified
-- 発送されたNLPIDによってフォーマットされたPDUs(どれが呼ばれるかがRFC1483で「ISO PDUsを発送した」)の形式ははっきりさせられます。
-- 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.
-- MACアドレスを注文しながらPIDとMACの間で橋を架けられたPDUsの送付先アドレスとビットを水増しすることの使用に関して明確化を提供します。
-- clarification is provided concerning the use of padding of
Ethernet/802.3 frames
-- イーサネット/802.3個のフレームの詰め物の使用に関して明確化を提供します。
-- a new encapuslation for VPNs is added
-- VPNsのための新しいencapuslationは加えられます。
-- 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カボーBlvd. マンスフィールド、MA 02048
EMail: dan@dma.isg.mot.com
メール: dan@dma.isg.mot.com
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
ユハ・Heinanen冬胞子堆フィンランドMyyrmaentie2 01600バンター(フィンランド)
EMail: jh@telia.fi
メール: jh@telia.fi
Grossman & Heinanen Standards Track [Page 22] RFC 2684 Multiprotocol Over AALS September 1999
グロースマンとHeinanen規格は1999年9月にAALSの上でRFC2684Multiprotocolを追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Grossman & Heinanen Standards Track [Page 23]
グロースマンとHeinanen標準化過程[23ページ]
一覧
スポンサーリンク
