RFC1483


NetWorking Group
Juha Heinanen Request for Comments:1483                                        Telecom Finland
                                                                       July 1993
Request for Comments: 


            MultiprotocolEncapusulation over ATM Adaptation Layer 5

この論文のステータス

 このRFCはインターネットコミュニティのためのIAB標準トラックプロトコルを規定し、かつ改善のための議論と
提案を求めるものである。
このプロトコルの標準化状況およびステータスについては、「IAB公式プロトコル標準」の最新版を参照してください。
本論文の配布に制限はありません。

概要

 この論文はATM AALタイプ5におけるネットワーク・インターコネクト・トラフィックのためのカプセル化の2つの
方法を説明する。
第1の方法は単一ATMのVC(virtual cuicuit)上のマルチプルプロトコルの多重化を許し、第2の方法は各プロトコルが
別個のATMのVC上で搬送するとみなす。

1.はじめに

 ATM(非同期転送モード)ベースのネットワークは、ローカルとワイドエリアの双方のアプリケーションにとって
ますます興味深いものになっている。
本論文は、コネクションレスのネットワーク相互接続トラフィックのための異なる2つの方法を説明する。
ATMネットワーク上でのルーティングとブリッジのPDUs(Protocol Data Units)である。
第1の方法は単一のATMのVC(virtual circuit)上でマルチプルプロトコルの多重化をゆるす。
搬送PUDのプロトコルは IEEE 802.2 LLC(Logical Link Control)ヘッダをPDUの前に置くことで識別される。
この方法は以下で「LLCカプセル化」と呼ばれ、そのサブセットは、早くからSMDSとして定義されている「1」。
第2の方法はATM VCs(Virtual Circuits)によって暗黙のうちに上位層プロトコルの多重化を行う。
これは以下で「VCベースの多重化」と呼ばれる。
 ATMは可変長のユーザーインフォメーションを短い、固定長のセルに分割するかあるいは固定長のセルから再組み立てするよう
要求するセルベースの転送モードであり、。この論文はブリッジ及びルーティングPUDs用の新しいSAR(Segmentation And Reassembly)を
指定するものではない。その代わり、PUDsはAAL5(ATM Adaptation Layer type 5)のCPCS(Common Part Convergence Sublayer)
 PUDのPayloadフィールドで運ばれる。[2]
 本論文はルーティング及びブリッジPUDsがAAL5のCPCS上をどのように直接運ばれるかを説明するだけであるのに注意。
たとえば、AAL5のSSCS(Service Specific Convergence Sublayer)がエンプティのとき、FRーSSCS(Frame Relay Service Specific
 Convergence Sublayer)がI.36x.1で定義されたように[3]、AAL5のCPCSで使用されるなら、ルーティング及びブリッジPUDsはRFC1294で
説明されたNLPID多重化方法を使って搬送される[4]。
 付録A(インフォメーション用のみ)は、IPおよびCLNP PUDsがRFC 1294に従ってFR-SSCS上で如何にカプセル化するかだけでなく、
FR-SSCS-PUDのフォーマットも示す。

2.多重化方法の選択

 VCベースの多重化は 多数のATM VCsのダイナミックな生成が素早く効率的になされる環境では支配的であると考えられる。
これらの条件は、プライベートATMネットワークで最初に普及するであろう。
 一方、各々のキャリープロトコルに個別のVCを持つことがさまざまな理由で現実的でないとき、LLCカプセル化が望まれるであろう。
たとえば、ATMネットワークが(semi)PVC(Permanent Virtual Circuits)のみをサポートするとき、
あるいは課金が同時に起こるVCの数に大きく依存する時がそのケースである。

 2つのATMステーションがコネクションレスのネットワークの相互接続トラフィックを交換したいとき、多重化の方法がマニュアル・
コンフィギュレーション(PVCの場合)によってか、B-ISDNの信号手順(スイッチVCの場合)によって選択されるであろう。
B-ISDN信号の詳細は未だCCITTが研究中である[5]。しかしながら、B-ISDN信号メッセージは「下位層互換性」インフォメーションエレメントを
含んでいると考えられ、そのエレメントはAAL5と搬送された(カプセル化)プロトコルの交渉を認めることになるであろう。

3.AAL5 フレームフォーマット

 多重化方法が選択されても、ルーティングおよびブリッジPDUはAAL5 CPCS-PDUのPayloadフィールド内でカプセル化されるであろう。
AAL5 CPCS-PDUのフォーマットを次に示す。


                AAL5 CPCS-PDU フォーマット
               +-------------------------------+
               |                .            |
               |                .              |
               |       CPCS-PDU Payload        |
               |       最大 2^16 - 1 octets)   |
               |                .              |
               |                .              |
               +-------------------------------+
               |      PAD ( 0 - 47 octets)    |
               +-------------------------------+ -------
               |           CPCS-UU (1 octet )  |
               +-------------------------------+
               |           CPI (1 octet )      |
               +-------------------------------+      CPCS-PDU トレイラ
               |           Length (2 octets)   |
               +-------------------------------|
               |           CRC (4 octets)      |
               +-------------------------------+ -------

 Payloadフィールドは最大2^16-1オクテッドのユーザーインフォメーションを含んでいる。

 PADフィールドは、SARサブレイヤによって生成された最後の48オクテッドのセルのペイロードがセルの中でぴったり調整された
CPCS-PDUトレイラを持つようにATMセルに正確にフィットさせるためCOCS-PDUをパディングする。
 
 CPCS-UU(User to User indecation 、CPCSユーザー間表示)このフィールドは、CPCSユーザー間情報をありのまま転送するのに用いられる。
フィールドは本論文で述べられるマルチプロトコルATMカプセル化の下では何の機能もなく、いかなる値も設定できる。

 CPI(Common Part Indicator,共通部種別表示)フィールドは、CPCS-PDUトレイラを64ビットに調整する。
可能な付加機能はCCITTの更なる研究用である。
64ビット調整機能のみが使われるとき、このフィールドは0x00とコーディングされる。

 Lengthフィールドは Peyload フィールドのlength(長さ)をオクテッドで示す。
lengthフィールドの最大値は65535オクテッドである。lengthフィールドが0x00とコーディングされると、
アボート機能として用いられる。

 CRCフィールドはCRCフィールド自体を除いた全CPCS-PDUを保護する。

4. LLC カプセル化

 LLCカプセル化は、いくつかのプロトコルが同じVCで運ばれるとき必要とされる。
受信者が、入ってくるAAL5 CPCS-PDUを正しく処理するために、Peyloadフィールドは、ルーティングあるいは
ブリッジPDUのプロトコルを識別するのに必要な情報を含んでいなければならない。
LLCカプセル化ではこの情報はキャリーPDUの前に置かれたLLCヘッダでエンコードされる。

 本論文はLLCタイプ1(確認応答なしコネクションレスモード)サービス上で操作するプロトコルのみを扱うが、
同じカプセル化原則はLLCタイプ2(コネクションモード)サービス上で操作するプロトコルにも適用する。
後者のケースでは、LLCヘッダのフォーマット及び/あるいは内容は以下に示すものとは異なっている。

4.ルーティングプロトコルのLLCカプセル化

 LLCカプセル化で、ルーティングPDUのプロトコルはIEEE 802.2 LLCヘッダを前に置いたPDUにより識別され、
そのヘッダはIEEE 802.1a SNAP(SubNetwork Attachment Point)ヘッダを従えている。
LLCタイプ1の操作で、LLCヘッダは3つの1オクテッドフィールドで成り立つ。

           +------+------+------+
              | DSAP | SSAP | Ctrl |
              +------+------+------+

 ルーティングプロトコルのLLCカプセル化では、Controlフィールドは常に0x03の値を持ちUnnumbered Information Command PUDを指定する。

 LLCヘッダ値 0xFE-FE-03はルーティングISO PDUが次に続くことを識別する([6]及び付録Bを参照のこと)
Controlフィールド値0x03はUnnumbered Information Command PDUを指定する。
ルーティングISO PDUのための、AAL5 CPCS-PDU Payloadフィールドのフォーマットは次の通りである。               

      ルーティングISO PDUのPayloadフォーマット 
               +-------------------------------+
               |       LLC  0xFE-FE-03         |
               +-------------------------------+
               |             .                 |
               |           ISO PDU             |
               |     (最大 2^16 - 4 octets)   |
               |             .                 |
               +-------------------------------+

  ルーティングISOプロトコルはプロトコルデータの一部である1オクテッドのNLPIDフィールドによって識別される。
NLPID値はISO及びCCITTによって管理される。
それらは、ISO/IEC TR 9577で定義され[6]、そして現在定義されているもののいくつかは、付録Cに列記する。
 
 0x00のNLPID値はISO/IEC 9577でNull Network LayerあるいはInactive Setとして定義される。
このカプセルの状況の中で意味を持たないので、0x00のNLPID値はATMカプセル化の下で無効である。

 IPに上記のカプセル化を使うことも可能である。
ISOプロトコルではないが、IPは、それに対して定義されたNLPID値0x00を持っているからである。
このフォーマットは使うべきでない。その代わり、IPはLLCヘッダの直後に続くSNAPヘッダでそれを識別することで
他のすべてのルーティングnon-ISOプロトコル同様カプセル化される

 SNAPヘッダの存在は,LLCヘッダ値0xAA-AA-03によって示される。SNAPヘッダの形式は以下の通りである。、

               +------+------+------+------+------+
               |  OUI |     PID                   |
               +------+------+------+------+------+

   3オクテッドのOUI(Organizationally Unique Identifier)は次の2オクテッドのPID(Protocol Identifier)の
意味を管理する構造を識別する。それらはともに明確なルーティングあるいはブリッジプロトコルを識別する。
OUI値0x00-00-00は、続くPIDがEtherTypeであることを指定する。

 ルーティング non-ISO PDU用のAAL5 CPCS-PDU Payloadフィールドのフォーマットは以下の通りである。

            ルーティング non-ISO PDU の Payloadフォーマット 
               +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-00-00         |
               +-------------------------------+
               |     EtherType (2 octets)      |
               +-------------------------------+
               |             .                 |
               |         Non-ISO PDU           |
               |     (最大 2^16 - 9 octets)   |
               |             .                 |
               +-------------------------------+

   インターネットIP PDUの特殊なケースでは、Ethertype値は0x08-00である。

              ルーティング IP PDU の Payloadフォーマット  
               +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-00-00         |
               +-------------------------------+
               |       EtherType 0x08-00       |
               +-------------------------------+
               |             .                 |
               |           IP PDU              |
               |     (最大 2^16 - 9 octets)   |
               |             .                 |
               +-------------------------------+

   これは、RFC 1042と互換性がある[7]。
  RFC 1042で指定されたヘッダフォーマットでのいかなる変更も本論文によって継承されるべきである。

4.2.  ブリッジプロトコルのためのLLC カプセル化

  LLCカプセル化において、ブリッジPDUはSNAPヘッダでブリッジ媒体のタイプを識別することでカプセル化される。
ルーティングnon-ISOプロトコルで、SNAPヘッダの存在は、値が0xAA-AA-03のLLCヘッダにより示される。ブリッジプロトコルで、
SNAPヘッダのOUI値は802.1構造コード0x00-80-C2であり、ブリッジ媒体の実際のタイプは2オクテッドのPIDによって指定される。
  加えて、PIDはオリジナルのFCS(Frame Check Sequence)がブリッジPDU内で保存されているかどうかを示している。
ATMカプセル化で使われる媒体タイプ(PID)値を付録Bに示す。

 ブリッジPDUを運ぶAAL5 CPCS-PDU Payloadフィールドは、それゆえ次のフォーマットの1つを持つであろう。
必要なら、ブリッジPDUのユーザーインフォメーションフィールドを4オクテッドの区切りで調整するためPIDフールドをパディングする。

            ブリッジ Ethernet/802.3 PDUのPayloadフォーマット
               +-------------------------------+
               |       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.4 PDU の Payloadフォーマット 
               +-------------------------------+
               |       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.5 PDU の Payloadフォーマット 
               +-------------------------------+
               |       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 のAC(Access Control)フィールドはローカル802.5サブネットの外では意味を持たないとことに注意。
それはどのような値(XX)もセットできる3オクテッドのPADフィールドの最後のオクテットとして見なされる。

              ブリッジ FDDI PDU の Payloadフォーマット 
               +-------------------------------+
               |       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)  |
               +-------------------------------+


            ブリッジ 802.6 PDU の Payloadフォーマット 
               +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-80-C2         |
               +-------------------------------+
               |         PID 0x00-0B           |
               +---------------+---------------+ ------
               |   Reserved    |     BEtag     |  Common
               +---------------+---------------+  PDU
               |            BAsize             |  ヘッダ
               +-------------------------------+ -------
               |    MAC destination address    |
               +-------------------------------+
               |                               |
               |   (remainder of MAC frame)    |
               |                               |
               +-------------------------------+
               |                               |
               |      Common PDU トレイラ      |
               |                               |
               +-------------------------------+

 ブリッジ802.6 PDUsでは、CRC-32の存在がMACフレームのヘッダのCIBビットによって示されるので、
PID値に対しては唯一つの選択しかないことに注意 

 Common PDU(Protocol Data Unit)ヘッダ及びトレイラは出口ブリッジで802.6サブネットワークへの輸送を許可することが伝えられる。
特に、Common PDUヘッダはPDUの長さを含んでいるBAsizeフィールドを含んでいる。
もしこのフィールドが802.6ブリッジの出口に利用できないなら、そのブリッジはすべてのPDUを受け取り、長さを計算し、
BAsizeフィールドに長さを挿入するまでセグメントPDUの転送をはじめられない。もしこのフィールドが有効なら、
出口の802.6ブリッジはCommon PDU ヘッダのBAsizeフィールドから長さを取りだし、最初のセグメントのコレスポンディングフィールドに挿入し、
802.6サブネットワークに直接セグメントを転送できる。このように、ブリッジは完全なPDUを受け取る前に802.6PDUの転送を開始できる。

 カプセル化フレームのCommon PDUヘッダとトレイラは出ていく802.6サブネットワークに簡単にコピーされるべきでない。
なぜなら、カプセル化したBEtag値はそのブリッジによって転送される以前のBEtagとかち合うからである。

 入口の802.6ブリッジはそのLengthフィールドをゼロにセットすることでAAL5 CPCS-PDUをアボートできる。
もし出口ブリッジがPDUのセグメントを802.6サブネットワークに転送し始め、AAL5 COCS-PDUがアボートされたことを通知すれば、
802.6 PDUが受信ブリッジで拒否される原因となるEOMセルをすぐさま生成するであろう。そのようなEOMセルは、たとえば、
Common PDU トレイラのLengthフィールドで無効値を含むことが可能である。

             +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-80-C2         |
               +-------------------------------+
               |         PID 0x00-0E           |
               +-------------------------------+
               |                               |
               |      BPDU as defined by       |
               |     802.1(d) or 802.1(g)      |
               |                               |
               +-------------------------------+

5.  Vcベースの多重化

 VCベースの多重化では、搬送されたネットワーク相互接続プロトコルはVCが2つのATMステーションと接続することで識別される。
たとえば、各プロトコルは個別のVC上を搬送されなければならない。それゆえ、AAL5 CPCS-PDUのPeyloadが明白な多重化情報を含む必要はない。
この結果として、最狭帯域と処理のオーバーヘッドとなる。

 上記が示すように、搬送されたプロトコルは信号手順を使ったコールの確立中に手動で構成することも
ダイナミックに交渉することもできる。信号の詳細は関連標準が有効になったとき、他のRFCでいずれ定義されるであろう。

5.1.  ルーティングプロトコルのVCベースの多重化

  ルーティングプロトコルのPDUs は、AAL5 CPCS-PDUのPeyloadで運ばれる. 
 AAL5 CPCS-PDU Payload フィールドのフォーマットは、以下の通りである。

               ルーティング PDUsのPayload フォーマット 
               +-------------------------------+
               |             .                 |
               |         Carried PDU           |
               |    (最大 2^16 - 1 octets)    |
               |             .                 |
               |             .                 |
               +-------------------------------+

5.2.  ブリッジプロトコルのベースの多重化 

 ブリッジプロトコルのPUDはPIDフィールドの後にフィールドが含まれている時以外は、
4.2章で述べたようにAAL5 CPCS-PDUのPeyload で搬送される。ブリッジPDUを搬送するAAL5 CPCS-PDU Payloadフィールドは、
それゆえ次のフォーマットの一つを持っている。


            ブリッジ Ethernet/802.3 PDUs の Payload フォーマット 
               +-------------------------------+
               |         PAD 0x00-00           |
               +-------------------------------+
               |    MAC destination address    |
               +-------------------------------+
               |                               |
               |   (remainder of MAC frame)    |
               |                               |
               +-------------------------------+
               | LAN FCS (VC dependent option) |
               +-------------------------------+


             ブリッジ 802.4/802.5/FDDI PDUs の Payload フォーマット
               +-------------------------------+
               | 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.5 AC(Access Control)フィールドはローカル802.5サブネットワークの外では意味を持たない。
それは802.5の場合、いかなる値(XX)をもセットすることができる3オクテッドのPADフィールドの
最後のオクテッドと見なすことができる。

              ブリッジ 802.6 PDUs の Payload フォーマット 
               +---------------+---------------+ -------
               |   Reserved    |     BEtag     |  Common
               +---------------+---------------+  PDU
               |            BAsize             |  ヘッダ
               +-------------------------------+ -------
               |    MAC destination address    |
               +-------------------------------+
               |                               |
               |   (remainder of MAC frame)    |
               |                               |
               +-------------------------------+
               |                               |
               |     Common PDU トレイラ       |
               |                               |
               +-------------------------------+


                BPDUs の Payload フォーマット 
               +-------------------------------+
               |                               |
               |      BPDU as defined by       |
               |     802.1(d) or 802.1(g)      |
               |                               |
               +-------------------------------+

 Ethernet 802.3,802.4 802.5 FDDI PDUsの場合、後続のLAN FCSの有る無しは、PIDフィールドが含まれないため、
VCによって無条件に識別される。LAN FCS付きのPDUsとLAN FCS無しのPDUsは、ブリッジ媒体タイプがたとえ同じでも、
異なるプロトコルに属すると考えられる。

6.ATMネットワークでのブリッジ

 ブリッジとして動作するATMインタフェースは、ブリッジPDUsをフロード、フォワード、フィルタできなくてはならない。

 すべての可能な適切なデスティネーションをPDUに送ることでフロードか起きる。
ATM環境では、これはそれぞれの適切なVCを通してPDUを送ることを意味する。
これはそれを各VCに適切にコピーするか、あるいはマルチキャストVCを使うことで行われる。

 PDUをフォワードするために、ブリッジはVC付きのdestination MAC addressと結びつくことができなければならない。
ブリッジにすべての可能なVC付きのdestination MAC addressとの連結を構成することを要求するのは不当であり多分不可能である。
それゆえ、ATMブリッジはATMインタフェースにATMステーションを超えてforeign destination についてダイナミックに学ばせるために
十分な情報を提供しなければならない。

 ダイナミックな学習を実現するために、ブリッジPDUは4章で述べたカプセル化に従うであろう。
このように受信側ATMインタフェースは、ブリッジPDUを研究しforeign   destination とATMステーション間の連結を学ぶことになる。

7.今後の研究のために
 ATMマルチキャスト、アドレッシング、信号メカニズムの標準化が不完全なため、アドレスリゾルーションと同様、
多重化方法の交渉に関する詳細はこれからのRFCに委ねられなければならない。

謝辞
 本論文は多くの資料が採用されたRFCs「1」及び[4]から発展したものである。
それらの著者T.Bradley, C.Brown, A.Malis, D.Pisctello, C.Lawrenceに謝意を表したい。
加えて、IETFのATMワーキンググループの専門知識は論文を書くにあたり評価しきれない程貴重なものであった。
CERNのBraian Carpenter, IBMのRao Cherukuri, MotorolaのDan Grossman, Network SystemsのJoel Halperns,
 Sun MicrosystemsのBob Hinden, MAN Technology CorporationのGary Kessierの詳細に渡る助力に特別な謝辞を捧げる。
 
セキュリティ考察
 セキュリティ問題は本論文では述べない。

参照
 [1] Piscitello,D.及びawrence C. 「The Transmission of IP Datagrams over the SMDS Service」
       RFC 1209 Bell Communications Research  1991年3月
 [2] CITT 「Draft Recommendation l.363」 CITT Study Group XVIlI Geneva,19-29 1993年1月
  [3] CITT 「Draft Recommendation l.36x.1」 CITT Study Group XVII Geneva,19-29 1993年1月
  [4] Bradley, T>, Brown 及びMalis, A. 「Multiprotocol interconnct over Frame Relay」
      RFC 1294 Wellfleett Communications, INC. 及びBBN Communications  1992年1月
 [5] CITT 「Draft text for Q.93B」CITT Study Group XI  1992年9月23日-10月2日
  [6] Information technology - Telecommunication and Information Exchange Between Systems 
     「Protocol identification in the Network Layer」ISO/IEC TR 9577 1009年10月
 [7] Postel, J. 及びReynolds, J. 「A Standard for the Transmission of IP Datagram over 
     IEEE 802 Networks」RFC1042, ISI, 1988年2月

付録 A FRーSSCS上でのマルチプロトコルカプセル化

 l.36x.1は、FrameRelay/ATM interworkingのためのAAL タイプ5のCPCS(Common Part Convergence Sublayer)
のトップで使われるFR=SSCS(Frame Relaying Convergence Sublayer)を定義する。
FR-SSCSが提供するサービスはl.233で述べるようにFrame Relaying 用のCore Serviceと一致する。

 FR-SSCS-PDU はQ.922 インフォメーションフィールドが続くQ.922アドレスフィールドから成り立つ。
Q.922フラグとFCSは除外される。AAlによって同じ機能が提供されるからである。
下図はAAL5 CPCS-PDUnのPeyload に埋め込まれたFR-SSCS-PDUを示している。

      AAL5 CPCS-PDU の Peyload中の FR-SSCS-PDU  
               +-------------------------------+ -------
               |      Q.922 Address Field      | FR-SSCS-PDU ヘッダ
               |         (2-4 octets)          |
               +-------------------------------+ -------
               |             .                 |
               |             .                 |
               |    Q.922 Information field    | FR-SSCS-PDU Payload
               |             .                 |
               |             .                 |
               +-------------------------------+ -------
               |      AAL5 CPCS-PDU トレイラ   |
               +-------------------------------+

   ルーティング及びブリッジ PDUs は RFC 1294で定義したようにFR-SSCS-PDUの内部でカプセル化される。
 Q.922 Information field は Q.922 Control field で始まり、その後にフレームの残りを調整し
送信側に対する便宜的境界とするために使われるオプショナルPADオクテッドが続く。
キャリー PDUのプロトコルはISO/CCITT NLPID(Network Layer Protocol ID)を先頭に置くことによって識別される。

   IP PDUの特殊なケースでは, NLPID は0xCCで、またFR-SSCS-PDUは以下のフォーマットを持つ。

              ルーティングIP PDUs用の FR-SSCS-PDU フォーマット 
               +-------------------------------+
               |       Q.922 Addr Field        |
               |       (2 or 4 octets)         |
               +-------------------------------+
               |     0x03 (Q.922 Control)      |
               +-------------------------------+
               |          NLPID  0xCC          |
               +-------------------------------+
               |             .                 |
               |           IP PDU              |
               |    (up to 2^16 - 5 octets)    |
               |             .                 |
               +-------------------------------+

 RFC 1294によると、Q.922 Address fieldは 2 又は 4 オクテッドであることに注意。たとえば、
3オクテッドのAddress field はサポートされない。

 CLNP PDUの特殊ケースでは、NLPIDは0x81で、またFR-SSCS-PDU は以下のフォーマットを持っている。
              ルーティング CLNP PDUs用の FR-SSCS-PDU フォーマット 
               +-------------------------------+
               |       Q.922 Addr Field        |
               |       (2 or 4 octets)         |
               +-------------------------------+
               |     0x03 (Q.922 Control)      |
               +-------------------------------+
               |         NLPID  0x81           |
               +-------------------------------+
               |               .               |
               |       Rest of CLNP PDU        |
               |    (up to 2^16 - 5 octets)    |
               |               .               |
               +-------------------------------+
 
 ISOプロトコルの場合は、NLPIDフィールドはPDU自体のの第1オクテッドを形成し、繰り返されない。
 上記のカプセル化は割り当てられたユニークNLPIDを持つこれらのルーティングプロトコルだけに適応する。
その他のルーティングプロトコル(またブリッジプロトコル)には、簡単なプロトコル識別のための
別のメカニズムを提供する必要がある。それはIEEE 802.1a SNAP(SubNetwork Attachment Point)
ヘッダが続くことを示すためにNLPID0x80値を使うことによって実現できる。

 FRCS上でのマルチプロトコルカプセル化に関する更なる詳細は、RFC 1294を参照のこと。

付録 B  OUI 00-80-c2のローカルアサインされた値のリスト

            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

付録 C   NLPIDsの部分リスト

         0x00    Null Network Layer or Inactive Set (not used with ATM)
         0x80    SNAP
         0x81    ISO CLNP
         0x82    ISO ESIS
         0x83    ISO ISIS
         0xCC    Internet IP

著者住所

   Juha Heinanen
   Telecom Finland
   PO Box 228
   SF-33101 Tampere
   Finland

   Phone: +358 49 500 958

   Email: Juha.Heinanen@datanet.tele.fi
 


 Copyright(C) 2001 by Etuko Ooishi

メールの宛先。
 一つ上へ
目 次 へ