RFC1483 日本語訳
1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. JuhaHeinanen. July 1993. (Format: TXT=35192 bytes) (Obsoleted by RFC2684) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Juha Heinanen
Reguest for Comments: 1483 Telecom Finland
July 1993
コメントのためにワーキンググループユハHeinanen Reguestをネットワークでつないでください: 1483 電子通信フィンランド1993年7月
Multiprotocol Encapsulation over ATM Adaptation Layer 5
気圧適合層5の上のMultiprotocolカプセル化
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.
このメモはネットワーク内部連絡交通をATM AAL5の上まで運ぶための2つのカプセル化方法を説明します。 最初の方法は、各プロトコルがATMの仮想のサーキットにもかかわらず、2番目の方法が仮定するシングルの上の複数のプロトコルですが、多重送信するのを別々のATM仮想のサーキットの上まで運ばれた状態で許容します。
1. Introduction
1. 序論
Asynchronous Transfer Mode (ATM) based networks are of increasing interest for both local and wide area applications. This memo describes two different methods for carrying connectionless network interconnect traffic, routed and bridged Protocol Data Units (PDUs), over an ATM network. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit. The protocol of a carried PDU is identified by prefixing the PDU by an IEEE 802.2 Logical Link Control (LLC) header. This method is in the following called "LLC Encapsulation" and a subset of it has been earlier defined for SMDS [1]. The second method does higher-layer protocol multiplexing implicitly by ATM Virtual Circuits (VCs). It is in the following called "VC Based Multiplexing".
非同期なTransfer Mode(ATM)ベースのネットワークは地方の、そして、広範の両方領域アプリケーションに関して増加しておもしろいです。 このメモはコネクションレスなネットワーク内部連絡交通を運ぶための2つの異なった方法を説明します、発送されて橋を架けられたプロトコルData Units(PDUs)、ATMネットワークの上で。 最初の方法で、ただ一つのATM仮想のサーキットにわたって複数のプロトコルを多重送信します。 運ばれたPDUのプロトコルは、PDUを前に置くことによって、IEEE802.2Logical Link Control(LLC)ヘッダーによって特定されます。 この方法は「LLCカプセル化」と呼ばれる以下にあります、そして、それの部分集合は先程SMDS[1]のために定義されました。 2番目の方法はATM Virtual Circuits(VCs)によってそれとなく多重送信される上位層プロトコルをします。 それは「VCはマルチプレクシングを基礎づけました」と呼ばれる以下にあります。
ATM is a cell based transfer mode that requires variable length user information to be segmented and reassembled to/from short, fixed length cells. This memo doesn't specify a new Segmentation And Reassembly (SAR) method for bridged and routed PDUs. Instead, the PDUs are carried in the Payload field of Common Part Convergence Sublayer (CPCS) PDU of ATM Adaptation Layer type 5 (AAL5) [2].
ATMによるセルが可変長ユーザー情報が短くて、固定された長さのセルからの/に区分されて、組み立て直されるのを必要とする転送モードを基礎づけたということです。 このメモは新しいSegmentation And Reassembly(SAR)方法を橋を架けられて発送されたPDUsに指定しません。 代わりに、PDUsはATM Adaptation Layerタイプ5(AAL5)[2]のCommon Part Convergence Sublayer(CPCS)PDUの有効搭載量分野で運ばれます。
Note that this memo only describes how routed and bridged PDUs are carried directly over the CPCS of AAL5, i.e., when the Service Specific Convergence Sublayer (SSCS) of AAL5 is empty. If Frame
このメモが発送されて橋を架けられたPDUsがどう運ばれるかを直接AAL5のCPCSに説明するだけであることに注意してください、すなわち、AAL5のService Specific Convergence Sublayer(SSCS)が空であるときに。 フレームです。
Heinanen [Page 1] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[1ページ]RFC1483Multiprotocol
Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in I.36x.1 [3], is used over the CPCS of AAL5, then routed and bridged PDUs are carried using the NLPID multiplexing method described in RFC 1294 [4]. 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 1294.
I.36x.1[3]で定義されるリレーService Specific Convergence Sublayer(フラン-SSCS)はAAL5のCPCSの上で使用されて、次に、発送されます、そして、橋を架けられたPDUsは、RFC1294[4]で説明された方法を多重送信しながらNLPIDを使用することで運ばれます。 付録A(情報だけのためのものです)はRFCに従ったフラン-SSCSの上のIPとCLNP PDUsがどう要約されるかと同様にフラン-SSCS-PDU1294年の書式を示しています。
2. Selection of the Multiplexing Method
2. マルチプレクシング方法の選択
It is envisioned that VC Based Multiplexing will be dominant in environments where dynamic creation of large numbers of ATM VCs is fast and economical. These conditions are likely to first prevail in private ATM networks. LLC Encapsulation, on the other hand, may be desirable when it is not practical for one reason or another to have a separate VC for each carried protocol. This is the case, for example, if the ATM network only supports (semi) Permanent Virtual Circuits (PVCs) or if charging depends heavily on the number of simultaneous VCs.
思い描かれて、そのVC Based Multiplexingが多くのATM VCsのダイナミックな創造が速くて、経済的であるところで環境で優位になるということです。 これらの状態は最初に、ATMネットワークが内緒で広がっていそうです。 何らかの理由にはそれぞれの運ばれたプロトコルのための別々のVCがあるのが、実用的でないときに、他方では、LLC Encapsulationは望ましいかもしれません。 例えば、ATMネットワークが(セミトレーラ)永久的なVirtual Circuits(PVCs)を支持するだけであるか、または充電が大いに同時のVCsの数によるなら、これはそうです。
When two ATM stations wish to exchange connectionless network interconnect traffic, selection of the multiplexing method is done either by manual configuration (in case of PVCs) or by B-ISDN signalling procedures (in case of Switched VCs). The details of B- ISDN signalling are still under study in CCITT [5]. It can, however, be assumed that B-ISDN signalling messages include a "Low layer compatibility" information element, which will allow negotiation of AAL5 and the carried (encapsulation) protocol.
2つのATMステーションがコネクションレスなネットワーク内部連絡交通を交換したがっているとき、手動の構成(PVCsの場合の)か手順を示すB-ISDN(Switched VCsの場合の)でマルチプレクシング方法の選択をします。 CCITT[5]にはB ISDN合図の詳細がまだ研究であります。 しかしながら、B-ISDN合図メッセージが「低層の互換性」情報要素を含んでいると思うことができます。(要素はAAL5の交渉と運ばれた(カプセル化)プロトコルを許容するでしょう)。
3. AAL5 Frame Format
3. AAL5フレーム形式
No matter which multiplexing method is selected, routed and bridged PDUs shall be encapsulated within the Payload field of AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU is given below:
方法を多重送信して、選択されて、発送されて、PDUsがAAL5 CPCS-PDUの有効搭載量分野の中で要約されるものとするのは、物質に橋を架けられません。 AAL5 CPCS-PDUの書式を以下に与えます:
Heinanen [Page 2] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[2ページ]RFC1483Multiprotocol
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を水増しします。
The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field has no function under the multiprotocol ATM encapsulation described in this memo and can be set to any value.
CPCS-UU(ユーザからユーザへの指示)分野は、透明にCPCSユーザをユーザー情報に移すのに使用されます。 分野は、このメモで説明されたmultiprotocol ATMカプセル化の下で機能を全く持たないで、どんな値にも設定できます。
The CPI (Common Part Indicator) field alings the CPCS-PDU trailer to 64 bits. Possible additional functions are for further study in CCITT. When only the 64 bit alignment function is used, this field shall be codes as 0x00.
CPI(一般的なPart Indicator)分野は64ビットにCPCS-PDUトレーラをalingsします。 CCITTにはさらなる研究には可能な追加機能があります。 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 protects the entire CPCS-PDU except the CRC field itself.
CRC分野自体を除いて、CRC分野は全体のCPCS-PDUを保護します。
4. LLC Encapsulation
4. LLCカプセル化
LLC Encapsulation is needed when several protocols are carried over the same VC. In order to allow the receiver to properly process the incoming AAL5 CPCS-PDU, the Payload Field must contain information
いくつかのプロトコルが同じVCの上まで運ばれるとき、LLC Encapsulationが必要です。 受信機が適切に入って来るAAL5 CPCS-PDUを処理するのを許容するために、有効搭載量Fieldは情報を含まなければなりません。
Heinanen [Page 3] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[3ページ]RFC1483Multiprotocol
necessary to identify the protocol of the routed or bridged PDU. In LLC Encapsulation this information is encoded in an LLC header placed in front of the carried PDU.
発送されたか橋を架けられた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 applies also to protocols operating over LLC Type 2 (connection-mode) service. In the latter case the format and/or contents of the LLC header would differ from what is shown below.
このメモはLLC Type1(不承認のコネクションレスなモード)サービスの上で作動するプロトコルに対処するだけですが、また、同じカプセル化原則はLLC Type2(接続モード)サービスの上で作動するプロトコルに適用されます。 後者の場合では、LLCヘッダーの形式、そして/または、コンテンツは以下に示されることと異なっているでしょう。
4.1. LLC Encapsulation for Routed Protocols
4.1. 発送されたプロトコルのためのLLCカプセル化
In LLC Encapsulation the protocol of the routed PDU is identified by prefixing the PDU by an IEEE 802.2 LLC header, which is possibly followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header. In LLC Type 1 operation, the LLC header consists of three one octet fields:
LLC Encapsulationでは、発送されたPDUのプロトコルは、PDUを前に置くことによって、IEEE802.2LLCヘッダーによって特定されます。(ヘッダーはことによるとIEEE 802.1a SubNetwork Attachment Point(SNAP)ヘッダーによってついて来られています)。 LLC Type1操作では、LLCヘッダーは1つの八重奏がさばく3から成ります:
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+
+------+------+------+ | DSAP| SSAP| Ctrl| +------+------+------+
In LLC Encapsulation for routed protocols, the Control field has always value 0x03 specifying Unnumbered Information Command PDU.
発送されたプロトコルのためのLLC Encapsulationでは、Control分野はいつもUnnumbered情報Command PDUを指定する値0x03を持っています。
The LLC header value 0xFE-FE-03 identifies that a routed ISO PDU (see [6] and Appendix B) follows. The Control field value 0x03 specifies Unnumbered Information Command PDU. For routed ISO PDUs the format of the AAL5 CPCS-PDU Payload field shall thus be as follows:
LLCヘッダー値の0xFE-FE-03は、発送されたISO PDU([6]とAppendix Bを見る)が続くのを特定します。 Control分野価値0x03はUnnumbered情報Command PDUを指定します。 その結果、AAL5 CPCS-PDU有効搭載量分野の形式は発送されたISO PDUsに関しては、以下の通りになるでしょう:
Payload Format for Routed ISO PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| . |
| ISO PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+
発送されたISO PDUs+のための有効搭載量形式-------------------------------+ | LLC 0xFE-FE-03| +-------------------------------+ | . | | ISO PDU| | (最大2^16--4つの八重奏) | | . | +-------------------------------+
The routed ISO protocol is identified by a one octet NLPID field that is part of Protocol Data. NLPID values are administered by ISO and CCITT. They are defined in ISO/IEC TR 9577 [6] and some of the currently defined ones are listed in Appendix C.
発送されたISOプロトコルはプロトコルDataの一部である1つの八重奏NLPID分野によって特定されます。 NLPID値はISOとCCITTによって管理されます。 それらは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
0×00のNLPID値はISO/IEC TR9577でNull Network LayerかInactive Setと定義されます。 それが中に意味を全く持っていないので
Heinanen [Page 4] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[4ページ]RFC1483Multiprotocol
the context of this encapsulation scheme, a NLPID value of 0x00 is invalid under the ATM encapsulation.
このカプセル化計画の文脈であり、0×00のNLPID値はATMカプセル化の下で無効です。
It would also be possible to use the above encapsulation for IP, since, although not an ISO protocol, IP has an NLPID value 0xCC defined for it. This format must not be used. Instead, IP is encapsulated like all other routed non-ISO protocols by identifying it in the SNAP header that immediately follows the LLC header.
また、IPに上のカプセル化を使用するのも可能でしょう、ISOプロトコルではありませんが、IPがそれのためにNLPID値の0xCCを定義させるので。 この形式を使用してはいけません。 代わりに、IPはすぐにLLCヘッダーについて来るSNAPヘッダーでそれを特定するのによる他のすべての発送された非ISOプロトコルのように要約されます。
The presence of a SNAP header is indicated by the LLC header value 0xAA-AA-03. A SNAP header is of the form
SNAPヘッダーの存在はLLCヘッダー値の0xAA-AA-03によって示されます。 SNAPヘッダーはフォームのものです。
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+
+------+------+------+------+------+ | OUI| PID| +------+------+------+------+------+
The three-octet Organizationally Unique Identifier (OUI) identifies an organization which administers the meaning of the following two octet Protocol Identifier (PID). Together they identify a distinct routed or bridged protocol. The OUI value 0x00-00-00 specifies that the following PID is an EtherType.
3八重奏のOrganizationally Unique Identifier(OUI)は以下の2八重奏プロトコルIdentifier(PID)の意味を管理する組織を特定します。 彼らは異なった発送されたか橋を架けられたプロトコルを一緒に、特定します。 OUIは0×00 00-00を評価します。以下のPIDがEtherTypeであると指定します。
The format of the AAL5 CPCS-PDU Payload field for routed non-ISO PDUs shall thus be as follows:
その結果、発送された非ISO PDUsのためのAAL5 CPCS-PDU有効搭載量分野の形式は以下の通りになるでしょう:
Payload Format for Routed non-ISO PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-ISO PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
発送された非ISO PDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 00-00| +-------------------------------+ | EtherType(2つの八重奏)| +-------------------------------+ | . | | 非ISO PDU| | (最大2^16--9つの八重奏) | | . | +-------------------------------+
In the particular case of an Internet IP PDU, the Ethertype value is 0x08-00:
インターネットIP PDUの特定の場合では、Ethertype値は0×08-00です:
Heinanen [Page 5] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[5ページ]RFC1483Multiprotocol
Payload Format for Routed IP PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
発送されたIP PDUs+のための有効搭載量形式-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 00-00| +-------------------------------+ | EtherType0×08-00| +-------------------------------+ | . | | IP PDU| | (最大2^16--9つの八重奏) | | . | +-------------------------------+
This is compatible with RFC 1042 [7]. Any changes in the header format specified in RFC 1042 should be followed by this memo.
これはRFC1042[7]と互換性があります。 このメモはRFC1042で指定されたヘッダー形式におけるどんな変化も支えるはずです。
4.2. LLC Encapsulation for Bridged Protocols
4.2. 橋を架けられたプロトコルのためのLLCカプセル化
In LLC Encapsulation bridged PDUs are encapsulated by identifying the type of the bridged media in the SNAP header. As with routed non-ISO protocols, the presence of the SNAP header is indicated by the LLC header value 0xAA-AA-03. With bridged protocols the OUI value in the SNAP header is the 802.1 organization code 0x00-80-C2 and the actual type of the bridged media is specified by the two octet PID. Additionally, the PID indicates whether the original Frame Check Sequence (FCS) is preserved within the bridged PDU. The media type (PID) values that can be used in ATM encapsulation are listed in Appendix B.
LLC Encapsulationでは、橋を架けられたPDUsは、SNAPヘッダーの橋を架けられたメディアのタイプを特定することによって、要約されます。 発送された非ISOプロトコルのように、SNAPヘッダーの存在はLLCヘッダー値の0xAA-AA-03によって示されます。 橋を架けられたプロトコルで、SNAPヘッダーのOUI値は0×00 802.1組織コード80-C2です、そして、橋を架けられたメディアの実際のタイプは2八重奏PIDによって指定されます。 さらに、PIDは、オリジナルのFrame Check Sequence(FCS)が橋を架けられたPDUの中に保存されるかどうかを示します。 ATMカプセル化に使用できるメディアタイプ(PID)値はAppendix Bに記載されています。
The AAL5 CPCS-PDU Payload field carrying a bridged PDU shall, therefore, have one of the following formats. Padding is added after the PID field if necessary in order to align the user information field of the bridged PDU at a four octet boundary.
したがって、橋を架けられたPDUを運ぶAAL5 CPCS-PDU有効搭載量分野は以下の形式の1つを持っているものとします。 必要なら、詰め物は、PID分野の後に4八重奏境界で橋を架けられたPDUのユーザ情報フィールドを並べるために加えられます。
Heinanen [Page 6] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[6ページ]RFC1483Multiprotocol
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-歳であるなら)| +-------------------------------+
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-歳であるなら)| +-------------------------------+
Heinanen [Page 7] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[7ページ]RFC1483Multiprotocol
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-歳であるなら)| +-------------------------------+
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 can be set to any value (XX).
802.5Access Control(西暦)分野が地方の802.5サブネットワークの外に意味を全く持っていないことに注意してください。 その結果、それを3八重奏PAD分野の最後の八重奏と見なすことができます。(どんな値(XX)にも分野を設定できます)。
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-歳であるなら)| +-------------------------------+
Heinanen [Page 8] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[8ページ]RFC1483Multiprotocol
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トレーラ| | | +-------------------------------+
Note that in bridged 802.6 PDUs, there is only one choice for the PID value, since the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame.
PID値のための1つの選択しか802.6橋を架けられたPDUsでは、ないことに注意してください、CRC-32の存在がMACフレームのヘッダーでCIBビットによって示されるので。
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
イングレス802.6橋は、Length分野をゼロに設定することによって、AAL5 CPCS-PDUを中止できます。 出口橋は既にPDUのセグメントを802.6サブネットワークに伝え始めたかどうか、そして、その時
Heinanen [Page 9] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[9ページ]RFC1483Multiprotocol
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.
AAL5 CPCS-PDUが持っている通知が中止されて、それはすぐに、受信橋で802.6PDUを拒絶させるEOMセルを発生させるかもしれません。 例えば、そのようなEOMセルはCommon PDU TrailerのLength分野に無効の値を保管するかもしれません。
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
+-------------------------------+ | LLC 0xAA-AA-03| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-0E| +-------------------------------+ | | | 定義されるBPDU| | 802.1(d)か802.1(g)| | | +-------------------------------+
5. VC Based Multiplexing
5. VCのベースのマルチプレクシング
In VC Based Multiplexing, the carried network interconnect protocol is identified implicitly by the VC connecting the two ATM stations, i.e. each protocol must be carried over a separate VC. There is therefore no need to include explicit multiplexing information in the Payload of the AAL5 CPCS-PDU. This results in minimal bandwidth and processing overhead.
VC Based Multiplexingでは、運ばれたネットワーク内部連絡プロトコルは2つのATMステーションをつなげるVCによってそれとなく特定されます、すなわち、別々のVCの上まで各プロトコルを運ばなければなりません。 したがって、AAL5 CPCS-PDUの有効搭載量に明白なマルチプレクシング情報を含む必要は全くありません。 これは最小量の帯域幅と処理オーバヘッドをもたらします。
As indicated above, the carried protocol can be either manually configured or negotiated dynamically during call establishment using signalling procedures. The signalling details will be defined later in other RFCs when the relevant standards have become available.
上で示されるように、呼び出し設立の間、合図手順を用いることでダイナミックに運ばれたプロトコルを手動で構成するか、または交渉できます。 後で関連規格が利用可能になったとき、合図の詳細は他のRFCsで定義されるでしょう。
5.1. VC Based Multiplexing of Routed Protocols
5.1. VCは発送されたプロトコルのマルチプレクシングを基礎づけました。
PDUs of routed protocols shall be carried as such in the Payload of the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU Payload field thus becomes:
発送されたプロトコルのPDUsはAAL5 CPCS-PDUの有効搭載量でそういうものとして運ばれるものとします。 その結果、AAL5 CPCS-PDU有効搭載量分野の形式はなります:
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
発送されたPDUs+のための有効搭載量形式-------------------------------+ | . | | 運ばれたPDU| | (最大2^16--1八重奏) | | . | | . | +-------------------------------+
Heinanen [Page 10] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[10ページ]RFC1483Multiprotocol
5.2. VC Based Multiplexing of Bridged Protocols
5.2. VCは橋を架けられたプロトコルのマルチプレクシングを基礎づけました。
PDUs of bridged protocols shall be carried in the Payload of the AAL5 CPCS-PDU exactly as described in section 4.2 except that only the fields after the PID field are included. The AAL5 CPCS-PDU Payload field carrying a bridged PDU shall, therefore, have one of the following formats.
橋を架けられたプロトコルのPDUsはちょうど次々とPID分野だけが含まれているのを除いて、セクション4.2で説明されるようにAAL5 CPCS-PDUの有効搭載量で運ばれるものとします。 したがって、橋を架けられたPDUを運ぶAAL5 CPCS-PDU有効搭載量分野は以下の形式の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の依存するオプション)| +-------------------------------+
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)にも分野を設定できます)。
Heinanen [Page 11] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[11ページ]RFC1483Multiprotocol
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)| | | +-------------------------------+
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が異なったプロトコルに属すとこのようにして考えられます。
6. Bridging in an ATM Network
6. 気圧ネットワークにおける橋を架けること
An ATM interface acting as a bridge must be able to flood, forward, and filter bridged PDUs.
橋が前方にあふれて、フィルターにかけることができなければならないように行動する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 multicast 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
PDUを進めるために、橋は送付先MACアドレスをVCに関連づけることができなければなりません。 それは無理であって、橋が静的に協会を構成するのが必要であるのが恐らく不可能である、あらゆる
possible destination MAC address with a VC. Therefore, ATM bridges
VCとの可能な送付先MACアドレス。 したがって、ATM橋
Heinanen [Page 12] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[12ページ]RFC1483Multiprotocol
must provide enough information to allow an ATM interface to dynamically learn about foreign destinations beyond the set of ATM stations.
ATMインタフェースが外国目的地に関してダイナミックにATMステーションのセットを超えて学ぶのを許容できるくらいの情報を提供しなければなりません。
To accomplish dynamic learning, a bridged PDU shall conform to the encapsulation described within section 4. 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はセクション4の中で説明されたカプセル化に従うものとします。 このように、受信ATMインタフェースは橋を架けられたPDUを調べて、外国目的地とATMステーションとの協会を学ぶのを知るでしょう。
7. For Further Study
7. さらなる研究に
Due to incomplete standardization of ATM multicasting, addressing, and signalling mechanisms, details related to the negotiation of the multiplexing method as well as address resolution had to be left for further RFCs.
ATMマルチキャスティングの不完全な標準化のため、メカニズムを記述して、合図して、アドレス解決と同様にマルチプレクシング方法の交渉に関連する詳細は一層のRFCsに残されなければなりませんでした。
Acknowledgements
承認
This document has evolved from RFCs [1] and [4] from which much of the material has been adopted. Thanks to their authors T. Bradley, C. Brown, A. Malis, D. Piscitello, and C. Lawrence. In addition, the expertise of the ATM working group of the IETF has been invaluable in completing the document. Special thanks Brian Carpenter of CERN, Rao Cherukuri of IBM, Dan Grossman of Motorola, Joel Halpern of Network Systems, Bob Hinden of Sun Mircosystems, and Gary Kessler of MAN Technology Corporation for their detailed contributions.
このドキュメントは材料の多くが採用されたRFCs[1]と[4]から発展しました。 彼らの作者T.ブラッドリー(C.ブラウン)のA.Malis、D.Piscitello、およびC.ローレンスをありがとうございます。 さらに、IETFのATMワーキンググループの専門的技術はドキュメントを完成するのにおいて非常に貴重です。 CERNの特別な感謝ブライアンCarpenter、IBMのラオCherukuri、モトローラのダン・グロースマン、Network Systemsのジョエル・アルペルン、Sun MircosystemsのボブHinden、および彼らの詳細な貢献のためのMAN Technology社のゲーリー・ケスラー。
Security Considerations
セキュリティ問題
Security issues are not addressed in this memo.
安全保障問題はこのメモに記述されません。
References
参照
[1] Piscitello, D. and Lawrence, C., "The Transmission of IP
Datagrams over the SMDS Service". RFC 1209, Bell Communications
Research, March 1991.
[1]PiscitelloとD.とローレンス、C.、「SMDSサービスの上のIPデータグラムの送信。」 RFC1209、ベルコミュニケーションズ・リサーチ、1991年3月。
[2] CCITT, "Draft Recommendation I.363". CCITT Study Group XVIII,
Geneva, 19 - 29 January, 1993.
[2]CCITT、「草稿推薦I.363。」 1993年のCCITT研究グループXVIII、ジュネーブ1月29日19--。
[3] CCITT, "Draft Recommendation I.36x.1". CCITT Study Group XVIII,
Geneva, 19-29 January, 1993.
[3]CCITT、「草稿推薦I.36x.1。」 1993年のCCITT研究グループXVIII、ジュネーブ1月19-29日。
[4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay". RFC 1294, Wellfleet
Communications, Inc. and BBN Communications, January 1992.
「Multiprotocolはフレームリレーの上でインタコネクトする」[4]ブラッドリーとT.とブラウン、C.とMalis、A.。 RFC1294とWellfleetコミュニケーションInc.とBBNコミュニケーション、1992年1月。
Heinanen [Page 13] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[13ページ]RFC1483Multiprotocol
[5] CCITT, "Draft text for Q.93B". CCITT Study Group XI, 23
September - 2 October, 1992.
[5] CCITT、「Q.93Bのための草案文面。」 9月23日--1992年10月2日のCCITT研究グループξ。
[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 Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, February,
1988.
[7] ポステルとJ.とレイノルズ、J.、「IEEE802ネットワークの上のIPデータグラムの送信の規格。」 RFC1042、ISI、1988年2月。
Appendix A. Multiprotocol Encapsulation over FR-SSCS
付録A.Multiprotocolカプセル化、フラン-SSCS
I.36x.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.
I.36x.1はFrame Relaying Specific Convergence Sublayerを定義します。Common Part Convergence Sublayer CPCSの先端で使用されるべき(フラン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 1294. 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/CCITT Network Layer Protocol ID (NLPID).
発送されて橋を架けられたPDUsはRFCで定義されるフラン-SSCS-PDU1294年に要約されます。 Q.922情報分野はQ.922 Control野原から始まります、続いて、送付者のためにフレームの残りを便利な境界に並べるのに使用される任意のPad八重奏から始まります。 そして、運ばれたPDUのプロトコルは、ISO/CCITT Network Layer Protocol 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です、そして、フランSSCS-PDUには、以下の形式があります:
Heinanen [Page 14] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[14ページ]RFC1483Multiprotocol
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 1294 the Q.922 Address field shall be either 2 or 4 octets, i.e., a 3 octet Address field is not supported.
Q.922 AddressがさばくRFC1294に応じて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 shall thus 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を使用することによって、これを達成できます。
See RFC 1294 for more details related to multiprotocol encapsulation over FRCS.
FRCSの上で「マルチ-プロトコル」カプセル化に関連するその他の詳細に関してRFC1294を見てください。
Heinanen [Page 15] RFC 1483 Multiprotocol over AAL5 July 1993
AAL5 July 1993の上のHeinanen[15ページ]RFC1483Multiprotocol
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
Author's Address
作者のアドレス
Juha Heinanen Telecom Finland PO Box 228 SF-33101 Tampere Finland
ユハHeinanen電子通信フィンランドPO Box228SF-33101タンペレフィンランド
Phone: +358 49 500 958
以下に電話をしてください。 +358 49 500 958
Email: Juha.Heinanen@datanet.tele.fi
メール: Juha.Heinanen@datanet.tele.fi
Heinanen [Page 16]
Heinanen[16ページ]
一覧
スポンサーリンク
