RFC1755 日本語訳
1755 ATM Signaling Support for IP over ATM. M. Perez, F. Liaw, A.Mankin, E. Hoffman, D. Grossman, A. Malis. February 1995. (Format: TXT=55209 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Perez
Request for Comments: 1755 ISI
Category: Standards Track F. Liaw
FORE Systems, Inc.
A. Mankin
E. Hoffman
ISI
D. Grossman
Motorola Codex
A. Malis
Ascom Timeplex, Inc.
February 1995
コメントを求めるワーキンググループM.ペレスの要求をネットワークでつないでください: 1755年のISIカテゴリ: 前面の標準化過程のモトローラ古写本A.Malis Ascom Timeplex Inc.F.LiawシステムInc.A.マンキンE.ホフマンISI D.グロースマン1995年2月
ATM Signaling Support for IP over ATM
気圧でのIPの気圧シグナリングサポート
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI) Specification Version 3.1 [ATMF94]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities.
このメモはRFC1577[LAUB94]で説明されるようにATM実装の上でClassicalがIPであるとサポートするのに必要であるATM呼び出しコントロールシグナリング交換について説明します。 ATM終点はATM Forum User-ネットワークInterface(UNI)仕様バージョン3.1[ATMF94]における指定されるとしてのATMシグナリングサービスを取り入れるでしょう。 ATM実装の上のIPは確立する地方のATMシグナリング実体とリリースATM接続のサービスを利用します。 このメモは、ATM実装に関してIPによって地元のATMシグナリング実体から必要とされたサポートを定義するのに使用されるべきです。
This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNI Specification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI.
このドキュメントはRFC1577、RFC1483、およびUNI ATMシグナリングの中で相互運用性を伸ばすことを意図する作成者のガイドです。 それは、またATM endsystemsであるIPホストとルータに適用して、ATM Forum UNI Specificationがバージョン3.1であると完全に実装するATMネットワークを仮定します。 明らかに述べない場合、兵士とPublic UNIの間で区別を全くしません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 1] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間にサポートするペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[1ページ]
UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment with Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found in Appendix B.
UNI3.1はUNI3.0仕様への誤字であると考えられます。 それは主にRecommendation Q.2931との整列の理由でATM Forumによって生産されました。 UNI3.1はUNI3.0に基づいていますが、2つのバージョンを非互換にする数回の変化があります。 ATMの上でUNI3.0を使用することでどうIPをサポートするかに関する記述はAppendix Bで見つけられます。
Table of Contents
目次
1. Conventions ............................................... 3
2. Overview .................................................. 3
3. Use of Protocol Procedures ................................ 4
3.1 VC Establishment ..................................... 4
3.2 Multiprotocol Support on VCs ........................ 4
3.3 Support for Multiple VCs ............................. 5
3.4 VC Teardown........................................... 6
4. Overview of UNI Call Setup Signaling ...................... 6
5. Overview of Call Establishment Message Content ............ 7
6. Information Elements with Endpoint Significance ........... 8
6.1 ATM Adaptation Layer Parameters ...................... 8
6.2 Broadband Low Layer Information ..................... 8
6.2.1 Framework for Protocol Layering ............... 9
7. Information Elements with Significance to the ATM Network . 11
7.1 ATM Traffic Descriptor ............................... 11
7.2 Broadband Bearer Capability .......................... 15
7.3 QoS Parameter......................................... 16
7.4 ATM Addressing Information ........................... 16
8. Dealing with Failure of Call Establishment................. 18
9. Security Considerations .................................... 18
10. Open Issues ............................................... 19
11. Acknowledgements........................................... 19
12. References ................................................ 19
13. Authors' Addresses ........................................ 20
Appendix A Sample Signaling Messages ......................... 22
Appendix B IP over ATM using UNI 3.0 Signaling ............... 25
Appendix C Combinations of Traffic Related Parameters ........ 27
Appendix D Frame Relay Interworking .......................... 28
1. コンベンション… 3 2. 概要… 3 3. プロトコル手順の使用… 4 3.1 VC設立… 4 3.2 VCsにおけるMultiprotocolサポート… 4 3.3 複数のVCsのために、サポートします。 5 3.4VC分解… 6 4. UNI呼び出しセットアップシグナリングの概要… 6 5. 呼び出し設立メッセージ内容の概要… 7 6. 終点意味がある情報要素… 8 6.1 気圧適合層のパラメタ… 8 6.2 広帯域の少ない層の情報… 8 6.2 プロトコルレイヤリングのための.1フレームワーク… 9 7. 気圧への意味がある情報要素は.117.1気圧トラフィック記述子をネットワークでつなぎます… 11 7.2 広帯域の運搬人能力… 15 7.3QoSパラメタ… 16 7.4 気圧アドレス指定情報… 16 8. 呼び出し設立について失敗に対処します… 18 9. セキュリティ問題… 18 10. 問題を開いてください… 19 11. 承認… 19 12. 参照… 19 13. 作者のアドレス… 20 付録Aサンプルシグナリングは通信します… 22 UNI3.0シグナリングを使用する気圧での付録B IP… 25 トラフィックの付録C組み合わせはパラメタについて話しました… 27 付録Dフレームリレーの織り込むこと… 28
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 2] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間にサポートするペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[2ページ]
1. Conventions
1. コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST, SHALL, or MANDATORY -- the item is an absolute requirement
of the specification.
o SHALL、MANDATORY--項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMEND -- this item SHOULD generally be followed for
all but exceptional circumstances.
o SHOULDかRECOMMEND--、この項目SHOULD、一般に、ほとんど例外的な事情には、続かれてください。
o MAY or OPTIONAL -- the item is truly optional and MAY be followed
or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2. Overview
2. 概要
In a Switched Virtual Connection (SVC) environment, ATM virtual channel connections (VCCs) are dynamically established and released as needed. This is accomplished using the ATM call/connection control signaling protocol, which operates between ATM endsystems and the ATM network. The signaling entities use the signaling protocol to establish and release calls (association between ATM endpoints) and connections (VCCs). Signaling procedures include the use of addressing to locate ATM endpoints and allocation of resource in the network for the connection. It also provides indication and negotiation between ATM endpoints for selection of end-to-end protocols and their parameters. This memo describes how the signaling protocol is used in support of IP over ATM, and, in particular, the information exchanged in the signaling protocol to effect this support.
Switched Virtual Connection(SVC)環境で、ATMの仮想のチャンネル接続(VCCs)は、必要に応じてダイナミックに確立されて、釈放されます。 これはATM呼び出し/接続規制シグナリングプロトコル(ATM endsystemsとATMネットワークの間で作動する)を使用するのに優れています。 シグナリング実体は確立するシグナリングプロトコル、リリース要求(ATM終点の間の協会)、および接続(VCCs)を使用します。 シグナリング手順は、接続のためのネットワークにおける、リソースのATM終点と配分の場所を見つけるようにアドレシングの使用を含んでいます。 また、それは終わりから終わりへのプロトコルとそれらのパラメタの品揃えにATM終点の間の指示と交渉を提供します。 このメモはシグナリングプロトコルがどうATMの上のIPを支持して使用されるか、そして、およびこのサポートに作用するようにシグナリングプロトコルで交換された特に情報について説明します。
IP address to ATM address resolution and routing issues are not in the scope of this memo, and are treated as part of IP in figure 1.
ATMアドレス解決へのIPアドレスとルーティング問題がこのメモ、および図のIPの一部として扱われた1の範囲にありません。
+--------------+ +------+ +----------+
| | | |<--->| IP / ARP |
| |<--->| This | | RFC 1577 |
| ATM | | Memo | +----------+
| signaling | | |<--->| RFC 1483 |
| | +------+ +----------+
| | -------------> | AAL 5 |
| | +----------+
| | -------------> | ATM |
+--------------+ +----------+
+--------------+ +------+ +----------+ | | | | <、-、--、>| IP/アルプ| | | <、-、--、>| これ| | RFC1577| | 気圧| | メモ| +----------+ | シグナリング| | | <、-、--、>| RFC1483| | | +------+ +----------+ | | ------------->| AAL5| | | +----------+ | | ------------->| 気圧| +--------------+ +----------+
Figure 1.
Relationship of this memo to IP, RFC 1483,
ATM signaling, ATM and AAL5
図1。 IP、RFC1483、ATMシグナリング、ATM、およびAAL5へのこのメモの関係
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 3] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間にサポートするペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[3ページ]
3. Use of Protocol Procedures
3. プロトコル手順の使用
The following requirements are motivated to provide implementation guidelines on how multiple ATM connections between peer systems SHOULD be managed, to prevent connection thrashing and related problems.
以下の要件は、接続の打つのと関連する問題を防ぐために管理されて、同輩システムSHOULDの間のATM接続がどれくらい複数かに関する実施要綱を提供するために動機づけられています。
3.1. VC Establishment
3.1. VC設立
The owner of an existing VCC is defined to be the entity within the ATM endsystem that establishes the connection. An ATM endsystem MAY establish an ATM call when it has a datagram to send and either there is no existing VCC that it can use for this purpose, it chooses not to use an existing VCC, (e.g., for reasons of route optimization or quality of service), or the VCC owner does not allow sharing.
既存のVCCの所有者は、接続を確立するATM endsystemの中の実体になるように定義されます。 または、送るデータグラムを持っているとき、ATM endsystemがATM呼び出しを確立するかもしれなくて、それがこのために使用できるどんな既存のVCCもなくて、それが、既存のVCCを使用しないのを選ぶ、(例えば、経路最適化かサービスの質の理由による)、VCC所有者は、共有するのを許しません。
To reduce the latency of the address resolution procedure at the called station, the following procedure MAY be used:
被呼局でアドレス解決手順のレイテンシを減少させるために、以下の手順は用いられるかもしれません:
If a VCC is established using the LLC/SNAP encapsulation, the calling endstation of the VCC MAY send an InARP_REQUEST to the called endstation after the connection is established (i.e. received a CONNECT message) and before the calling endstation sends the first data packet. In addition, the calling endstation MAY send its data packets without waiting for the InARP_REPLY. An endstation MAY respond, generate, and manage its ATMARP table according to the procedures specified in RFC1293 [BRAD92], Section 7, "Protocol Operation", during the life time of the VCC.
VCCがLLC/SNAPカプセル化、VCC MAYの呼んでいるendstationを使用することで設立されるなら、接続が確立された(すなわち、CONNECTメッセージを受け取ります)後と呼んでいるendstationが最初のデータ・パケットを送る前にInARP_REQUESTを呼ばれたendstationに送ってください。 さらに、InARP_REPLYを待たないで、呼んでいるendstationはデータ・パケットを送るかもしれません。 RFC1293[BRAD92](VCCの寿命時間の「操作について議定書の中で述べてください」というセクション7)で指定された手順によると、endstationはATMARPテーブルを反応して、生成して、管理するかもしれません。
To avoid establishing multiple VCCs to the same endstation, a called endstation MAY associate the calling party number in the SETUP message with the established VCC. This VCC MAY be used to transmit data packets destined to a endstation whose ATMARP resolution results in an ATM address that is the same as the associated calling party number. Sharing of VCCs is subject to the policies configured at the endstation as described in section 4.3 of this recommendation.
同じendstationに複数のVCCsを設立するのを避けるために、呼ばれたendstationはSETUPメッセージの起呼側番号を確立したVCCに関連づけるかもしれません。 このVCC MAY、使用されて、ATMARP解決が関連起呼側番号と同じATMアドレスをもたらすendstationに運命づけられたデータ・パケットを伝えてください。 VCCsの共有はこの推薦のセクション4.3で説明されるようにendstationで構成された方針を受けることがあります。
3.2. Multiprotocol Support on VCs
3.2. VCsにおけるMultiprotocolサポート
When two ATM endsystems run multiple protocols, an ATM connection MAY be shared among two or more datagram protocol entities, as long as the VCC owner allows sharing and if the encapsulation allows proper multiplexing and demultiplexing (i.e. the LLC/SNAP encapsulation). This indication of sharing a VCC MAY be by configuration or via an API. Similarly, the Internet layer supports multiplexing of multiple end-to-end transport sessions. To properly detect idle connections while sharing a VCC among more than one higher layer protocol entities, the ATM endsystem MUST monitor the traffic at the lowest
2ATM endsystemsが複数のプロトコルを実行すると、ATM接続は2つ以上のデータグラムプロトコル実体の中で共有されるかもしれません、VCC所有者が、共有するのを許す限り、カプセル化が適切なマルチプレクシングと逆多重化(すなわち、LLC/SNAPカプセル化)を許容するなら。 VCC MAYを共有するこのしるしは構成かAPIを通したそうです。 同様に、インターネット層は終わりから終わりへの輸送複数のセッションのマルチプレクシングをサポートします。 1つ以上のより高い層のプロトコル実体の中でVCCを共有している間、適切に無駄な接続を検出するために、ATM endsystemは最も低いところでトラフィックをモニターしなければなりません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 4] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間にサポートするペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[4ページ]
multiplexing layer.
層を多重送信します。
3.3. Support for Multiple VCs
3.3. 複数のVCsのサポート
An ATMARP server or client MAY establish an ATM call when it has a datagram to send and either there is no existing VCC that it can use for this purpose, it chooses not to use an existing VCC, or the owner of the VCC does not allow sharing. Note that there might be VCCs to the destination which are used for IP, but an ARP server might prefer to use a separate VCC for ARP only. The ATMARP server or client MAY maintain or release the call as specified in RFC 1577. However, if the VCC is shared among several protocol entities, the ATMARP client or server SHALL NOT disconnect the call as suggested in RFC 1577.
送るデータグラムを持っているとき、ATMARPサーバかクライアントがATM呼び出しを確立するかもしれません、そして、それがこのために使用できるどんな既存のVCCもないか、既存のVCCを使用しないのを選ぶか、またはVCCの所有者は共有するのを許しません。 目的地へのIPに使用されるVCCsがあるかもしれませんが、ARPサーバが、ARPだけに別々のVCCを使用するのを好むかもしれないことに注意してください。 ATMARPサーバかクライアントが、RFC1577での指定されるとしての呼び出しを維持するか、またはリリースするかもしれません。 しかしながら、VCCが共有されるなら、いくつかのプロトコル実体、ATMARPクライアントまたはサーバの中では、SHALL NOTはRFC1577に示されるように呼び出しから切断します。
Systems MUST be able to support multiple connections between peer systems (without regard to which peer system initiated each connection). They MAY be configured to only allow one such connection at a time.
システムは同輩システム(同輩システムが各接続を開始した関係のない)の間の複数の接続をサポートすることができなければなりません。 それらは、一度にそのような接続のひとりしか許容しないように構成されるかもしれません。
If a receiver accepts more than one call from a single source, that receiver MUST then accept incoming PDUs on the additional connection(s), and MAY transmit on the additional connections. Receivers SHOULD NOT accept the incoming call, only to close the connection or ignore PDUs from the connection.
受信機が単独のソースから1つ以上の呼び出しを受け入れるなら、その受信機は、次に、追加接続のときに入って来るPDUsを受け入れなければならなくて、追加接続のときに伝わるかもしれません。 受信機SHOULD NOTはかかってきた電話を受け入れますが、接続を終えるか、または接続からPDUsを無視します。
Because opening multiple connections is specifically allowed, algorithms to prevent connection call collision, such as the one found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be implemented.
複数の接続を開くのが明確に許されているので、接続呼び出し衝突を防ぐアルゴリズム(ものがセクション8.4.3で.5人のISO/IEC8473[ISO8473]を見つけたようなもの)を実装してはいけません。
While allowing multiple connections is specifically desired and allowed, implementations MAY choose (by configuration) to permit only a single connection to some destinations. Only in such a case, if a colliding incoming call is received while a call request is pending, the incoming call MUST be rejected. Note that this MAY result in a failure to establish a connection. In such a case, each system MUST wait at least a configurable collision retry time in the range 1 to 10 seconds before retrying. Systems MUST add a random increment, with exponential backoff.
複数の接続を許すのが明確に必要で許容されている間、実装は、いくつかの目的地に単独結合だけを可能にするのを選ぶかもしれません(構成で)。 このような場合には、発呼要求が未定ですが、衝突かかってきた電話が受け取られているなら、かかってきた電話を拒絶するだけでよいです。 これが取引関係を築かないことをもたらすかもしれないことに注意してください。 このような場合には、各システムは再試行する1〜10秒前の範囲の再試行時間に少なくとも構成可能な衝突を待たなければなりません。 システムは指数のbackoffで無作為の増分を加えなければなりません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 5] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間にサポートするペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[5ページ]
3.4. VC Teardown
3.4. VC分解
Either endsystem MAY close a connection. If the connection is closed or reset while a datagram is being transmitted, the datagram is lost. Systems SHOULD be able to configure a minimum holding time for connections to remain open as long as the endpoints are up. (Note that holding time, the time the connection has been open, differs from idle time.) A suggested default value for the minimum holding time is 60 seconds.
endsystemは接続を終えるかもしれません。 データグラムが送られている間、接続が閉店するか、またはリセットされるなら、データグラムは無くなっています。 システムSHOULD、終点が上がっている限り、接続が開いたままで残る最小の把持時間を構成できてください。 (把持時間(接続がオープンである時)が遊休時間と異なっていることに注意してください。) 最小の把持時間の提案されたデフォルト値は60秒です。
Because some public networks MAY charge for connection holding time, and connections MAY be a scarce resource in some networks or endsystems, each system implementing a Public ATM UNI interface MUST support the use of a configurable inactivity timer to clear connections that are idle for some period of time. The timer's range SHOULD include a range from a small number of minutes to "infinite". A default value of 20 minutes is RECOMMENDED. Systems which only implement a Private ATM UNI interface SHOULD support the inactivity timer. If implemented, the inactivity timer MUST monitor traffic in both directions of the connection.
いくつかの公衆通信回線が接続把持時間に充電されるかもしれなくて、接続がいくつかのネットワークかendsystemsの不十分なリソースであるかもしれないので、Public ATM UNIインタフェースを実装する各システムはいつかの期間の間無駄な接続をきれいにするために構成可能な不活発タイマの使用をサポートしなければなりません。 タイマの範囲SHOULDは数分の少ない数から「無限」までの範囲を含んでいます。 20分のデフォルト値はRECOMMENDEDです。 兵士のATM UNIインタフェースがSHOULDであると実装するだけであるシステムが不活発タイマを支えます。 実装されるなら、不活発タイマは接続の両方の方向にトラフィックをモニターしなければなりません。
4. Brief Overview of UNI Call Setup Signaling Procedures and Messages
4. 手順とメッセージを示すUNI呼び出しセットアップの簡潔な概要
This section provides a summary of point-to-point signaling procedures. Readers are referred to [ATMF93].
このセクションは二地点間シグナリング手順の概要を提供します。 読者は言及されます[ATMF93]。
UNI signaling messages used for point-to-point call/connection control are the following:
二地点間呼び出し/接続コントロールに使用されるUNIシグナリングメッセージは以下です:
Call Setup Call Release
---------- ------------
SETUP RELEASE
CALL PROCEEDING RELEASE COMPLETE
CONNECT
CONNECT ACKNOWLEDGE
呼び出しリリースにセットアップに電話をしてください。---------- ------------ 完全な状態でリリースを続かせるのが接続するというセットアップリリース要求が接続する、承認
An ATM endpoint initiates a call request by sending a SETUP message to the network. The network processes the call request to determine if the call can be progressed. If so, the network indicates the value of the newly allocated VPCI/VCI in its first response to the the SETUP message, which is either a CALL PROCEEDING or CONNECT message. If a call cannot be accepted, by the network or destination ATM end- point, a RELEASE COMPLETE is sent. At the destination ATM endpoint, the network offers the call using the SETUP message. If the destination endpoint is able to accept the call, it responds with a CONNECT message (which MAY be preceded by a CALL PROCEEDING); otherwise, it sends a RELEASE COMPLETE message. See Appendix A, Section 2 for guidance on the use of the CALL PROCEEDING message.
ATM終点は、SETUPメッセージをネットワークに送ることによって、発呼要求を開始します。 ネットワークは呼び出しを進行できるかどうか決定するという発呼要求を処理します。 そうだとすれば、ネットワークはCALL PROCEEDINGかCONNECTメッセージのどちらかであるSETUPメッセージへの最初の応答における、新たに割り当てられたVPCI/VCIの値を示します。 ATM終わりが指すネットワークか目的地で呼び出しを受け入れることができないなら、RELEASE COMPLETEを送ります。 目的地ATM終点では、ネットワークが、SETUPメッセージを使用することで呼び出しを提供します。 目的地終点が呼び出しを受け入れることができるなら、CONNECTメッセージ(CALL PROCEEDINGによって先行されるかもしれない)で、応じます。 さもなければ、それはRELEASE COMPLETEメッセージを送ります。 指導に関してCALL PROCEEDINGメッセージの使用にAppendix A、セクション2を見てください。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 6] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[6ページ]
Call release can be initiated by either endpoint or (rarely) by the network. When an endpoint wishes to release a call, it sends a RELEASE message to the network. The network responds with a RELEASE COMPLETE message, frees up resources associated with the call, and initiates clearing toward the other endpoint. The network initiates clearing by sending a RELEASE message to the ATM endpoint, which reponds by sending a RELEASE COMPLETE message. Upon receipt of the RELEASE COMPLETE message, the network frees any resources associated with the call.
ネットワークは(めったに)どちらの終点でも呼び出しリリースを開始できません。 終点であるときに、呼び出しをリリースするという願望であり、それはRELEASEメッセージをネットワークに送ります。 ネットワークは、RELEASE COMPLETEメッセージで応じて、呼び出しに関連しているリソースを開けて、もう片方の終点に向かって開拓地を開始します。 ネットワークはRELEASEメッセージをATM終点に送ることによって、開拓地を開始して、発信するのによるどの「再-池」がRELEASE COMPLETEメッセージであるか。 RELEASE COMPLETEメッセージを受け取り次第、ネットワークは呼び出しに関連しているどんなリソースも解放します。
5. Overview of Call Establishment Message Content
5. 呼び出し設立メッセージ内容の概観
Signaling messages are structured to contain mandatory and optional variable length information elements (IEs). IEs are further subdivided into octet groups, which in turn are divided into fields. IEs contain information related to the call, which is relevant to the network, the peer endpoint or both. Selection of optional IEs and the content of mandatory and optional IEs in a call establishment message determines the parties to and nature of the communication over the ATM connection. For example, the call establishment message for a call which will be used for constant bitrate video over AAL 1 will have different contents than a call which will be used for IP over AAL 5.
シグナリングメッセージは、義務的で任意の可変長情報要素(IEs)を含むように構造化されます。 IEsはさらに八重奏グループに細分されます。(グループは順番に分野に分割されます)。 IEsはネットワーク、同輩終点または両方に関連している呼び出しに関連する情報を含んでいます。 呼び出し設立メッセージの義務的で任意のIEsのIEsと内容がパーティーを決定する任意の選択とATM接続の上のコミュニケーションの本質。 例えば、一定のbitrateビデオにAAL1の上で使用される呼び出しへの呼び出し設立メッセージには、IPにAAL5の上で使用される呼び出しと異なったコンテンツがあるでしょう。
A SETUP message which establishes an ATM connection to be used for IP and multiprotocol interconnection calls MUST contain the following IEs:
IPに使用されるためにATM接続を確立するSETUPメッセージと「マルチ-プロトコル」インタコネクト呼び出しは以下のIEsを含まなければなりません:
AAL Parameters
ATM Traffic Descriptor
Broadband Bearer Capability
Broadband Low Layer Information
QoS Parameter
Called Party Number
Calling Party Number
AALパラメタ気圧交通記述子ブロードバンド運搬人能力ブロードバンド安値は情報QoSパラメタ被呼者数の起呼側番号を層にします。
and MAY, under certain circumstance contain the following IEs:
5月、そして、ある状況の下に、以下のIEsを含んでください:
Calling Party Subaddress
Called Party Subaddress
Transit Network Selection
パーティSubaddressトランジットネットワーク選択と呼ばれる起呼側Subaddress
In UNI 3.1, the AAL Parameters and the Broadband Low Layer Information IEs are optional in a SETUP message. However, in support of IP over ATM these two IEs MUST be included. Appendix A shows an example SETUP message coded in the manner indicated in this memo.
UNI3.1では、AAL ParametersとBroadband Low Layer情報IEsはSETUPメッセージで任意です。 しかしながら、ATMの上のIPを支持して、これらの2IEsを含まなければなりません。 付録Aはこのメモで示された方法でコード化された例のSETUPメッセージを示しています。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 7] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[7ページ]
6. Information Elements with Endpoint to Endpoint Significance
6. 終点意味への終点がある情報要素
This section describes the coding of, and procedures surrounding, information elements in a SETUP message with significance only to the endpoints of an ATM call supporting IP.
このセクションがコード化について説明する、手順周辺(ATM呼び出しの終点だけへの意味がIPを支持しているSETUPメッセージの情報要素)
6.1. ATM Adaptation Layer Parameters
6.1. 気圧適合層のパラメタ
The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) carries information about the ATM Adaptation Layer (AAL) to be used on the connection. RFC 1483 specifies encapsulation of IP over AAL 5. Thus, AAL 5 MUST be indicated in the "AAL type" field.
AAL Parameters IE(セクション5.4.5.5とAnnex Fの[ATMF93]を見る)は、接続のときに使用されるためにATM Adaptation Layer(AAL)の情報を運びます。 RFC1483はAAL5の上でIPのカプセル化を指定します。 したがって、「AALタイプ」分野でAAL5を示さなければなりません。
Coding and procedure related to the 'Forward and Backward Maximum CPCS-SDU Size' fields are discussed in [ATKI94]. Values may range from zero to 65,535. Although the default IP over AAL 5/ATM is 9188 bytes, endstations are encouraged to support MTU sizes up to and including 64k.
[ATKI94]で'フォワードとBackward Maximum CPCS-SDU Size'分野に関連するコード化と手順について議論します。 値はゼロ〜6万5535まで及ぶかもしれません。 AAL5/ATMの上のデフォルトIPは9188バイトですが、endstationsが64kを含めてMTUサイズを支持するよう奨励されます。
Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be used for multiprotocol interconnect over AAL5. Therefore, the SSCS 'type' field SHOULD be absent or, if present, coded to Null SSCS.
通常、Service Specific Convergence Sublayer(SSCS)は全くAAL5の上の「マルチ-プロトコル」内部連絡に使用されないでしょう。 したがって、SSCSは分野SHOULDを'タイプします'。休むか存在しているなら、Null SSCSにコード化されてください。
Format and field values of AAL Parameters IE
AAL Parameters IEの形式と分野値
----------------------------------------------------------
| aal_parameters |
----------------------------------------------------------
| aal_type 5 (AAL 5) |
| fwd_max_sdu_size_identifier 140 |
| fwd_max_sdu_size 65,535 (desired IP MTU) |
| bkw_max_sdu_size_identifier 129 |
| bkw_max_sdu_size 65,535 (desired IP MTU) |
| sscs_type identifier 132 |
| sscs_type 0 (null SSCS) |
----------------------------------------------------------
---------------------------------------------------------- | aal_パラメタ| ---------------------------------------------------------- | aal_タイプ5(AAL5)| | fwd_最大_sdu_サイズ_識別子140| | fwd_最大_sdu_サイズ65,535(必要なIP MTU)| | bkw_最大_sdu_サイズ_識別子129| | bkw_最大_sdu_サイズ65,535(必要なIP MTU)| | sscs_タイプ識別子132| | sscs_タイプ0(ヌルSSCS)| ----------------------------------------------------------
6.2. Broadband Low Layer Information
6.2. 広帯域の少ない層の情報
Selection of an encapsulation to support IP over an ATM VCC is done using the Broadband Low Layer Information (B-LLI) IE, along with the AAL Parameters IE, and the B-LLI negotiation procedure.
ATM VCCの上でIPを支持するカプセル化の選択はBroadband Low Layer情報(B-LLI)IEを使用し終わっています、AAL Parameters IE、およびB-LLI交渉手順と共に。
RFC 1577 specifies LLC/SNAP as the default encapsulation. This encapsulation MUST be implemented by all endstations. LLC encapsulation MUST be signaled in the B-LLI as shown below. Signaling indication of other encapsulations is discussed in Appendix D, Section 4. Note that only LLC is indicated in the B-LLI. It is up
RFC1577はデフォルトカプセル化としてLLC/SNAPを指定します。 すべてのendstationsがこのカプセル化を実行しなければなりません。 B-LLIで以下に示すようにLLCカプセル化に合図しなければなりません。 Appendix D、セクション4で他のカプセル化のシグナリングしるしについて議論します。 LLCだけがB-LLIで示されることに注意してください。 それは上がっています。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 8] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[8ページ]
to the LLC layer to look into the encapsulation header of the packets following call setup. A B-LLI specifying both LLC and a layer_3_id SNAP layer is not recommended. If in those packets, the SNAP header indicates IP, it is the LLC layer's job to hand the packets up to IP.
LLCに、層にして、呼び出しセットアップに続いて、パケットのカプセル化ヘッダーを調べてください。 LLCと層の_3_イドSNAP層の両方を指定するB-LLIは推薦されません。 SNAPヘッダーがそれらのパケットでIPを示すなら、パケットをIPまで手渡すのは、LLC層の仕事です。
Format of B-LLI IE indicating LLC/SNAP encapsulation
LLC/SNAPカプセル化を示すB-LLI IEの形式
----------------------------------------------------------
| bb_low_layer_information |
----------------------------------------------------------
| layer_2_id 2 |
| user_information_layer 12 (lan_llc - ISO 8802/2) |
----------------------------------------------------------
---------------------------------------------------------- | bbの_の少ない_層_情報| ---------------------------------------------------------- | 層の_2_イド2| | ユーザ_情報_層12(lan_llc--ISO8802/2)| ----------------------------------------------------------
6.2.1. Framework for Protocol Layering
6.2.1. プロトコルレイヤリングのための枠組み
The support of connectionless services from a connection oriented link layer exposes general problems of connection management, specifically the problems of connection acceptance, assignment of quality of service, and connection shutdown. For a connection to be associated with the correct protocol on the called host, it is necessary for information about one or more layers of protocol identification to be associated with a connection "management entity" or "endpoint". This association is what we call a binding in this memo. In this section we attempt to describe a framework for a usable binding or service architecture given the available IEs in the ATM call control messages.
接続指向のリンクレイヤからのコネクションレス型サービスのサポートは接続管理の一般的問題、明確に接続承認の問題、サービスの質の課題、および接続閉鎖を露出します。 接続が呼ばれたホストの上の正しいプロトコルに関連しているように、接続「経営体」か「終点」に関連しているのがおよそ1つ以上が層にするプロトコル識別の情報に必要です。 この協会はこのメモでいわゆる結合です。 このセクションでは、ATM呼び出しコントロールメッセージの利用可能なIEsを考えて、私たちは、使用可能な結合かサービス構造のために枠組みについて説明するのを試みます。
It is important to distinguish between two basic uses of protocol identification elements present in the UNI setup message. The first is the description of the protocol encapsulation that will be used on the data packet over the virtual connection, the second is the entity that will be responsible for managing the call. All protocols present in various IEs MUST be used to encapsulate the call, but the most specific, or highest, layer specified SHOULD manage the call. This defines a hierarchy of services and provides a framework for applications, including LLC and IP, to terminate calls. This hierarchy provides a clear mechanism for support of higher level protocol and application bindings, when their use and specification is defined in the appropriate standards bodies.
UNIセットアップメッセージの現在のプロトコル識別要素の2つの基本的な用途を見分けるのは重要です。 1番目が仮想接続の上でデータ・パケットの上で使用されるプロトコルカプセル化の記述である、2番目は呼び出しを管理するのに原因となるようになる実体です。 呼び出しを要約するのに様々なIEsの現在のすべてのプロトコルを使用しなければなりませんが、最も特定の、または、最も高い層の指定されたSHOULDは呼び出しを管理します。 これは、呼び出しを終えるためにLLCとIPを含むアプリケーションに、サービスの階層構造を定義して、枠組みを提供します。 この階層構造は、より高いレベルのサポートのための明確なメカニズムにプロトコルを提供して、結合をアプリケーションに提供します、それらの使用と仕様が適切な標準化団体で定義されるとき。
In general, it would be desirable to allow data packets to be stored directly into an application's address space after connection is established. This is possible only if we have both encapsulation and managing entity indications in the signaling message.
一般に、接続が確立された後にデータ・パケットが直接アプリケーションのアドレス空間に格納されるのを許容するのは望ましいでしょう。 私たちにシグナリングメッセージにおける両方のカプセル化と管理実体指摘がある場合にだけ、これは可能です。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 9] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[9ページ]
The B-LLI is the only information element currently available in UNI 3.1 for designating protocol endpoints. It contains codepoints that describe layer 2 and layer 3 protocol entities associated with the call. There are other information elements under consideration in the ATM Forum and ITU, which could come to play a significant role in the description of application to connection binding, but their use is not yet defined, and they are not part of the framework described by RFC 1577. They include B-HLI, for containing information for a higher layer protocol, Network Layer Information (NLI) to contain information for the network layer, and UUI, which is meant to carry information for use by the top level application.
B-LLIは現在UNI3.1でプロトコル終点を指定するのに有効な唯一の情報要素です。 それは呼び出しに関連している層2と層3のプロトコル実体について説明するcodepointsを含んでいます。 彼らの使用はまだ定義されていません、そして、ATM ForumとITUには他の情報要素は考慮中でありますが、それらはRFC1577によって説明された枠組みの一部ではありません。(ITUは、アプリケーションの記述における重要な役割を接続結合にプレーするようになることができました)。 彼らはB-HLIを含んでいます、より高い層のプロトコルのための情報を含むように、ネットワーク層のために情報を含んで、トップ平らなアプリケーションによる使用のために、UUIを含むNetwork Layer情報(NLI)。(UUIは情報を運ぶことになっています)。
The following figure shows a B-LLI that MAY be used for specifying in call setup that IP will manage the call and that this VC will be used only for IP traffic. Called parties MUST accept this B-LLI. The caller using VC MUST use LLC-SNAP encapsulation on all IP datagrams, despite the fact that the caller views the VC as dedicated to IP. The reason for this requirement is that while we require receivers to accept this form of call setup, they may choose whether or not to multiplex the call through LLC, in other words to ignore the Layer 3 information. This choice is dependent on the receiver's implementation's protocol architecture and is local to the receiver.
以下の図は、IPが呼び出しを管理して、このVCがIP交通にだけ使用されるのを呼び出しセットアップで指定するのに使用されるかもしれないB-LLIに示します。 被呼者はこのB-LLIを受け入れなければなりません。 訪問者使用VC MUSTはすべてのIPデータグラムの上にLLC-SNAPカプセル化を使用します、訪問者がIPに捧げられるようにVCを見るという事実にもかかわらず。 この要件の理由は私たちがこの形式の呼び出しセットアップを受け入れるために受信機を必要としている間LLCを通して呼び出しを多重送信して、言い換えれば、Layer3情報を無視するかどうかを選ぶかもしれないということです。 この選択は、受信機の実現のプロトコル構造に依存していて、受信機にローカルです。
Format of B-LLI IE indicating VC ownership by IP
(NOTE: LLC/SNAP encapsulation is still used)
IPでVC所有権を示すB-LLI IEの形式(注意: LLC/SNAPカプセル化はまだ使用されています)
----------------------------------------------------------
| bb_low_layer_information |
----------------------------------------------------------
| layer_2_id 2 |
| user_information_layer 12 (lan_llc - ISO 8802/2) |
| layer_3_id 3 |
| ISO/IEC TR 9577 IPI 204 (0xCC) |
----------------------------------------------------------
---------------------------------------------------------- | bbの_の少ない_層_情報| ---------------------------------------------------------- | 層の_2_イド2| | ユーザ_情報_層12(lan_llc--ISO8802/2)| | 層の_3_イド3| | ISO/IEC TR9577IPI204(0xCC)| ----------------------------------------------------------
Null-encapsulated VCs are described in RFC 1483. Such a VC would result in the most direct form of binding a VC to IP. However, the method of signaling for this type of VC has not yet been integrated into the IP over ATM context. For completeness, we mention that the signaling would use a B-LLI containing the layer 3 identifier with the ISO/IEC TR-9577 protocol codepoint and omitting the layer 2 identifier [ATMF93]. Since no layer 2 is specified, frames produced by AAL processing would be given directly to IP. Processing of this B-LLI is not required at this time.
ヌルで要約されたVCsはRFC1483で説明されます。 そのようなVCはIPにVCを縛る最もダイレクトなフォームをもたらすでしょう。 しかしながら、VCのこのタイプのために合図する方法はまだATM文脈の上のIPと統合されていません。 完全性のために、私たちは、シグナリングがISO/IEC TR-9577プロトコルcodepointがある層の3識別子を含んでいて、層の2識別子[ATMF93]を省略するB-LLIを使用すると言及します。 どんな層以来も、2が指定されていない、AAL処理で生産されたフレームを直接IPに与えるでしょう。 このB-LLIの処理はこのとき、必要ではありません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 10] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[10ページ]
7. Information Elements with Significance to the ATM Network
7. 気圧ネットワークへの意味がある情報要素
This section describes the coding of, and procedures surrounding, information elements with significance to the ATM network, as well as the endpoints of an ATM call supporting multiprotocol operation.
このセクションはコード化について説明して、手順周辺、ATMネットワークへの意味がある情報要素、およびATMの終点は、multiprotocolに操作を支持すると呼びます。
The standards, implementation agreements, research and experience surrounding such issues as traffic management, quality of service and bearer service description are still evolving. Much of this material is cast to give the greatest possible latitude to ATM network implementation and service offerings. ATM endsystems need to match the traffic contract and bearer service they request from the network to the capabilities offered by the network. Therefore, this memo can only offer what, at the present time, are the most appropriate and efficient coding rules to follow for setting up IP and ATMARP VCCs. Future revisions of this memo may take advantage of ATM services and capabilities that are not yet available.
規格(実現協定)は、研究して、輸送管理、サービスの質、および運搬人サービス記述がまだ発展しているような問題を囲むのを経験します。 この材料の多くが、ATMネットワーク実現とサービス提供に可能な限り大きい緯度を与えるために投じられます。 ATM endsystemsは、彼らがネットワークからネットワークによって提供された能力まで要求する交通契約と運搬人サービスに合う必要があります。 したがって、このメモは何がIPを設立するための続く現在の最も適切で効率的なコード化規則であるか、そして、ATMARP VCCsを提供できるだけです。 このメモの今後の改正はまだ利用可能でないATMサービスと能力を利用するかもしれません。
7.1. ATM Traffic Descriptor
7.1. 気圧交通記述子
The ATM traffic descriptor characterizes the ATM virtual connection in terms of peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size. This information is used to allocate resources (e.g., bandwidth, buffering) in the network. In general, the ATM traffic descriptor for supporting multiprotocol interconnection over ATM will be driven by factors such as the capacity of the network, conformance definition supported by the network, performance of the ATM endsystem and (for public networks) cost of services.
ATM交通記述子はピークセルレート(PCR)、持続可能なセルレート(SCR)、および最大の放出量に関してATM仮想接続について描写します。 この情報は、ネットワークでリソース(例えば、帯域幅、バッファリング)を割り当てるのに使用されます。 一般に、ATMの上で「マルチ-プロトコル」インタコネクトを支持するための交通記述子が追い立てられるATMはネットワーク、ネットワークによって支持された順応定義、ATM endsystemの性能の容量とサービスの(公衆通信回線のための)費用としてそのようなものを因数分解します。
The most convenient model of IP behavior corresponds to the Best Effort Capability (see section 3.6.2.4 of [ATMF93]). If this capability is offered by the ATM network(s), it MAY be requested by including the Best Effort Indicator, the peak cell rate forward (CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM Traffic Descriptor IE. When the Best Effort Capability is used, no guarantees are provided by the network, and in fact, throughput may be zero at any time. This type of behavior is also described by RFC 1633 [BRAD94].
セクション3.6を見てください。IPの振舞いの最も便利なモデルがBest Effort Capabilityに文通している、(.2 .4[ATMF93。) この能力がATMネットワークによって提供されるなら、Best Effort Indicatorを含んでいることによって、ピークセルレートフォワード(CLP=0+1)とピークセルが、(CLP=0+1)がATM Traffic Descriptor IEの分野であると後方に評定するよう要求されるかもしれません。 Best Effort Capabilityが使用されているとき、保証は全くネットワークによって提供されません、そして、事実上、いつでも、スループットはゼロであるかもしれません。 また、このタイプの振舞いはRFC1633[BRAD94]によって説明されます。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 11] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[11ページ]
Format and field values of ATM Traffic Descriptor IE
ATM Traffic Descriptor IEの形式と分野値
----------------------------------------------------------
| traffic_descriptor |
----------------------------------------------------------
| fwd_peak_cell_rate_0+1_identifier 132 |
| fwd_peak_cell_rate_0+1 (link rate) |
| bkw_peak_cell_rate_0+1_identifier 133 |
| bkw_peak_cell_rate_0+1 (link rate) |
| best_effort_indication 190 |
----------------------------------------------------------
---------------------------------------------------------- | 交通_記述子| ---------------------------------------------------------- | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_ピーク_セル_レート_0+1(リンクレート)| | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_ピーク_セル_レート_0+1(リンクレート)| | 最も良い_努力_指示190| ----------------------------------------------------------
When the network does not support Best Effort Capability or more predictable ATM service is desired for IP, more specific traffic parameters MAY be specified and the Best Effort capability not used. Doing so includes use of two other traffic-related IEs and is discussed in the following paragraphs and sections.
ネットワークがBest Effort Capabilityを支持しないか、または、より予測できるATMサービスがIPのために望まれているとき、より特定の交通パラメタは指定されているかもしれなくて、Best Effort能力は使用されていません。 そうするのと他の2交通関連のIEsの使用を含んで、以下のパラグラフとセクションで議論します。
The Traffic Descriptor IE is accompanied by the Broadband Bearer Capability IE and the QoS Parameter IE. Together these define the signaling view of ATM traffic management. In this memo, we present an agreed-on, required subset of traffic management capabilities, as specified by using the three IEs. The figure immediately below shows the set of the allowable combinations of traffic parameters which all IP over ATM endsystems MUST support in their ATM signaling. The subset includes Best Effort in the form of a non-guaranteed bitrate combination (the rightmost column of the table below); a type of traffic description that is intended for ATM "pipes", for example between two routers (the middle column); and a type of traffic description that will allow initial use of token-bucket style characterizations of the source, as presented in RFC 1363 [PART92] and RFC 1633, for example (the leftmost column).
Traffic Descriptor IEはBroadband Bearer Capability IEとQoS Parameter IEによって同伴されます。 これらはATM輸送管理のシグナリング視点を一緒に、定義します。 このメモでは、私たちは3IEsを使用することによって指定されるように輸送管理能力の同意していて、必要な部分集合を提示します。 すぐに以下の図は、ATM endsystemsの上のすべてのIPが彼らのATMシグナリングでどれを支持しなければならないかを交通パラメタの許容できる組み合わせのセットに示します。 部分集合は非保証されたbitrate組み合わせ(以下のテーブルの一番右のコラム)の形にBest Effortを含んでいます。 ATMのために意図する一種のトラフィック記述が例えば、2つのルータ(中くらいのコラム)の間へ「運ばれます」。 そして、象徴バケツの初期の使用を許すトラフィック記述のタイプはソースの特殊化を流行に合わせます、RFC1363[PART92]とRFC1633に提示されるように、例えば、(一番左コラム。)
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 12] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[12ページ]
Combinations of Traffic Related Paramenters
that MUST be supported in the SETUP message
SETUPメッセージで支持しなければならないTrafficの関連Paramentersの組み合わせ
|---------------------------------|
|Broadband Bearer |
|Capability |
|---------------------------------|
|Broadband Bearer | C | X | X |
|---------------------|---|---|---|
|Traffic Type | | | |
|(CBR,VBR) | |CBR| & |
|---------------------|---|---|---|
|Timing Required | |YES| &&|
|---------------------------------|
|Traffic Descriptor |
|Parameter |
|---------------------------------|
|PCR (CLP=0) | | | |
|---------------------|---|---|---|
|PCR (CLP=0+1) | S | S | S |
|---------------------|---|---|---|
|SCR (CLP=0) | | | |
|---------------------|---|---|---|
|SCR (CLP=0+1) | S | | |
|---------------------|---|---|---|
|MBS (CLP=0) | | | |
|---------------------|---|---|---|
|MBS (CLP=0+1) | S | | |
|---------------------|---|---|---|
|Best Effort | | | S |
|---------------------|---|---|---|
|Tagging | NO| NO| NO|
|---------------------------------|
|---------------------------------|
|QOS Classes | 0 | 0 | 0 |
-----------------------------------
|---------------------------------| |広帯域の運搬人| |能力| |---------------------------------| |広帯域の運搬人| C| X| X| |---------------------|---|---|---| |交通タイプ| | | | |(CBR、VBR) | |CBR| & | |---------------------|---|---|---| |タイミングが必要です。| |はい| &&| |---------------------------------| |交通記述子| |パラメタ| |---------------------------------| |PCR(CLP=0)| | | | |---------------------|---|---|---| |PCR(CLP=0+1)| S| S| S| |---------------------|---|---|---| |SCR(CLP=0)| | | | |---------------------|---|---|---| |SCR(CLP=0+1)| S| | | |---------------------|---|---|---| |mb(CLP=0)| | | | |---------------------|---|---|---| |mb(CLP=0+1)| S| | | |---------------------|---|---|---| |ベストエフォート型| | | S| |---------------------|---|---|---| |タグ付け| いいえ| いいえ| いいえ| |---------------------------------| |---------------------------------| |QOSのクラス| 0 | 0 | 0 | -----------------------------------
S = Specified
& = Parameter is coded to either "no indication" or VBR or octet 5a
(Traffic Type/Timing Required) is absent; these three codings are
treated as equivalent
&& = Parameter is coded to either "no indication" or "No" or octet 5a
is absent; these three codings are treated as equivalent
= S=は指定しました、そして、パラメタが「指示がありません」かVBRのどちらかにコード化されるか、または八重奏5a(交通Type/タイミングRequired)は欠けています。 これらの3つのコーディングが同等物として扱われる、= パラメタが「指示がありません」か「いいえ」のどちらかにコード化されるか、または八重奏5aは欠けています。 これらの3つのコーディングが同等物として扱われます。
Use of other allowable combinations of traffic parameters listed in the large table in Appendix C may work, since they are allowed by [ATMF94], but this will depend on the the calling endsystem, the network, and the called endsystem.
それらが[ATMF94]によって許容されていますが、これが呼んでいるendsystem、ネットワーク、および呼ばれたendsystemによるので、Appendix Cに大きいテーブルにリストアップされた交通パラメタの他の許容できる組み合わせの使用は働くかもしれません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 13] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[13ページ]
If Best Effort service is not use, link rate SHOULD not be requested as the peak cell rate. Without any knowledge of the application, it is RECOMMENDED that a fraction, such as 1/10th, of the the link bandwidth be requested.
リンクレートSHOULD、Best Effortであるなら、サービスは使用ではありません。ピークセルレートとして、要求されていません。 アプリケーションに関する少しも知識がなければ、リンク帯域幅の1/10番目などの部分が要求されているのは、RECOMMENDEDです。
[ATMF93] does not provide any capability for negotiation of the ATM traffic descriptor paramenters. This means that:
[ATMF93]はATM交通記述子paramentersの交渉に少しの能力も提供しません。 これは、以下のことを意味します。
a) the calling endsystem SHOULD have some prior knowledge as to
the traffic contract that will be acceptable to both the
called endsystem and the network.
a) 呼んでいるendsystem SHOULDには、呼ばれたendsystemとネットワークの両方に許容できるようになる交通契約に関して何らかの先の知識があります。
b) if, in response to a SETUP message, a calling endsystem
receive a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#37, User Cell Rate Unavailable, it MAY examine the
diagnostic field of the Cause IE and reattempt the call after
selecting smaller values for the parameter(s) indicated. If
the RELEASE COMPLETE or RELEASE message is received with cause
#73, Unsupported combination of traffic parameter, it MAY
try other combinations from table 5-7 and 5-8 of [ATMF93].
b) SETUPメッセージに対応して呼ぶendsystemがRELEASE COMPLETEメッセージを受け取るか、そして、原因#37があるRELEASE COMPLETEメッセージがあとに続いたCALL PROCEEDINGメッセージ、User Cell Rate Unavailable、それはパラメタのために、より小さい値を選択した後の呼び出しが示したCause IEと「再-試み」の診断分野を調べるかもしれません。 RELEASE COMPLETEかRELEASEメッセージが交通パラメタのUnsupported組み合わせ、原因#73で受け取られていて、[ATMF93]のテーブル5-7と5-8から他の組み合わせを試みるかもしれないということであるなら。
c) the called endsystem SHOULD examine the ATM traffic descriptor
IE in the SETUP message. If it is unable to process cells at
the Forward PCR indicated, it SHOULD clear the call with cause
#37, User Cell Rate Unavailable.
c) 呼ばれたendsystem SHOULDはSETUPメッセージでATM交通記述子IEを調べます。 示されたForward PCRにセルを処理できません、それ。SHOULDは原因#37で呼び出しをクリアします、User Cell Rate Unavailable。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 14] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[14ページ]
7.2. Broadband Bearer Capability
7.2. 広帯域の運搬人能力
Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type C (BCOB-C) are both applicable for multiprotocol interconnection, depending on the service(s) provided by the ATM network and the capabilities (e.g., for traffic shaping) of the ATM endsystem. The table in the previous section showed the use of BCOB-X and BCOB-C with other parameters. The figure below shows format and field values for a BCOB-X when the Traffic Descriptor IE indicates Best Effort.
「マルチ-プロトコル」インタコネクトには、ブロードバンドBearer Connection Oriented Service Type X(BCOB-X)かType C(BCOB-C)はともに適切です、ATMネットワークによって提供されたサービスとATM endsystemの能力(例えば、交通形成のための)によって。 前項のテーブルは他のパラメタでBCOB-XとBCOB-Cの使用を示しました。 以下のショーがフォーマットして、Traffic Descriptor IEであるときに分野がBCOB-Xのために評価する図はBest Effortを示します。
Format and field values of Broadband Bearer Capability IE
Broadband Bearer Capability IEの形式と分野値
----------------------------------------------------------
| bb_bearer_capability |
----------------------------------------------------------
| spare 0 |
| bearer_class 16 (BCOC-X) |
| spare 0 |
| traffic_type 0 (no indication) |
| timing_reqs 0 (no indication) |
| susceptibility_to_clipping 0 (not suscept) |
| spare 0 |
| user_plane_configuration 0 (point_to_point) |
----------------------------------------------------------
---------------------------------------------------------- | bb_運搬人_能力| ---------------------------------------------------------- | 0を割いてください。| | 運搬人_クラス16(BCOC-X)| | 0を割いてください。| | 交通_タイプ0(指示がありません)| | タイミング_reqs0(指示がありません)| | _切り取0り(susceptでない)への敏感さ_| | 0を割いてください。| | ユーザ_飛行機_構成0(_ポイントに_を向けます)| ----------------------------------------------------------
IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the combinations shown in the previous section. It MAY also permit one of the allowable combinations shown in Appendix C.
ATMシグナリングの上のIPは前項で示された組み合わせでBCOB-CとBCOB-Xを可能にしなければなりません。 また、それはAppendix Cに示された許容できる組み合わせの1つを可能にするかもしれません。
Currently, there is no capability for negotiation of the broadband bearer capability. This means that:
現在、広帯域の運搬人能力の交渉のための能力が全くありません。 これは、以下のことを意味します。
a) the calling endsystem SHOULD have some prior knowledge as to
the broadband bearer capability that will be acceptable to
both the called endsystem and the network.
a) 呼んでいるendsystem SHOULDには、呼ばれたendsystemとネットワークの両方に許容できるようになる広帯域の運搬人能力に関して何らかの先の知識があります。
b) if, in response to a SETUP message, a calling endsystem
receives a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#57, bearer capability not authorized or #58 bearer capability
not presently available, it MAY reattempt the call after
selecting another bearer capability.
b) SETUPメッセージに対応して職業endsystemがRELEASE COMPLETEメッセージを受け取るか、CALL PROCEEDINGメッセージが運搬人能力が原因#57で認可しなかったRELEASE COMPLETEメッセージで従ったか、そして、現在利用可能でない#58運搬人能力、別の運搬人能力を選択した後に、それは呼び出しを「再-試み」るかもしれません。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 15] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[15ページ]
7.3. QoS Parameter
7.3. QoSパラメタ
The Unspecified QoS class (Class 0) is the only QoS class that must be supported by all networks and the only QoS class allowed when using the Best Effort service. The Specified QoS Class for Connection Oriented Data Transfer (Class 3) or the Specified QoS Class for Connectionless Data Transfer (Class 4) may be applicable to multiprotocol over ATM, but their use has to be negotiated with the network provider. The combinations of QoS parameters with the ATM Traffic Descriptor and the Broadband Bearer Capability are detailed in the Traffic Descriptor section and in Appendix C.
Unspecified QoSのクラス(クラス0)は、すべてのネットワークが支持しなければならない唯一のQoSのクラスとBest Effortサービスを利用するとき許容された唯一のQoSのクラスです。 Connection Oriented Data TransferのためのSpecified QoS Class(クラス3)かConnectionless Data TransferのためのSpecified QoS Class(クラス4)がATMの上で「マルチ-プロトコル」に適切であるかもしれませんが、彼らの使用はネットワーク内の提供者と交渉されなければなりません。 ATM Traffic DescriptorとBroadband Bearer CapabilityへのQoSパラメタの組み合わせはTraffic Descriptor部とAppendix Cで詳細です。
Format and field values of QoS Parameters IE
QoS Parameters IEの形式と分野値
----------------------------------------------------------
| qos_parameter |
----------------------------------------------------------
| qos_class_fwd 0 (class 0) |
| qos_class_bkw 0 (class 0) |
----------------------------------------------------------
---------------------------------------------------------- | qos_パラメタ| ---------------------------------------------------------- | qos_クラス_fwd0(クラス0)| | qos_クラス_bkw0(クラス0)| ----------------------------------------------------------
[ATMF93] does not provide any capability for negotiation of Quality of Service parameters. This means that:
[ATMF93]はServiceパラメタのQualityの交渉に少しの能力も提供しません。 これは、以下のことを意味します。
a) the calling endsystem SHOULD have some prior knowledge as to
the QoS classes offered by the ATM network in conjunction with
the requested Broadband Bearer Service and Traffic Descriptor.
a) 呼んでいるendsystem SHOULDはATMネットワークに要求されたBroadband Bearer ServiceとTraffic Descriptorに関連してQoSのクラスに関する何らかの先の知識を提供させます。
b) if, in response to a SETUP message, a calling endsystem
receives a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#49, Quality of Service Unavailable, it MAY reattempt the call
after selecting another QoS class.
b) SETUPメッセージに対応して職業endsystemがRELEASE COMPLETEメッセージを受け取るか、そして、原因#49があるRELEASE COMPLETEメッセージがあとに続いたCALL PROCEEDINGメッセージ、Service UnavailableのQuality、もう1人のQoSのクラスを選択した後に、それは呼び出しを「再-試み」るかもしれません。
Note: The two-bit 'coding standard' field of the General Information
octet in the IE header, SHOULD be set to '00' now that the ITU-T has
standardized QoS class 0. Endsystems SHOULD treat either value ('11'
or '00') as requesting the ITU-T QoS class.
以下に注意してください。 安っぽさ、''現在のITU-tが標準化した'00までのセットがQoSのクラス0であったならIEヘッダー、SHOULDで総合案内八重奏について標準の'分野をコード化します。 'Endsystems SHOULDはITU-T QoSのクラスを要求するとして値(11年''00')を扱います。
7.4. ATM Addressing Information
7.4. 気圧アドレス指定情報
ATM addressing information is carried in the Called Party Number, Calling Party Number, and, under certain circumstance, Called Party Subaddress, and Calling Party Subaddress IE. Section 5.8 of [ATMF93] provides the procedure for an ATM endsystem to learn its own ATM address from the ATM network, for use in populating the Calling Party Number IE. Section 5.4.5.14 [ATMF94] describes the syntax and semantics of the calling party subaddress IE.
ATMアドレス指定情報はある状況の下でCalledパーティNumber、CallingパーティNumber、CalledパーティSubaddress、およびCallingパーティSubaddress IEで運ばれます。 ATM endsystemがATMネットワークからそれ自身のATMアドレスを学ぶように、[ATMF93]のセクション5.8は手順を提供します、CallingパーティNumber IEに居住することにおける使用のために。 セクション5.4 .5 .14 [ATMF94]は起呼側subaddress IEの構文と意味論について説明します。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 16] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[16ページ]
RFC 1577 RECOMMENDS that a router be able to provide multiple LIS support with a single physical ATM interface that may have one or more individual ATM endsystem addresses. Use of the Selector field in the NSAPAs and E.164 addresses (in the NSAP format) is identified as a way to differentiate up to 256 different LISs for the same ESI. Therefore, an IP router MAY associate the IP addresses of the various LISs it supports with distinct ATM addresses differentiated only by the SEL field. If an IP router does this association, then its signaling entity MUST carry in the SETUP message the ATM addresses corresponding to the particular IP entity requesting the call, and the IP entity it is requesting a call to. These ATM addresses are carried in the Calling and Called Party Number IEs respectively. Native E.164 addresses do not support a SEL field. For IP routers residing in a Public UNI where native E.164 addresses are used it is RECOMMENDED that multiple E.164 addresses be used to support multiple LISs. Note: multiple LIS support is the only recommended use of the SEL field. Use of this field is not recommended for selection of higher level applications.
RFC1577RECOMMENDS、ルータは1つ以上の個々のATM endsystemアドレスを持っているかもしれない単一の物理的なATMインタフェースを複数のLISサポートに提供できます。 NSAPAsとE.164アドレス(NSAP形式の)におけるSelector分野の使用は同じESIのために最大256異なったLISsを微分する方法として特定されます。 したがって、IPルータは異なったATMアドレスがSEL分野だけによって微分されている状態でそれが支持する様々なLISsのIPアドレスを関連づけるかもしれません。 IPルータがこの協会をするなら、それが呼び出しを要求している呼び出し、およびIP実体を要求して、シグナリング実体はSETUPメッセージで特定のIP実体に対応するATMアドレスを運ばなければなりません。 これらのATMアドレスはCallingとCalledパーティNumber IEsでそれぞれ運ばれます。 固有のE.164アドレスはSEL分野を支持しません。 固有のE.164アドレスが使用されているPublic UNIにあるIPルータのために、複数のE.164アドレスが複数のLISsを支持するのに使用されるのは、RECOMMENDEDです。 以下に注意してください。 複数のLISサポートはSEL分野の唯一のお勧めの使用です。 この分野の使用は、より高い平らなアプリケーションの品揃えのために推薦されません。
Resolution of IP addresses to ATM addresses is required of hosts and routers which are ATM endsystems that use ATM SVCs. RFC 1577 provides a mechanism for doing IP to ATM address resolution in the classical IP model.
ATM SVCsを使用するATM endsystemsであるホストとルータはATMアドレスへのIPアドレスの解決に要求されます。 RFC1577は古典的なIPモデルにおけるATMアドレス解決にIPをするのにメカニズムを提供します。
Format and field values of Called and Calling Party Number IE
CalledとCallingパーティNumber IEの形式と分野値
----------------------------------------------------------
| called_party_number |
----------------------------------------------------------
| type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) |
| addr_number (E.164 / ATM Endsystem Address) |
----------------------------------------------------------
---------------------------------------------------------- | _パーティー_数と呼ばれます。| ---------------------------------------------------------- | _数(国際的な数/未知の)の_をタイプしてください。| | addr_プラン_ident(ISDN/ATM Endsystem Address)| | addr_数(E.164 / ATM Endsystem Address)| ----------------------------------------------------------
----------------------------------------------------------
| calling_party_number |
----------------------------------------------------------
| type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) |
| presentation_indic (presentation allowed) |
| spare 0 |
| screening_indic (user provided verified & passed) |
| addr_number (E.164 / ATM Endsystem Address |
----------------------------------------------------------
---------------------------------------------------------- | _をパーティー_数と呼びます。| ---------------------------------------------------------- | _数(国際的な数/未知の)の_をタイプしてください。| | addr_プラン_ident(ISDN/ATM Endsystem Address)| | プレゼンテーション_indic(許容されたプレゼンテーション)| | 0を割いてください。| | 選別_indic(ユーザは、確かめられた状態で提供して、通りました)| | addr_number (E.164 / ATM Endsystem Address | ----------------------------------------------------------
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 17] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[17ページ]
8. Dealing with Failure of Call Establishment
8. 呼び出し設立について失敗に対処すること。
If an ATM call attempt fails with any of the following causes, the situation SHOULD be treated as Network Unreachable (if the called ATM endsystem is a router) or Host Unreachable (if the called ATM endsystem is a host). See the treatment of Network and Host Unreachable conditions in RFC 1122 [BRAD89].
以下の原因のどれか、状況SHOULDに応じてATM呼び出し試みがNetwork Unreachable(呼ばれたATM endsystemがルータであるなら)かHost Unreachableとして扱われた状態で失敗するなら(呼ばれたATM endsystemがホストであるなら)。 RFC1122[BRAD89]のNetworkとHost Unreachable状態の処理を見てください。
# 1 unallocated (unassigned) number
# 3 no route to destination
# 17 user busy
# 18 no user reponding
# 27 destination out of order
# 38 network out of order
# 41 temporary failure
# 47 resource unavailable, unspecified
# 1 「非-割り当て」られた(割り当てられない)数#3ノーは故障していた状態で不適切な#38がネットワークでつなぐ#27の目的地を再池にするユーザを全く目的地#17ユーザ忙しい#18、に#41一時障害#47リソース入手できなくて、不特定の状態で発送しません。
If an ATM call attempt fails with any of the following causes, the ATM endsystem MAY retry the call, changing (or adding) the IE(s) indicated by the cause code and diagnostic.
ATM呼び出し試みが以下の原因のどれかで失敗するなら、ATM endsystemは呼び出しを再試行するかもしれません、原因コードと病気の特徴によって示されたIE(s)を変えて(または、加えます)。
# 2 no route to specified transit network
# 21 call rejected
# 22 number changed
# 23 user rejects call with CLIR
# 37 user cell rate unavailable
# 49 quality of service unavailable
# 57 bearer capability not authorized
# 58 bearer capability not presently available
# 65 bearer capability not implemented
# 73 unsupported combination of traffic parameter
# 88 incompatible destination
# 91 invalid transmit network selection
# 78 AAL parameter cannot be supported
# 2 no route to specified transit network # 21 call rejected # 22 number changed # 23 user rejects call with CLIR # 37 user cell rate unavailable # 49 quality of service unavailable # 57 bearer capability not authorized # 58 bearer capability not presently available # 65 bearer capability not implemented # 73 unsupported combination of traffic parameter # 88 incompatible destination # 91 invalid transmit network selection # 78 AAL parameter cannot be supported
9. Security Considerations
9. Security Considerations
Not all of the security issues relating to IP over ATM are clearly understood at this time, due to the fluid state of ATM specifications, newness of the technology, and other factors. Future revisions of this specification will address the security capabilities that future signaling standards may offer to IP over ATM signaling.
Not all of the security issues relating to IP over ATM are clearly understood at this time, due to the fluid state of ATM specifications, newness of the technology, and other factors. Future revisions of this specification will address the security capabilities that future signaling standards may offer to IP over ATM signaling.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 18] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 18] RFC 1755 ATM Signaling Support for IP over ATM February 1995
10. Open Issues
10. Open Issues
o This document version is specifically an RFC 1577/RFC 1483
implementation document. Although RFC 1577 and RFC 1483
specify an LLC/SNAP encapsulation, which is inherently a
multiprotocol encapsulation, it is beyond to scope of this
document to go into any multiprotocol specifications other than
to point out some examples (see Appendix D for an example of
NLPID encapsulation).
o This document version is specifically an RFC 1577/RFC 1483 implementation document. Although RFC 1577 and RFC 1483 specify an LLC/SNAP encapsulation, which is inherently a multiprotocol encapsulation, it is beyond to scope of this document to go into any multiprotocol specifications other than to point out some examples (see Appendix D for an example of NLPID encapsulation).
11. Acknowledgments
11. Acknowledgments
The authors wish to thank the work of their colleagues who attend the IP over ATM working group; the ATM Forum Technical Committee; the ATM Signaling Subworking Group in ANSI-Accredited Technical Subcommittee T1S1; the ATM Access Signaling experts in ITU-T (formerly CCITT) Study Group 11. Rao Cherukuri (IBM) and Jeff Kiel (formerly with Bellcore, presently with BellSouth) were particularly valuable in coordinating among T1S1, ITU-T and the ATM Forum to make sure that the needs of multiprotocol over ATM could be expressed in the ATM signaling protocol.
The authors wish to thank the work of their colleagues who attend the IP over ATM working group; the ATM Forum Technical Committee; the ATM Signaling Subworking Group in ANSI-Accredited Technical Subcommittee T1S1; the ATM Access Signaling experts in ITU-T (formerly CCITT) Study Group 11. Rao Cherukuri (IBM) and Jeff Kiel (formerly with Bellcore, presently with BellSouth) were particularly valuable in coordinating among T1S1, ITU-T and the ATM Forum to make sure that the needs of multiprotocol over ATM could be expressed in the ATM signaling protocol.
REFERENCES
REFERENCES
[ATKI94] Atkinson, R., "Default IP MTU over ATM AAL5", RFC 1626,
Naval Research Laboratory, May 1994.
[ATKI94] Atkinson, R., "Default IP MTU over ATM AAL5", RFC 1626, Naval Research Laboratory, May 1994.
[ATMF94] ATM Forum, "ATM User-Network Interface Specification Version
3.1", 1994.
[ATMF94] ATM Forum, "ATM User-Network Interface Specification Version 3.1", 1994.
[ATMF93] ATM Forum, "ATM User-Network Interface Specification Version
3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993).
[ATMF93] ATM Forum, "ATM User-Network Interface Specification Version 3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993).
[BRAD89] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Science
Institute, October 1989.
[BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Science Institute, October 1989.
[BRAD94] Braden, R., Clark, D., and S. Shenker, "Integrated Service
in the Internet Architecture: An Overview", RFC 1633,
USC/Information Science Institute, June 1994.
[BRAD94] Braden, R., Clark, D., and S. Shenker, "Integrated Service in the Internet Architecture: An Overview", RFC 1633, USC/Information Science Institute, June 1994.
[BRAD92] Bradley, T., and C. Brown, "Inverse Address Resolution
Protocol", RFC 1293, Wellfleet Communications, Inc., January
1992.
[BRAD92] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992.
[HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
[HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 19] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 19] RFC 1755 ATM Signaling Support for IP over ATM February 1995
[ISO8473] ISO/IEC 8473, Information processing systems - Data
communications - Protocol for providing the connectionless-mode
network service, 1988.
[ISO8473] ISO/IEC 8473, Information processing systems - Data communications - Protocol for providing the connectionless-mode network service, 1988.
[ISO9577] Information Technology - Telecommunication and information
exchange between systems - Protocol identification in the network
layer ISO/IEC TR9577 (International Standards Organization:
Geneva, 1990).
[ISO9577] Information Technology - Telecommunication and information exchange between systems - Protocol identification in the network layer ISO/IEC TR9577 (International Standards Organization: Geneva, 1990).
[LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, December 1993.
[LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, December 1993.
[PART92] Partridge, C., "A Proposed Flow Specification", RFC 1363,
BBN, September 1992.
[PART92] Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN, September 1992.
[Q.2931] Broadband Integrated Service Digital Network (B-ISDN)
Digital Subscriber Signaling System No.2 (DSS2) User Network
Interface Layer 3 Specification for Basic Call/Connection Control
ITU-T Recommendation Q.2931, (International Telecommunication
Union: Geneva, 1994)
[Q.2931] Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 1994)
Authors' Addresses
Authors' Addresses
Maryann Perez Maher USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Maryann Perez Maher USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Phone: 703-807-0132 EMail: perez@isi.edu
Phone: 703-807-0132 EMail: perez@isi.edu
Fong-Ching Liaw FORE Systems, Inc. 174 Thorn Hill Road Warrendale, PA 15086-7535
Fong-Ching Liaw FORE Systems, Inc. 174 Thorn Hill Road Warrendale, PA 15086-7535
Phone: (412) 772-8668 EMail: fong@fore.com
Phone: (412) 772-8668 EMail: fong@fore.com
Allison Mankin USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Allison Mankin USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Phone: 703-807-0132 EMail: mankin@isi.edu
Phone: 703-807-0132 EMail: mankin@isi.edu
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 20] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 20] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Eric Hoffman USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Eric Hoffman USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203
Phone: 703-807-0132 EMail: hoffman@isi.edu
Phone: 703-807-0132 EMail: hoffman@isi.edu
Dan Grossman Motorola Codex
Dan Grossman Motorola Codex
Phone: 617-821-7333 EMail: dan@merlin.dev.cdx.mot.com
Phone: 617-821-7333 EMail: dan@merlin.dev.cdx.mot.com
Andrew G. Malis Ascom Timeplex, Inc. Advanced Products Business Unit 289 Great Road Suite 205 Acton, MA 01720
Andrew G. Malis Ascom Timeplex, Inc. Advanced Products Business Unit 289 Great Road Suite 205 Acton, MA 01720
Phone: (508) 266-4522 EMail: malis@maelstrom.timeplex.com
Phone: (508) 266-4522 EMail: malis@maelstrom.timeplex.com
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 21] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 21] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Appendix A. Sample Signaling Messages
Appendix A. Sample Signaling Messages
1. SETUP and CONNECT messages
1. SETUP and CONNECT messages
This appendix shows sample codings of the SETUP and CONNECT signaling messages. The fields in the IE header are not shown.
This appendix shows sample codings of the SETUP and CONNECT signaling messages. The fields in the IE header are not shown.
+--------------------------------------------------------------------+
SETUP
+--------------------------------------------------------------------+ SETUP
Information Elements/
Fields Value/(Meaning)
-------------------- ---------------
Information Elements/ Fields Value/(Meaning) -------------------- ---------------
aal_parameters
aal_type 5 (AAL 5)
fwd_max_sdu_size_ident 140
fwd_max_sdu_size (send IP MTU value)
bkw_max_sdu_size_ident 129
bkw_max_sdu_size (recv IP MTU value)
sscs_type identifier 132
sscs_type 0 (null SSCS)
aal_parameters aal_type 5 (AAL 5) fwd_max_sdu_size_ident 140 fwd_max_sdu_size (send IP MTU value) bkw_max_sdu_size_ident 129 bkw_max_sdu_size (recv IP MTU value) sscs_type identifier 132 sscs_type 0 (null SSCS)
user_cell_rate
fwd_peak_cell_rate_0_1_ident 132
fwd_peak_cell_rate_0_1 (link rate)
bkw_peak_cell_rate_0_1_ident 133
bkw_peak_cell_rate_0_1 (link rate)
best_effort_indication 190
user_cell_rate fwd_peak_cell_rate_0_1_ident 132 fwd_peak_cell_rate_0_1 (link rate) bkw_peak_cell_rate_0_1_ident 133 bkw_peak_cell_rate_0_1 (link rate) best_effort_indication 190
bb_bearer_capability
spare 0
bearer_class 16 (BCOC-X)
spare 0
traffic_type 0 (no indication)
timing_reqs 0 (no indication)
susceptibility_to_clipping 0 (not susceptible to
clipping)
spare 0
user_plane_configuration 0 (point_to_point)
bb_bearer_capability spare 0 bearer_class 16 (BCOC-X) spare 0 traffic_type 0 (no indication) timing_reqs 0 (no indication) susceptibility_to_clipping 0 (not susceptible to clipping) spare 0 user_plane_configuration 0 (point_to_point)
bb_low_layer_information
layer_2_id 2
user_information_layer 12 (lan_llc (ISO 8802/2)
bb_low_layer_information layer_2_id 2 user_information_layer 12 (lan_llc (ISO 8802/2)
qos_parameter
qos_class_fwd 0 (class 0)
qos_class_bkw 0 (class 0)
qos_parameter qos_class_fwd 0 (class 0) qos_class_bkw 0 (class 0)
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 22] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 22] RFC 1755 ATM Signaling Support for IP over ATM February 1995
called_party_number
type_of_number (international number / unknown)
addr_plan_ident (ISDN / ATM Endsystem Address)
number (E.164 / ATM Endsystem Address)
called_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ATM Endsystem Address) number (E.164 / ATM Endsystem Address)
calling_party_number
type_of_number (international number / unknown)
addr_plan_ident (ISDN / ATM Endsystem Address)
presentation_indic (presentation allowed)
spare 0
screening_indic (user_provided verified and passed)
number (E.164 / ATM Endsystem Address)
calling_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ATM Endsystem Address) presentation_indic (presentation allowed) spare 0 screening_indic (user_provided verified and passed) number (E.164 / ATM Endsystem Address)
+--------------------------------------------------------------------+
Figure 1.
Sample contents of SETUP message
+--------------------------------------------------------------------+ Figure 1. Sample contents of SETUP message
[* : optional, ignored if present]
[* : optional, ignored if present]
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 23] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 23] RFC 1755 ATM Signaling Support for IP over ATM February 1995
In IP over ATM environments the inclusion of the "AAL parameters" IE is *mandatory* to allow for MTU size negotiation between the source and destination. The "Broadband Low Layer Information" IE is also mandatory for specifying the IP encapsulation scheme.
In IP over ATM environments the inclusion of the "AAL parameters" IE is *mandatory* to allow for MTU size negotiation between the source and destination. The "Broadband Low Layer Information" IE is also mandatory for specifying the IP encapsulation scheme.
+--------------------------------------------------------------------+
CONNECT
+--------------------------------------------------------------------+ CONNECT
Information Elements/
Fields Value
-------------------- -----
aal_parameters
aal_type 5 (AAL 5)
fwd_max_sdu_size_ident 140
fwd_max_sdu_size (send IP MTU value)
bkw_max_sdu_size_ident 129
bkw_max_sdu_size (recv IP MTU value)
sscs_type identifier 132
sscs_type 0 (null SSCS)
Information Elements/ Fields Value -------------------- ----- aal_parameters aal_type 5 (AAL 5) fwd_max_sdu_size_ident 140 fwd_max_sdu_size (send IP MTU value) bkw_max_sdu_size_ident 129 bkw_max_sdu_size (recv IP MTU value) sscs_type identifier 132 sscs_type 0 (null SSCS)
bb_low_layer_information
layer_2_id 2
user_information_layer 12 (lan_llc (ISO 8802/2)
bb_low_layer_information layer_2_id 2 user_information_layer 12 (lan_llc (ISO 8802/2)
connection identifier
spare 0
vp_assoc_signaling 1 (explicit indication of VPCI)
preferred_exclusive 0 (exclusive vpci/vci)
vpci (assigned by network)
vci (assigned by network)
+--------------------------------------------------------------------+
Figure 2.
Sample contents of CONNECT message
connection identifier spare 0 vp_assoc_signaling 1 (explicit indication of VPCI) preferred_exclusive 0 (exclusive vpci/vci) vpci (assigned by network) vci (assigned by network) +--------------------------------------------------------------------+ Figure 2. Sample contents of CONNECT message
As in the SETUP message, IP over ATM environments demand the inclusion of the "AAL parameters" IE so that the destination may specify the MTU size that it is willing to receive.
As in the SETUP message, IP over ATM environments demand the inclusion of the "AAL parameters" IE so that the destination may specify the MTU size that it is willing to receive.
2. Hints on Use of CALL PROCEEDING Message
2. Hints on Use of CALL PROCEEDING Message
Use of the CALL PROCEEDING message is beneficial in implementations where the called party's ATM signaling entity and AAL Users are decoupled. An arriving SETUP may result in an immediate CALL PROCEEDING response from the called party's ATM signaling entity, while it locally queries the called IP-ATM entity to see if the SETUP's conditions are acceptable. The acceptance of the SETUP's conditions would then cause the ATM signaling entity to issue a CONNECT back to the switch. The two possible refusal modes at the
Use of the CALL PROCEEDING message is beneficial in implementations where the called party's ATM signaling entity and AAL Users are decoupled. An arriving SETUP may result in an immediate CALL PROCEEDING response from the called party's ATM signaling entity, while it locally queries the called IP-ATM entity to see if the SETUP's conditions are acceptable. The acceptance of the SETUP's conditions would then cause the ATM signaling entity to issue a CONNECT back to the switch. The two possible refusal modes at the
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 24] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 24] RFC 1755 ATM Signaling Support for IP over ATM February 1995
called party then become:
called party then become:
a) Called party has no IP-ATM entity resident. Issue RELEASE
COMPLETE in response to SETUP.
a) Called party has no IP-ATM entity resident. Issue RELEASE COMPLETE in response to SETUP.
b) Called party has a resident IP-ATM entity, so CALL PROCEEDING
was issued. The IP-ATM entity rejects the call request, so a
RELEASE is issued instead (to be acknowledged by the network
with RELEASE COMPLETE).
b) Called party has a resident IP-ATM entity, so CALL PROCEEDING was issued. The IP-ATM entity rejects the call request, so a RELEASE is issued instead (to be acknowledged by the network with RELEASE COMPLETE).
Appendix B. IP over ATM using UNI 3.0 Signaling
Appendix B. IP over ATM using UNI 3.0 Signaling
This appendix describes how to support IP over ATM using UNI 3.0 signalling. Differences in the coding or semantics of each relevant IE is given.
This appendix describes how to support IP over ATM using UNI 3.0 signalling. Differences in the coding or semantics of each relevant IE is given.
1. AAL parameter
1. AAL parameter
Values for maximum SDU size may range from one (not zero) to 64K.
Values for maximum SDU size may range from one (not zero) to 64K.
A 'mode' field is an allowable field in UNI 3.0. Nevertheless, this 'mode' field SHOULD be omitted from the AAL Parameters IE and MUST be ignored by the destination endsystem.
A 'mode' field is an allowable field in UNI 3.0. Nevertheless, this 'mode' field SHOULD be omitted from the AAL Parameters IE and MUST be ignored by the destination endsystem.
2. Traffic Management Related IEs
2. Traffic Management Related IEs
In UNI 3.0 issues of traffic management were less understood than in UNI 3.1. UNI 3.0 does not contain a guide to coordinating the use of the User Cell Rate IE (Traffic Descriptor IE in UNI 3.1), Broadband Bearer Capability IE, and QoS parameters IE. Therefore, the recommendation for specifying parameters in these IEs is the same as that given above when using UNI 3.1. The following section merely describes relevant differences in names and code values.
In UNI 3.0 issues of traffic management were less understood than in UNI 3.1. UNI 3.0 does not contain a guide to coordinating the use of the User Cell Rate IE (Traffic Descriptor IE in UNI 3.1), Broadband Bearer Capability IE, and QoS parameters IE. Therefore, the recommendation for specifying parameters in these IEs is the same as that given above when using UNI 3.1. The following section merely describes relevant differences in names and code values.
2.1 ATM User Cell Rate (instead of ATM Traffic Descriptor)
2.1 ATM User Cell Rate (instead of ATM Traffic Descriptor)
The ATM Traffic Descriptor IE is refered to as 'ATM User Cell Rate' IE in UNI 3.0. Also, the value for the cause 'user cell rate unavailable' is #51.
The ATM Traffic Descriptor IE is refered to as 'ATM User Cell Rate' IE in UNI 3.0. Also, the value for the cause 'user cell rate unavailable' is #51.
2.3 QoS parameters
2.3 QoS parameters
The two-bit 'coding standard' field of the General Information octet in the IE header, should be set to '11' inidicating that the IE is a standard defined for the network (as opposed to an ITU-TS standard) present on the network side of the interface.
The two-bit 'coding standard' field of the General Information octet in the IE header, should be set to '11' inidicating that the IE is a standard defined for the network (as opposed to an ITU-TS standard) present on the network side of the interface.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 25] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 25] RFC 1755 ATM Signaling Support for IP over ATM February 1995
3. ATM Addressing Information
3. ATM Addressing Information
In UNI 3.1, the 'ATM Endsystem Address' type was introduced to differentiate ATM addresses from OSI NSAPs. In UNI 3.0, 'ATM Endsystem Address' is not a valid type. Therefore, in the called and calling party subaddress IEs the three-bit 'type of subaddress' field MUST specify 'NSAP' (value = 001) when using the subaddress IE to carry ATM addresses.
In UNI 3.1, the 'ATM Endsystem Address' type was introduced to differentiate ATM addresses from OSI NSAPs. In UNI 3.0, 'ATM Endsystem Address' is not a valid type. Therefore, in the called and calling party subaddress IEs the three-bit 'type of subaddress' field MUST specify 'NSAP' (value = 001) when using the subaddress IE to carry ATM addresses.
4. Dealing with Failure of Call Establishment
4. Dealing with Failure of Call Establishment
In UNI 3.0 the there are certain cause values which are different than UNI 3.1. Two relevant differences are the following:
In UNI 3.0 the there are certain cause values which are different than UNI 3.1. Two relevant differences are the following:
'AAL Parameter Cannot Be Supported' is #93 (#78 in UNI 3.1), and
'AAL Parameter Cannot Be Supported' is #93 (#78 in UNI 3.1), and
'User Cell Rate Unavailable' is #51 (#37 in UNI 3.1).
'User Cell Rate Unavailable' is #51 (#37 in UNI 3.1).
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 26] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 26] RFC 1755 ATM Signaling Support for IP over ATM February 1995
Appendix C.
Appendix C.
Combinations of Traffic Related Parameters
tha MAY be supported in the SETUP message
Combinations of Traffic Related Parameters tha MAY be supported in the SETUP message
|-----------------------------------------------------------------|
|Broadband Bearer |
|Capability |
|-----------------------------------------------------------------|
|Broadband Bearer |A,C| X |X |C | X |C| X |A,C| X | X |C| X |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Traffic Type | | | | | | | | | | | | |
|(CBR,VBR) | |CBR| & | |& | |& | |CBR|& |&| & |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Timing Required | | Y |&& | |&& | |&& | | Y |&& | |&& |
|-----------------------------------------------------------------|
|Traffic Descriptor |
|Parameter |
|-----------------------------------------------------------------|
|PCR (CLP=0) | S | S | S | | | | | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|PCR (CLP=0+1) | S | S | S | S | S |S| S | S | S | S |S| S |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|SCR (CLP=0) | | | | | S |S| | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|SCR (CLP=0+1) | | | | | | | S | S | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|MBS (CLP=0) | | | | | S |S| | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|MBS (CLP=0+1) | | | | | | | S | S | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Best Effort | | | | | | | | | | |S| S |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Tagging |Y/N|Y/N|Y/N|Y/N|Y/N|N| N | N | N | N |N| N |
|-----------------------------------------------------------------|
|-----------------------------------------------------------------|
|QOS Classes | * | * | * | * | * |*| * | * | * | * |0| 0 |
|-----------------------------------------------------------------|
|-----------------------------------------------------------------| |広帯域の運搬人| |能力| |-----------------------------------------------------------------| |広帯域の運搬人|A、C| X|X|C| X|C| X|A、C| X| X|C| X| |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |交通タイプ| | | | | | | | | | | | | |(CBR、VBR) | |CBR| & | |& | |& | |CBR|& |&| & | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |タイミングが必要です。| | Y|&& | |&& | |&& | | Y|&& | |&& | |-----------------------------------------------------------------| |交通記述子| |パラメタ| |-----------------------------------------------------------------| |PCR(CLP=0)| S| S| S| | | | | | | | | | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |PCR(CLP=0+1)| S| S| S| S| S|S| S| S| S| S|S| S| |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |SCR(CLP=0)| | | | | S|S| | | | | | | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |SCR(CLP=0+1)| | | | | | | S| S| | | | | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |mb(CLP=0)| | | | | S|S| | | | | | | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |mb(CLP=0+1)| | | | | | | S| S| | | | | |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |ベストエフォート型| | | | | | | | | | |S| S| |---------------------|---|---|---|---|---|-|---|---|---|---|-|---| |タグ付け|Y/N|Y/N|Y/N|Y/N|Y/N|N| N| N| N| N|N| N| |-----------------------------------------------------------------| |-----------------------------------------------------------------| |QOSのクラス| * | * | * | * | * |*| * | * | * | * |0| 0 | |-----------------------------------------------------------------|
(Table 2 is a reproduction of Table F-1 of Appendix F in [ATMF 94].)
(テーブル2は[ATMF94]でのAppendix FのTableエフワンの再現です。)
PCR = Peak Cell Rate, SCR = Sustainable Cell Rate,
MBS = Maximum Burst Size
PCRはピークセルレートと等しく、SCRは持続可能なセルレートと等しく、mbは最大の放出量と等しいです。
Y = Yes, N = No, S = Specified
S=はYがはいと等しく、Nがいいえと等しいと指定しました。
Y/N = either "Yes" or "No" is allowed
「はい」かY/N=「いいえ」のどちらかが許容されています。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 27] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[27ページ]
* = allowed QoS class values are a network option. Class 0 is
always supported for alignment with ITU-T
* = QoS階級値が許容されているのは、ネットワークオプションです。 クラス0はITU-Tとの整列のためにいつも支持されます。
& = parameter is coded to either "no indication" or VBR or
octet 5a(Traffic Type/Timing Required) is absent; these three
codings are treated as equivalent
= パラメタが「指示がありません」かVBRのどちらかにコード化されるか、または八重奏5a(交通Type/タイミングRequired)は欠けています。 これらの3つのコーディングが同等物として扱われます。
&& = parameter is coded to either "no indication" or "No" or
octet 5a(Traffic Type/Timing Required) is absent; these three
codings are treated as equivalent
= パラメタが「指示がありません」か「いいえ」のどちらかにコード化されるか、または八重奏5a(交通Type/タイミングRequired)は欠けています。 これらの3つのコーディングが同等物として扱われます。
A blank entry in the table indicates that the parameter is not
present.
テーブルの空白のエントリーは、パラメタが存在していないのを示します。
Appendix D. Frame Relay Interworking
付録D.フレームリレーの織り込むこと
1. RFC 1490 over FR-SSCS vs. RFC 1483 over null-SSCS
1. ヌルSSCSの上のフラン-SSCSの対RFC上RFC1490 1483
Procedures for Frame Relay to ATM signaling interworking have not yet been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC 1490 encapsulation must both be be specified in the SETUP message. Nevertheless, since neither LLC encapsulation nor VC-multiplexing will interoperate when used over FR-SSCS, these two encapsulations cannot be negotiated as alternatives to RFC 1490 encapsulation (see Section 4, Encapsulation Negotiation).
ATMシグナリングの織り込むことへのFrame Relayのための手順はITU-T、ATM Forum、またはFrame Relay Forumによってまだ指定されていません。 ATM endsystemが、SETUPメッセージで指定されているようにフラン-SSCS、フラン-SSCS、およびRFC1490カプセル化がともにそうしなければならない使用に願うなら。 それにもかかわらず、フラン-SSCSの上で使用される場合LLCカプセル化もVC-マルチプレクシングも共同利用しないので、RFC1490カプセル化への代替手段としてこれらの2つのカプセル化を交渉できません(セクション4を見てください、Encapsulation Negotiation)。
In ATM environments the SSCS layer is part of the AAL functionality. The SSCS serves to coordinate the needs of a protocol above with the requirements of next lower layer, the Common Part Convergence Sublayer (CPCS). For example, the UNI ATM signaling protocol runs on top of a signaling SSCS which among other things provides an assured transfer service for signaling messages. Since the SSCS is considered part of the AAL, the SSCS type is specified as one of the parameters in the AAL Parameters IE. To date there has not been an SSCS defined for data transmission in ATM and this type field is usually set to 'null'.
ATM環境で、SSCS層はAALの機能性の一部です。 SSCSは、次の下層の要件による上のプロトコルの必要性を調整するのに役立ちます、Common Part Convergence Sublayer(CPCS)。 例えば、UNI ATMシグナリングプロトコルはシグナリングメッセージのための確実な転送サービスを特に提供するシグナリングSSCSの上を走ります。 SSCSがAALの一部であると考えられるので、SSCSタイプはAAL Parameters IEのパラメタの1つとして指定されます。 これまで、ATMのデータ伝送のために定義されたSSCSがありませんでした、そして、通常、このタイプ分野は'ヌル'に設定されます。
The exception occurs when doing FR interworking where an ATM endsystem may choose to use the FR-SSCS over AAL 5 in order to communicate with a FR endsystem. In that case the SSCS type in the AAL Parameters IE of the SETUP message is set to 'FR-SSCS'.
ATM endsystemがFR endsystemとコミュニケートするのにAALの上のフラン-SSCS5を使用するのを選ぶかもしれないところでFRの織り込むことをするとき、例外は起こります。 その場合、SETUPメッセージのAAL Parameters IEのSSCSタイプは'フラン-SSCS'に用意ができています。
Also included in a SETUP message is an indication in the B-LLI IE of the protocol layers to be used above the AAL. In particular, ATM connections established to carry connectionless network interconnect traffic require a layer above the AAL for multiplexing multiple protocols over a single VC [HEIN 93]. As mentioned above, RFC 1577
また、SETUPメッセージに含まれているのは、AALの上で使用されるべきプロトコル層のB-LLI IEの指示です。 特に、コネクションレスなネットワーク内部連絡交通を運ぶために確立されたATM接続は、独身のVC[ハイン93]の上に複数のプロトコルを多重送信するためにAALの上の層を必要とします。 以上のようのRFC1577
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 28] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[28ページ]
defines LLC as default multiplexing layer for IP over AAL5.
IPのためにAAL5の上に層を多重送信するデフォルトとLLCを定義します。
Specification of the SSCS restricts the encapsulation protocol used over it, since RFC 1483 (in addition to applicable ITU standards) defines the use of RFC 1490 encapsulation over the FR-SSCS, and LLC or null encapsulation otherwise. The fact that it is not possible, in the UNI 3.0 signaling specification, to negotiate between the FR- SSCS and null-SSCS can result in interoperability restrictions between stations that implement and wish to use the FR-SSCS and those that do not, even though they both are using IP. The guidelines in the following section were developed to decrease the chance that such interoperability restrictions occur.
SSCSの仕様はそれの上で使用されるカプセル化プロトコルを制限します、そうでなければ、RFC1483(適切なITU規格に加えた)がフラン-SSCSと、LLCかヌルカプセル化の上でRFC1490カプセル化の使用を定義するので。 それが可能でないという彼らの両方がIPを使用していますが、ステーションの間でSSCSとヌルSSCSがもたらすことができるフラン相互運用性制限の間でその道具を交渉して、フラン-SSCSとそうしないそれらを使用することを願うために仕様に合図するUNI3.0の事実。 以下のセクションのガイドラインは、そのような相互運用性制限が起こるという可能性を減少させるために開発されました。
2. Scenarios for Interworking
2. 織り込むシナリオ
The following discussion uses the terms "network interworking" and "service interworking". "Network interworking" uses FR-SSCS over AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and the ATM endsystem is aware that the other endpoint is a FR/ATM Network IWU. "Service interworking" aims to make the operation transparent to the ATM endsystem by adding encapsulation translation and other payload processing in the FR/ATM Service IWU to allow the ATM endsystem to operate as if it were talking to another ATM endsystem.
以下の議論は用語「ネットワークの織り込ん」で「サービスの織り込む」を使用します。 「ネットワークの織り込むこと」はInterWorking Unit(IWU)とATM endsystemの間のAAL5の上でフラン-SSCSを使用します、そして、ATM endsystemはもう片方の終点がFR/ATM Network IWUであることを意識しています。 「サービスの織り込むこと」は、まるで別のATM endsystemと話しているかのようにATM endsystemが作動するのを許容するためにFR/ATM Service IWUでカプセル化翻訳と他のペイロード処理を加えることによって操作をATM endsystemに透明にすることを目指します。
The most common scenario where FR-SSCS could be negotiated is between an ATM endsystem and a FR/ATM network IWU to allow connectivity among an ATM endsystem and a FR endsystem residing behind a FR/ATM network IWU.
FR/ATMネットワークIWUの後ろに住みながらATM endsystemとFR endsystemの中に接続性を許容するために、ATM endsystemとFR/ATMネットワークIWUの間には、フラン-SSCSを交渉できた最も一般的なシナリオはあります。
-------- --------
------- | | | | -------
| A | | FR/ATM | | ATM | | B |
| (FR) |----->| IWU |----->| switch |----->| (ATM) |
------- | | | | -------
-------- --------
-------- -------- ------- | | | | ------- | A| | フラン/気圧| | 気圧| | B| | (フラン) |、-、-、-、--、>| IWU|、-、-、-、--、>| スイッチ|、-、-、-、--、>| (気圧) | ------- | | | | ------- -------- --------
| | | |
-----> --------------------->
FR call ATM call
| | | | ----->。--------------------->FR呼び出しATMは呼びます。
A network IWU can place a call to an ATM host (on behalf of a FR host) by signaling for FR-SSCS and assuming that the ATM endsystem supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC 1490 encapsulation and the SSCS type field of the AAL Parameters IE SHALL be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails because the called ATM host does not support FR-SSCS, the IWU can retry the call negotiating for LLC encapsulation or VC-multiplexing.
フラン-SSCSのために合図して、ATM endsystemがフラン-SSCSを支持すると仮定することによって、ネットワークIWUはATMホスト(FRホストを代表した)に電話することができます。 AAL Parameters IE SHALLの1490年のRFCカプセル化とSSCSタイプ分野がフラン-SSCSを示すためにコード化されるのをB-LLI IE SHALL、コード化されて、示してください。 呼ばれたATMホストがフラン-SSCSを支持しないのでフラン-SSCS交渉が失敗するなら、IWUはLLCカプセル化かVC-マルチプレクシングを交渉する呼び出しを再試行できます。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 29] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[29ページ]
However, the IWU can only attempt the retry if it is able to do FR- ATM service interworking. Such service interworking adds extra processing overhead during the call.
しかしながら、FR- ATMサービスの織り込むことができる場合にだけ、IWUは再試行を試みることができます。 そのようなサービスの織り込むのは呼び出しの間、余分な処理オーバヘッドを加えます。
The even more problematic case occurs when a call is requested in the opposite direction, i.e. when an ATM host places a call to a host residing behind an IWU.
呼び出しが逆方向に要求されているとき、さらに問題の多いケースは現れます、すなわち、ATMホストがIWUの後ろに住んでいるホストに電話するとき。
-------- --------
------- | | | | -------
| B | | FR/ATM | | ATM | | A |
| (FR) |<-----| IWU |<-----| switch |<-----| (ATM) |
------- | | | | -------
-------- --------
-------- -------- ------- | | | | ------- | B| | フラン/気圧| | 気圧| | A| | (フラン) | <、-、-、-、--、| IWU| <、-、-、-、--、| スイッチ| <、-、-、-、--、| (気圧) | ------- | | | | ------- -------- --------
| | | |
<----- <---------------------
FR call ATM call
| | | | <、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- FR呼び出しATMは呼びます。
Not knowing that the destination resides behind an IWU, the calling host will negotiate for the default LLC encapsulation (possibly requesting VC-multiplexing as an alternative). In this situation the IWU can accept the call and do the necessary service interworking or reject the call specifying 'AAL Parameters not supported'. If the IWU rejects the call it risks the possibility that calling host does not support FR-SSCS or simply does not retry and the call will never be established.
目的地がIWUの後ろに住んでいるのを知らないで、呼んでいるホストはデフォルトLLCカプセル化を交渉するでしょう(ことによると代替手段としてVC-マルチプレクシングを要求して)。 この状況で、IWUは呼び出しを受け入れて、必要なサービスの織り込むことをするか、または'AAL Parametersは支持しなかった'呼び出し指定を拒絶できます。 IWUがそれが危険にさらす呼び出しを拒絶すると、ホストに電話をするのは、フラン-SSCSを支持しないか、または絶対に再試行されない可能性と要求は決して確立されないでしょう。
3. Possible Alternatives
3. 可能な代替手段
While Frame Relay interworking is possible, it is not possible to negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, which decreases the chances of completing an ATM call. However, interoperability can be increased using the following alternatives:
Frame Relayの織り込むのは可能ですが、LLCカプセル化かVC-マルチプレクシングとフラン-SSCSを交渉するのは可能ではありません。(マルチプレクシングはATM呼び出しを終了するという可能性を減少させます)。 しかしながら、相互運用性は以下の代替手段を使用することで増加できます:
1. Maintaining external knowledge that a particular destination uses FR-SSCS. This knowledge can be configured, or in the future added to some network host database.
1. 特定の目的地がフラン-SSCSを使用するという外部の知識を維持します。 この知識を構成するか、または将来、何らかのネットワークホストデータベースに追加できます。
2. In the absence of such external knowledge, an ATM endsystem is required to negotiate for the default LLC encapsulation (possibly requesting VC-multiplexing as an alternative). There are three sub- cases:
2. そのような外部の知識がないとき、ATM endsystemが、デフォルトLLCカプセル化を交渉するのに必要です(ことによると代替手段としてVC-マルチプレクシングを要求して)。 3つのサブケースがあります:
2a. The IWU supports service interworking and network interworking, and prefers service interworking. The IWU simply accepts the call using LLC encapsulation.
2a。 IWUはサービスの織り込むのとネットワークの織り込むことを支持して、サービスの織り込むことを好みます。 IWUは、LLCカプセル化を使用することで単に呼び出しを受け入れます。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 30] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[30ページ]
2b. The IWU supports service interworking and network interworking, and prefers network interworking. The IWU simply accepts the call, but attempts to open a parallel connection back to the original ATM endsystem negotiating the FR-SSCS use. If the connection is accepted, the IWU closes the service interworking connection.
2b。 IWUはサービスの織り込むのとネットワークの織り込むことを支持して、ネットワークの織り込むことを好みます。 IWUは、単に呼び出しを受け入れますが、フラン-SSCS使用を交渉するオリジナルのATM endsystemに並列接続を開いて戻すのを試みます。 接続を受け入れるなら、IWUは接続を織り込むサービスを終えます。
2c. The IWU supports network interworking only. The IWU rejects the call specifying 'AAL Parameters not supported', and then attempts to open a connection back to the original ATM endsystem negotiating the FR-SSCS use.
2c。 IWUはネットワークの織り込むことだけを支持します。 IWUは、'AAL Parametersは支持しなかった'呼び出し指定を拒絶して、次に、フラン-SSCS使用を交渉するオリジナルのATM endsystemに接続を開いて戻すのを試みます。
4. Encapsulation negotiation
4. カプセル化交渉
The call/connection control signaling protocol includes a mechanism to support negotiation of encapsulation for endsystems that support more than one. This section describes the procedures for negotiation of an encapsulation.
呼び出し/接続規制シグナリングプロトコルは、1つ以上を支持するendsystemsのためにカプセル化の交渉を支持するためにメカニズムを含んでいます。 このセクションはカプセル化の交渉のための手順について説明します。
The B-LLI negotiation procedures (see Annex C of [ATMF93]) are initiated by the calling ATM endsystem by including up to three instances of the B-LLI IE in the SETUP message in descending order of preference (following the rule for repeating IE in section 5.4.5.1 of [ATMF93]).
SETUPメッセージに好み(.1繰り返しているIEコネセクション5.4.5[ATMF93]の規則に従う)の降順でB-LLI IEの最大3つの例を含んでいることによって、B-LLI交渉手順([ATMF93]のAnnex Cを見る)は職業ATM endsystemによって着手されます。
The following is the list of the three possible combinations that B- LLI IE instances MAY be included in the SETUP message. Each instance is referred to by its encapsulation name as it appears in RFC 1483, and corresponding section labels from Appendix D of the ATM Forum UNI 3.0 specification.
↓これはB LLI IE例があるかもしれないSETUPメッセージに含まれていた3つの可能な組み合わせのリストです。 各例はRFC1483、および該当箇所ラベルにATM Forum UNI3.0仕様のAppendix Dから現れるようにカプセル化名によって参照されます。
a) LLC/SNAP encapsulation (D.3.1)
a) LLC/SNAPカプセル化(D.3.1)
In this case, the calling ATM endsystem can only send and receive packets preceded by an LLC/SNAP identification. This memo requires that hosts and routers which are ATM endsystems implement LLC/SNAP encapsulation.
この場合、呼んでいるATM endsystemはLLC/SNAP識別で先行されたパケットを、送って、受けることができるだけです。 このメモは、ATM endsystemsであるホストとルータがLLC/SNAPカプセル化を実行するのを必要とします。
b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1)
b) VC-マルチプレクシング(D.3.2)とLLC/スナップ(D.3.1)
The calling ATM endsystem prefers to use VC multiplexing, but is willing to agree to use LLC/SNAP encapsulation instead, if the called ATM endsytem only supports LLC/SNAP.
呼んでいるATM endsystemは、VCマルチプレクシングを使用するのを好みますが、代わりにLLC/SNAPカプセル化を使用するのに同意しても構わないと思っています、呼ばれたATM endsytemがLLC/SNAPを支持するだけであるなら。
c) RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS
(D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS
type of AAL Parameters IE.)
c) FRSSCSの上のRFC1490カプセル化(NLPIDマルチプレクシング)(D.3.3、SSCSのフラン-SSCSは八重奏の7aと7bを省略して、省略したに違いないので、AAL Parameters IEをタイプします。)
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 31] RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC1755気圧シグナリングがIPのために気圧1995年2月の間に支持するペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[31ページ]
The calling ATM endsystem can only send and receive packets using RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 1490 encapsulation presently cannot be negotiated as an alternative to LLC encapsulation or VC-multiplexing. If the B-LLI IE is encoded to indicate RFC 1490 encapsulation, the SSCS type field of the AAL Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL Parameters IE can not be coded to indicate both NULL and FR-SSCS and neither LLC encapsulation nor VC-multiplexing will be interoperable when used over FR-SSCS.
呼んでいるATM endsystemは、FRSSCSの上でRFC1490カプセル化(NLPIDマルチプレクシング)を使用することでパケットを送って、受けることができるだけです。 1490年のRFCカプセル化の使用は、現在、LLCカプセル化に代わる手段として交渉されない、VCを多重送信しているはずがありません。 B-LLI IEが1490年のRFCカプセル化を示すためにコード化されるなら、SSCSはFRSSCSを示すためにコード化されたAAL Parameters IE SHALLの分野をタイプします。 フラン-SSCSの上で使用されるとどちらもNULLとフラン-SSCSとLLCカプセル化かVC-マルチプレクシングの両方が共同利用できるのを示すためにAAL Parameters IEをコード化できないことに注意してください。
The called ATM endsystem SHALL select the encapsulation method it is able to support from the B-LLI IE present in SETUP message. If it supports more than one of the encapsulations indicated in the SETUP message, it MUST select the one which appears first in the SETUP message. The called ATM endsystem then includes the B-LLI IE content corresponding to the selected encapsulation in the CONNECT message. If the called endsystem does not support any encapsulation indicated in the incoming SETUP message, it SHALL clear the call with cause #88, incompatible destination. If the received SETUP message does not include the B-LLI IE, the call SHALL be cleared with cause #21, "call rejected", with diagnostics indicating rejection reason = information element missing and the B-LLI IE identifier. As described in Annex C of [ATMF93], if the calling ATM endpoint receives a CONNECT message that does not contain a B-LLI IE, it SHALL assume the encapsulation indicated in the first BLLI IE that it included in the SETUP message.
呼ばれたATM endsystem SHALLはそれがSETUPメッセージの現在のB-LLI IEから支持できるカプセル化方法を選択します。 SETUPメッセージで示されたカプセル化の1つ以上を支持するなら、それは最初にSETUPメッセージに現れるものを選択しなければなりません。 そして、呼ばれたATM endsystemはCONNECTメッセージの選択されたカプセル化に対応するB-LLI IE内容を含んでいます。 呼ばれたendsystemがそうしないなら、入って来るSETUPメッセージで示されたあらゆるカプセル化を支持してください、それ。SHALLは原因#88で呼び出しをクリアします、非互換な目的地。 受信されたSETUPメッセージがB-LLI IEを含んでいないなら、呼び出しSHALLが原因#21できれいにされて、病気の特徴が拒絶理由を示している「拒絶された呼び出し」は情報要素の取り逃がすのとB-LLI IE識別子と等しいです。 それは呼んでいるATM終点が[ATMF93]CONNECTメッセージを受け取るならAnnex Cで説明されるようにB-LLI IEを含んでいません、それ。SHALLは、SETUPメッセージにそれを含んでいて、カプセル化が最初のBLLI IEでそれを示したと仮定します。
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 32]
ペレス、Liaw、マンキン、ホフマン、グロースマン、およびMalis[32ページ]
一覧
スポンサーリンク
