Network Working Group M. Suzuki
Request for Comments: 3033 NTT
Category: Standards Track January 2001
The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
Q.2941ジェネリック識別子とインターネットプロトコルのためのQ.2957ユーザ間のシグナリングにおける情報フィールドとプロトコル識別子の割り当て
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol.
この文書の目的は、Q.2941共通識別子とQ.2957インターネットプロトコルのためのユーザツーユーザシグナリングにおける情報フィールドの割り当て及びプロトコル識別子を指定することです。
The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS-sensitive session transfers over ATM.
この文書のセクション4で指定された割り当ては、インターネットプロトコルの高度なB-ISDNシグナリングをサポートするために明らかにされたインターネットプロトコルにセッションに対応する接続のための、特にB-ISDNシグナリングをサポートする設計されています部2この仕様は、長寿命のセッションおよびQoSに敏感なATM上のセッション転送の実現に不可欠なフレームワークを提供します。
The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol.
この文書の目的は、Q.2941共通識別子とQ.2957インターネットプロトコルのためのユーザツーユーザシグナリングにおける情報フィールドの割り当て及びプロトコル識別子を指定することです。
The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. Needless to say, the purpose of this specification is not limited to this support, and it should also be applicable to other purposes.
この文書のセクション4で指定された割り当ては、インターネットプロトコルの高度なB-ISDNシグナリングをサポートするために明らかにされたインターネットプロトコルにセッションに対応する接続のための、特にB-ISDNシグナリングをサポートする設計されています言うべきセクション2.言うまでもないが、この仕様書の目的は、このサポートに限定されるものではないが、それはまた、他の目的に適用可能であるべきです。
This specification provides an indispensable framework for the implementation of long-lived session and QoS-sensitive session transfers over ATM. Note that this document only specifies the assignment of the information field and protocol identifier, and that it may not specify complete protocol that enables interoperable implementation. This is because it is beyond the scope of this document and will be specified in a separate document.
この仕様は、ATM上長命セッションおよびQoSに敏感なセッション転送の実現に不可欠なフレームワークを提供します。この文書は情報提供を唯一のフィールドとプロトコル識別子の割り当てを指定し、それが相互運用可能な実装を可能に完全なプロトコルを指定しない場合があることに注意してください。それは、このドキュメントの範囲を超えていると、別の文書で指定されるためです。
With the development of new multimedia applications on the current Internet, the demands for multimedia support are increasing in the IP network, which currently supports best effort communications. In particular, demands to support QoS guaranteed communications are increasing with the development of voice, audio, and video communications applications. And it may also be necessary to introduce the mechanism that can efficiently transfer the huge volume of traffic expected with these applications.
現在、インターネット上の新しいマルチメディアアプリケーションの発展に伴い、マルチメディアのサポートのための要求は、現在、ベストエフォート型の通信をサポートしているIPネットワーク、中に増加しています。具体的には、保証通信は、音声、オーディオ、およびビデオ通信アプリケーションの開発に増加しているQoSをサポートするために求められています。そしてまた、効率的に、これらのアプリケーションで予想されるトラフィックの膨大な量を転送することができ仕組みを導入する必要があるかもしれません。
The major features of B-ISDN are high speed, logical multiplexing with the VP/VC, and flexible QoS management per VC, so it is quite natural to use these distinctive functions of B-ISDN to implement a multimedia support mechanism in the IP network. The flexible QoS management and logical multiplexing functions in B-ISDN are the expected method of implementing the QoS guaranteed communications in the Internet. And when a long-lived session is supported by a particular VC, efficient packet forwarding may be possible using the high speed and logical multiplexing of B-ISDN.
B-ISDNの主な特徴は、高速、VP / VCと論理多重化、およびVCごとの柔軟なQoS管理しているので、IPネットワークにおけるマルチメディア支持機構を実装するためにB-ISDNのこれらの特徴的な機能を使用することは非常に自然です。 B-ISDNにおけるフレキシブルQoS管理および論理多重化機能は、インターネットにおけるQoS保証通信を実現する予想方法です。長命のセッションが特定のVCに支持されている場合に、効率的なパケット転送が高速とB-ISDNの論理的多重化を使用可能であってもよいです。
This section clarifies B-ISDN signaling functions that are required when the session is supported by the VC, for advanced B-ISDN signaling support of the Internet protocol.
このセクションでは、セッションはVCによってサポートされているときに、インターネットプロトコルの高度なB-ISDNシグナリングをサポートするために、必要とされるB-ISDNシグナリング機能を明確にしています。
An example scenario for establishing a VC for a long-lived session is shown in Fig. 2.1.
長命のセッションのためにVCを確立するためのシナリオ例を図4に示す。2.1。
IP Router ATM SW ATM SW IP Router
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| | | / \ | | / \ | | |
+------+ +-----+ +-----+ +------+
A. New session initially forwarded over a default VC.
A.新しいセッションは、最初はデフォルトのVCを介して転送します。
IP Router ATM SW ATM SW IP Router
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| |<------+-/-\-+--------+-/-\-+------>| |
+------+ +-----+ +-----+ +------+
New VC is set up
B. New VC is set up for the long-lived session.
B.新しいVCは長命のセッション用に設定されています。
IP Router ATM SW ATM SW IP Router
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | |<------+-\-/-+--------+-\-/-+------>| | +-+--+
|.....|__ |===||==| X |========| X |==||===| __|.....|
| \-->|<------+-/-\-+--------+-/-\-+------>|<--/ |
+------+ +-----+ +-----+ +------+
New VC
C. Transfer of the long-lived session to a new VC.
新しいVCに長命セッションのC.転送。
Fig. 2.1: Example scenario for establishing a VC for a long-lived session.
図2.1：長命のセッションのためのVCを確立するためのシナリオ例。
First, a session is multiplexed into the default VC connecting the routers. Then, if a router detects that it is a long-lived session, it sets up a new VC for the session. If the new VC is established successfully, the long-lived session is moved to the new VC.
まず、セッションはルータを接続するデフォルトのVCに多重化されます。ルータはそれが長命のセッションであることを検出した場合、それはセッションのための新たなVCを設定します。新しいVCが正常に確立されている場合は、長寿命のセッションは新しいVCに移動されます。
In this procedure involving an ATM VC setup, the B-ISDN signaling entity in the called side router must detect that the incoming call corresponds to a session of the Internet protocol and notify that fact to the IP layer entity. Based on this information, the IP layer entity moves the session to the new VC.
ATM VCの設定を含むこの手順では、着信側ルータにおけるB-ISDNシグナリングエンティティは、着信呼がインターネットプロトコルのセッションに対応することを検出し、IPレイヤエンティティにその旨を通知しなければなりません。この情報に基づいて、IPレイヤエンティティは、新しいVCにセッションを移動します。
Therefore, to implement this signaling procedure, the B-ISDN signaling must include an session identifier as an information element. The B-LLI, B-HLI, User-user, and Generic Identifier information elements are all capable of transferring this information. Considering the original purposes of these information elements, the most appropriate one to use is the Generic Identifier information element.
したがって、このシグナリング手順を実装するために、B-ISDNシグナリングは、情報要素として、セッション識別子を含まなければなりません。 B-LLI、B-HLI、ユーザ・ユーザ、及び共通識別子情報要素は、すべての情報を転送することが可能です。これらの情報要素の元の目的を考慮し、使用するために最も適切なものは、共通識別子情報要素です。
The major difference between QoS-sensitive session signaling and long-lived session signaling is that call setup is not initiated by the detection of a long-lived session, but is explicitly initiated by the setup protocol such as RSVP. To implement QoS-sensitive session signaling using ATM, the ATM network between the routers must forward not only the session identifier but also the setup protocol.
QoSに敏感なセッションシグナリングおよび長寿命のセッションシグナリングの主な違いは、コールセットアップが長命セッションの検出によって開始されていませんが、明示的なRSVPとしてセットアッププロトコルによって開始されていることです。 ATMを使用してQoSに敏感なセッションシグナリングを実装するには、ルータ間のATMネットワークは、セッション識別子だけでなく、セットアッププロトコルだけでなく、転送する必要があります。
There are two schemes for forwarding the setup protocol. One is to multiplex the protocol into a default VC connecting the routers, or to forward the protocol through a particular VC. In this case, the QoS-sensitive session and the ATM VC are established sequentially. The second scheme is to forward the setup protocol as an information element in the B-ISDN signaling. In this case, the QoS-sensitive session and the ATM VC are established simultaneously. The latter scheme has the following advantages compared with the former one.
セットアッププロトコルを転送するための2つの方式があります。一つは、ルータを接続デフォルトVCにプロトコルを多重化する、または特定のVCを介してプロトコルを転送することです。この場合、QoSに敏感なセッションおよびATM VCを順次確立されています。第2のスキームは、B-ISDNシグナリングの情報要素として設定プロトコルを転送することです。この場合、QoSに敏感なセッションおよびATM VCが同時に確立されています。後者の方式は、前者に比べて以下の利点を有します。
o Easier to implement.
実装が簡単、O。
- Admission control is simplified, because admission control for the IP and ATM layers can be done simultaneously.
- IPやATM層のためのアドミッション制御を同時に行うことができるため、アドミッション制御が簡素化されます。
- Watchdog timer processing is simplified, because there is no need to watch the IP layer establishment and ATM layer establishment sequentially.
- ウォッチドッグタイマ処理を順次IPレイヤの確立とATMレイヤの確立を監視する必要はありませんので、簡略化されています。
o If the setup protocol supports negotiation, then an ATM VC whose QoS is based on the result of negotiation can be established.
セットアッププロトコルがネゴシエーションをサポートしている場合は、O、そしてそのQoSのネゴシエーションの結果に基づいてATM VCを確立することができます。
However, the latter scheme, at least, cannot support a case where a PVC is used to support a QoS-sensitive session. Therefore, both procedures should be taken into account.
しかし、後者の方式は、少なくとも、PVCは、QoSに敏感なセッションをサポートするために使用されている場合をサポートすることができません。したがって、両方の手順を考慮すべきです。
An example of a message sequence that simultaneously establishes a QoS-sensitive session and an ATM VC is shown in Fig. 2.2.
同時にQoSに敏感なセッションを確立し、ATM VCは、図2.2に示されたメッセージシーケンスの例。
IP Router ATM SW ATM SW IP Router
+----+ B-ISDN Signaling +----+
| WS | +------+ UNI +-----+ Setup +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/--Protocol--\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| \-->|<------+-/-\-+--------+-/-\-+------>|<--/ |
+------+ +-----+ Data +-----+ +------+
QoS VC
N-CONNECT | |
---------->| | | | | |
|->| SETUP | | | |
| |------------>| | | |
| |<------------| | | |
| | CALL PROC |----------->| SETUP | |
| | | |------------>| |
| | | | |->| N-CONNECT
| | | | | |---------->
| | | | | |<----------
| | | | CONN |<-| N-CONNECT-ACK
| | | |<------------| |
| | | |------------>| |
| | CONN |<-----------| CONN ACK |->|
| |<------------| | | |
| |------------>| | | |
|<-| CONN ACK | | | |
<----------| | | | | |
N-CONNECT | |
-ACK
Fig. 2.2: Example procedure for simultaneous QoS-sensitive session
and ATM VC establishment.
RSVP is currently proposed for the setup protocol and new setup protocols are likely to be developed in the future. Therefore, to generalize the discussion, the procedure for the setup protocol in this example is the general connection setup procedure using confirmed service.
RSVPは現在、セットアッププロトコルのために提案され、新しいセットアッププロトコルが将来開発される可能性が高いです。そのため、議論を一般化するために、この例では、セットアッププロトコルのための手順を確認し、サービスを利用して、一般的な接続設定手順です。
To implement this signaling procedure, the B-ISDN signaling must include the User-user information element that the capacity is sufficient to forward the setup protocol.
このシグナリング手順を実装するために、B-ISDNシグナリングは、容量が設定プロトコルを転送するのに十分であることをユーザ・ユーザ情報要素を含まなければなりません。
The Generic Identifier enables the transfer of identifiers between end-to-end users in the ATM network, and it is defined in the Q.2941 Part 1 (Q.2941.1) [3] and Part 2 (Q.2941.2) [4] as an optional information element for the Q.2931 [1] and Q.2971 [2] UNI signaling protocol. The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY ACK messages that are transferred between end-to-end users in the ATM network may contain up to three Generic Identifier information elements. The ATM network transfers the Generic Identifier information element transparently if it contains no coding rule errors.
共通識別子は、ATMネットワークにおけるエンドツーエンドユーザーとの間の識別子の転送を可能にし、それはQ.2941パート1（Q.2941.1）[3]及びパート2（Q.2941.2）で定義されている[4] Q.2931 [1]及びQ.2971 [2] UNIシグナリングプロトコルのためのオプションの情報要素として。 SETUPは、ALERTING、CONNECT、RELEASE、COMPLETE放出は、ATMネットワーク内のエンド・ツー・エンドユーザ間で転送されるDROP PARTY、およびDROP PARTY ACKメッセージが含まれていてもよいREJECT PARTYを追加し、PARTY ACKを追加し、PARTY、PARTYアラートを追加します3つの汎用識別子情報要素まで。それは符号則エラーが含まれていない場合、ATMネットワークは、透過共通識別子情報要素を転送します。
The format of the Generic Identifier information element specified in the Q.2941 is shown in Fig. 3.1.
Q.2941で指定された汎用識別子情報要素のフォーマットは、図に示されている。3.1。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = Generic identifier transport IE (0x7F) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier related standard/application | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length | 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier value | 8-
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier value |
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 3.1: Format of the Generic Identifier information element.
図3.1：汎用識別子情報要素のフォーマット。
The usage of the first 4 octets of fields is specified in section 4 of the Q.2931.
フィールドの最初の4つのオクテットの使用はQ.2931のセクション4で指定されています。
The Identifier related standard/application field identifies the standard or application that uses the identifier. Assignment of the Identifier related standard/application field for the Internet protocol is as follows. A leading 0x means hexadecimal.
識別子に関連する標準/アプリケーションのフィールドは、識別子を使用して標準またはアプリケーションを識別する。次のようにインターネットプロトコルの識別子に関連する標準/アプリケーションのフィールドの割り当てです。先行する0xは、16進数を意味します。
0x03: IPv4.
0x03の：IPv4の。
0x04: ST2+.
0x04を：ST2の+。
0x05: IPv6.
0×05：IPv6の。
0x06: MPLS.
0x06で：MPLS。
Note: DSM-CC, H.310/H.321, MPOA, ATM VCC Trunking, AAL2, and H.323/H.245 are also supported.
注意：DSM-CC、H.310 / H.321、MPOA、ATM VCCトランキング、AAL2、およびH.323 / H.245もサポートされています。
A transferred identifier is given by the combination of the Identifier type, length and value fields, and a Generic Identifier information element may contain multiple identifiers.
転送識別子が識別子タイプ、長さ、および値フィールドの組み合わせによって与えられ、共通識別子情報要素は、複数の識別子を含んでいてもよいです。
Assignment of the Identifier type field for the Internet protocol is as follows. A leading 0x means hexadecimal.
次のようにインターネットプロトコルの識別子タイプフィールドの割り当てです。先行する0xは、16進数を意味します。
0x01: Session.
0x01の：セッション。
0x02: Resource.
0×02：リソース。
0x10-0xFD: Reserved for IANA assignment.
0x10-0xFD：IANAの割り当てのために予約されています。
0xFE: Experiment/Organization specific.
0xFEの：実験/組織の特定。
The maximum length of the Generic Identifier information element is 63 octets.
汎用識別子情報要素の最大長さは63オクテットです。
See the Q.2941.1 and Draft Q.2941.2 for detailed protocol specifications of the Generic Identifier.
一般的な識別子の詳細なプロトコル仕様のためQ.2941.1とドラフトQ.2941.2を参照してください。
The User-to-user Signaling enables the transfer of information between end-to-end users in the ATM network, and it is defined in Q.2957 [5, 6] and in Q.2971 annex D [2] as an optional information element for the Q.2931 [1] and Q.2971 [2] UNI signaling protocol. The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS, ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY ACK messages that are transferred between end-to-end users in the ATM network may contain a User-user information element. The ATM network transfers the User-user information element transparently if it contains no coding rule errors.
ユーザツーユーザシグナリングは、ATMネットワークにおけるエンドツーエンドユーザー間の情報の転送を可能にし、それはQ.2957で定義されている[5、6]、Q.2971の附属書D [2]、オプションとしてQ.2931 [1]及びQ.2971 [2] UNIシグナリングプロトコルの情報要素。 ATMネットワークにおけるエンドツーエンドユーザー間で転送されるSETUP、ALERTING、CONNECT、RELEASEリリースCOMPLETE、PROGRESS、PARTYを追加し、PARTY ALERTING、PARTY ACKを追加、PARTYはREJECT ADD、DROP PARTY、およびDROP PARTY ACKメッセージユーザ・ユーザ情報要素が含まれていてもよいです。それは符号則エラーが含まれていない場合、ATMネットワークは透過ユーザ・ユーザ情報要素を転送します。
From the viewpoint of B-ISDN signaling applications, it seems the Generic Identifier and User-to-user Signaling are similar functions. But their rules for processing exceptions are not completely the same, because their purposes are different. The Generic Identifier is designed for the transfer of identifiers between the c-planes, while the User-to-user Signaling is designed for the transfer of user data via the c-planes. Another difference is that the latter supports interworking with the user-user information element in the
B-ISDNシグナリングアプリケーションの観点からは、共通識別子およびユーザツーユーザシグナリングは同様の機能であると思われます。その目的が異なっているので、しかし、処理の例外のための彼らのルールは、完全に同じではありません。ユーザツーユーザシグナリングは、c面を介してユーザデータの転送のために設計されている一般的な識別子は、c面との間の識別子の転送用に設計されています。もう1つの違いは、後者は、ユーザ・ユーザ情報要素とのインターワーキングをサポートしていることです
Q.931 N-ISDN signaling, but the Generic Identifier does not. Note that the ATM network may check the contents of the Generic Identifier information element, but does not check the contents of the User-to-user information element.
Q.931 N-ISDNシグナリングが、共通識別子はありません。 ATMネットワークは、共通識別子情報要素の内容を確認することができるが、ユーザ・ユーザ情報要素の内容をチェックしないことに留意されたいです。
The format of the User-user information element is shown in Fig. 3.2.
ユーザ・ユーザ情報要素のフォーマットは、図に示されている。3.2。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = User-user information element (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol discriminator | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| User information | 6-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 3.2: Format of the User-user information element.
図3.2：ユーザ・ユーザ情報要素のフォーマット。
The usage of the first 4 octets of fields is specified in section 4 of the Q.2931.
フィールドの最初の4つのオクテットの使用はQ.2931のセクション4で指定されています。
The Protocol discriminator field identifies the upper layer protocol that uses the user-user information.
プロトコル識別子フィールドは、ユーザ・ユーザ情報を使用して上位層プロトコルを識別する。
The User information field contains the user-user information to be transferred.
ユーザー情報フィールドは、転送されるユーザ・ユーザ情報が含まれています。
The maximum length of the User-user information element is 133 octets.
ユーザ・ユーザ情報要素の最大長は、133オクテットです。
See Q.2957, Draft Q.2957 amendment 1, and Q.2971 annex D for detailed protocol specifications of the User-to-user Signaling.
Q.2957、ドラフトQ.2957改正1、およびユーザツーユーザシグナリングの詳細なプロトコル仕様のためのQ.2971附属書Dを参照。
The information field and protocol identifier assignment principle for the Internet protocol in the Generic Identifier information element is shown in Fig. 4.1.
汎用識別子情報要素のインターネットプロトコルのための情報フィールドとプロトコル識別子割当原理を図1に示す。4.1。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = Generic identifier transport IE (0x7F) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier related standard/application |
| = IPv4, ST2+, IPv6, or MPLS | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Session, Resource, or Experiment | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length | 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier value | 8-
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Session, Resource, or Experiment |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier value |
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.1: Principle of assignment in the Generic Identifier information element.
図4.1：汎用識別子情報要素に割り当ての原則。
The Identifier related standard/application field is the IPv4, ST2+, IPv6, or MPLS.
識別子に関連する標準/アプリケーションのフィールドは、IPv4、ST2 +、IPv6の、またはMPLSあります。
The Identifier type field is the Session, Resource, or Experiment/Organization specific.
識別子タイプフィールドは、セッション、リソース、または実験/組織固有のものです。
The Identifier value field is assigned to Internet protocol related information which is identified by the Identifier related standard/application field and Identifier type field. The following identifiers are specified.
識別子値フィールドは、識別子に関連する標準/アプリケーションのフィールドと識別子タイプフィールドによって識別されるインターネットプロトコル関連情報に割り当てられています。次の識別子が指定されています。
Std./app. Id type
Std./app。 IDタイプ
IPv4 session identifier IPv4 Session
IPv4のセッション識別子IPv4のセッション
IPv6 session identifier IPv6 Session
IPv6のセッション識別子IPv6のセッション
MPLS VCID MPLS Resource
MPLS VCID MPLSリソース
Exp./Org. specific IPv4/ST2+/IPv6/MPLS Experiment
Exp./Org。特定のIPv4 / ST2 + / IPv6の/ MPLS実験
As described in section 3.1, the B-ISDN signaling message transferred between end-to-end users may contain up to three Generic Identifier information elements. These elements may contain multiple identifiers. This document does not specify the order of identifiers when multiple identifiers appear in a signaling message.
セクション3.1で説明したように、エンド・ツー・エンドユーザーとの間で転送されるB-ISDNシグナリングメッセージは、最大3つの汎用識別子情報要素を含んでいてもよいです。これらの要素は、複数の識別子が含まれていてもよいです。複数の識別子は、シグナリングメッセージに表示されたときにこの文書では、識別子の順序を指定していません。
This document also does not specify the semantics when multiple identifiers having the same Identifier type appear in a signaling message, or when a signaling message contains a Generic Identifier information element that does not contain identifiers.
同じ識別子のタイプを有する複数の識別子がシグナリングメッセージに表示されたときに、この文書はまた、セマンティクスが指定されていない、またはシグナリングメッセージは、識別子が含まれていない一般的な識別子情報要素が含まれている場合。
When a B-ISDN signaling message containing a Generic Identifier information element enters an ATM network that does not support the Generic Identifier, the network clears the call, discards the information element, or discards the signaling message. (See sections 4.5.1 and 5.6.8.1 of Q.2931 and section 9.3 of Q.2941.1 for details.)
共通識別子情報要素を含むB-ISDNシグナリングメッセージは共通識別子をサポートしていないATMネットワークに入ると、ネットワークは、呼をクリア情報要素を破棄し、またはシグナリングメッセージを破棄する。 （詳細については、セクション4.5.1及びQ.2931の5.6.8.1とQ.2941.1のセクション9.3を参照）。
To enable reliable Generic Identifier information element transfer, when the calling party sends a SETUP or ADD PARTY message with up to three Generic Identifier information elements, the CONNECT or ADD PARTY ACK message returned by the called party must contain at least one Generic Identifier information element. The called party may not respond with the same identifiers received from the calling party. The calling party should confirm that the response message contains at least one Generic Identifier information element. This rule enables identifier negotiation; this document does not specify the detailed procedure of this negotiation.
発呼者がSETUPを送信するか、最大3つの一般的な識別子情報要素を持つPARTYメッセージを追加し、CONNECTまたは被呼者によって返さPARTY ACKメッセージは、少なくとも1つの汎用識別子情報要素を含んでいなければならないADD信頼性の高い共通識別子情報要素の転送を、有効にするには。被呼者は、発呼者から受信した同じ識別子に応答しないことがあります。発呼者は、応答メッセージは、少なくとも1つの汎用識別子情報要素が含まれていることを確認する必要があります。この規則は、識別子のネゴシエーションを可能にします。この文書では、この交渉の詳細な手順を指定していません。
If the Identifier related standard/application field in the Generic Identifier information element is the IPv4, and the Identifier type field in the identifier is the Session, the identifier is the IPv4 session identifier. The format of the IPv4 session identifier is shown in Fig. 4.2.
汎用識別子情報要素内の識別子に関連する標準/アプリケーションのフィールドがIPv4であり、識別子内の識別子タイプフィールドがセッションである場合、識別子は、IPv4セッション識別子です。 IPv4のセッション識別子のフォーマットは、図に示されている。4.2。
Bits Octet
8 7 6 5 4 3 2 1 length
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Session (0x01) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
| = 13 octets (0x0D) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Source IPv4 address | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Destination IPv4 address | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Source Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Destination Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.2: IPv4 session identifier.
図4.2：IPv4のセッション識別子。
The Identifier type field is the Session (0x01).
識別子タイプフィールドは、セッション（0×01）です。
The Identifier length is 13 octets.
識別子の長さは13オクテットです。
The Source IPv4 address, Destination IPv4 address, Protocol, Source Port, and Destination Port [7, 9, 10] are assigned in that order to the Identifier value field.
送信元IPv4アドレス、宛先IPv4アドレス、プロトコル、送信元ポート、および宛先ポートは[7、9、10]識別子値フィールドへの順に割り当てられます。
Note: This specific session identifier is intended for use only with the explicit reservation. If wild card associations are needed at a later date, another identifier type will be used.
注：この特定のセッション識別子は、明示的な予約を使用することを意図しています。ワイルドカード協会は、後日必要な場合は、別の識別子タイプが使用されます。
If the Identifier related standard/application field in the Generic Identifier information element is the IPv6, and the Identifier type field in the identifier is the Session, the identifier is the IPv6 session identifier. The format of the IPv6 session identifier is shown in Fig. 4.3.
汎用識別子情報要素内の識別子に関連する標準/応用分野がIPv6であり、識別子内の識別子タイプフィールドがセッションである場合、識別子は、IPv6セッション識別子です。 IPv6のセッション識別子のフォーマットは、図に示されている。4.3。
Bits Octet
8 7 6 5 4 3 2 1 length
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Session (0x01) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
| = 37 octets (0x25) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Source IPv6 address | 16
+-----+-----+-----+-----+-----+-----+-----+-----+
| Destination IPv6 address | 16
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Source Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Destination Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.3: IPv6 session identifier.
図4.3：IPv6のセッション識別子。
The Identifier type field is the Session (0x01).
識別子タイプフィールドは、セッション（0×01）です。
The Identifier length is 37 octets.
識別子の長さは37オクテットです。
The Source IPv6 address, Destination IPv6 address, Protocol, Source Port, and Destination Port [8, 9, 10] are assigned in that order to the Identifier value field.
送信元IPv6アドレス、宛先IPv6アドレス、プロトコル、送信元ポート、および宛先ポートは[8,9,10]は識別子値フィールドへの順に割り当てられます。
Note: This specific session identifier is intended for use only with the explicit reservation. If wild card associations are needed at a later date, another identifier type will be used.
注：この特定のセッション識別子は、明示的な予約を使用することを意図しています。ワイルドカード協会は、後日必要な場合は、別の識別子タイプが使用されます。
If the Identifier related standard/application field in the Generic Identifier information element is the MPLS, and the Identifier type field in the identifier is the Resource, the identifier is the MPLS VCID. The format of the MPLS VCID is shown in Fig. 4.4.
汎用識別子情報要素内の識別子に関連する標準/アプリケーションフィールドはMPLSであり、識別子内の識別子タイプフィールドがリソースである場合、識別子は、MPLS VCIDあります。 MPLS VCIDのフォーマットは、図に示されている。4.4。
Bits Octet
8 7 6 5 4 3 2 1 length
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Resource (0x02) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
| = 4 octets (0x04) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| MPLS VCID | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.4: MPLS VCID.
図4.4：MPLS VCID。
The Identifier type field is the Resource (0x02).
識別子タイプフィールドは、リソース（0×02）です。
The Identifier length is 4 octets.
識別子の長さは4つのオクテットです。
The MPLS VCID [13] is assigned to the Identifier value field.
MPLS VCID [13]識別子値フィールドに割り当てられます。
If the Identifier related standard/application field in the Generic Identifier information element is the IPv4, ST2+, IPv6, or MPLS, and the Identifier type field in the identifier is the Experiment/Organization specific, the identifier is the Experiment/Organization specific. The format of the Experiment/Organization specific is shown in Fig. 4.5.
汎用識別子情報要素内の識別子に関連する標準/アプリケーションのフィールドは、IPv4、ST2 +、IPv6の、またはMPLS、識別子内の識別子タイプフィールドがある場合、識別子は、実験/組織特異的であり、実験/組織特異的です。実験/組織特定のフォーマットは、図に示されている。4.5。
Bits Octet
8 7 6 5 4 3 2 1 length
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Experiment/Organization specific (0xFE) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Organizationally unique identifier (OUI) | 3
+-----+-----+-----+-----+-----+-----+-----+-----+
| Experiment/Organization specific info. |
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.5: Experiment/Organization specific.
図4.5：実験/組織の特定。
The Identifier type field is the Experiment/Organization specific (0xFE).
識別子タイプフィールドは、実験/組織特異的（0xFEの）です。
The first 3 octets in the Identifier value field must contain the Organizationally unique identifier (OUI) (as specified in IEEE 802- 1990; section 5.1).
識別子値フィールドの最初の3つのオクテットは（;セクション5.1 IEEE 802- 1990年に指定されるように）組織固有識別子（OUI）を含んでいなければなりません。
The information field and protocol identifier assignment principle for the Internet protocol in the User-user information element is shown in Fig. 4.6.
ユーザ・ユーザ情報要素内のインターネットプロトコルの情報フィールドとプロトコル識別子割当原理を図1に示す。4.6。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = User-user information element (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol discriminator |
| = Internet protocol/application (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Internet protocol/application identifier | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Internet protocol/application related info. | 7-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.6: Principle of assignment in the User-user information element.
図4.6：ユーザ・ユーザ情報要素内の割り当ての原則。
The Protocol discriminator field is the Internet protocol/application (0x06). In this case, the first 1 octet in the User information field is the Internet protocol/application identifier field.
プロトコル識別子フィールドは、インターネットプロトコル/アプリケーション（0x06で）です。この場合、ユーザ情報フィールドの最初のオクテット1は、インターネットプロトコル/アプリケーション識別子フィールドです。
Assignment of the Internet protocol/application identifier field is as follows. A leading 0x means hexadecimal.
次のようにインターネットプロトコル/アプリケーション識別子フィールドの割り当てです。先行する0xは、16進数を意味します。
0x00: Reserved.
0x00：予約済み。
0x01: Reserved for ST2+.
0×01：ST2の+のために予約されています。
0x02: RSVP message.
0×02：RSVPメッセージ。
0x03-0xFD: Reserved for IANA assignment.
0x03-0xFD：IANAの割り当てのために予約されています。
0xFE: Experiment/Organization specific.
0xFEの：実験/組織の特定。
0xFF: Reserved.
0xFFを：予約済み。
The field that follows the Internet protocol/application identifier field is assigned to Internet protocol/application related information that is identified by the Internet protocol/application identifier field.
インターネットプロトコル/アプリケーション識別子フィールドを次のフィールドは、インターネットプロトコル/インターネットプロトコル/アプリケーション識別子フィールドによって識別されるアプリケーション関連情報に割り当てられています。
When a B-ISDN signaling message containing a User-user information element enters an ATM network that does not support the User-to-user Signaling, the network clears the call, discards the information element, or discards the signaling message. (See sections 4.5.1 and 5.6.8.1 of Q.2931, section 1.9 of Q.2957, and Q.2971 annex D for details.)
ユーザ・ユーザ情報要素を含むB-ISDNシグナリングメッセージはユーザ対ユーザシグナリングをサポートしていないATMネットワークに入ると、ネットワークが呼をクリアし、情報要素を破棄し、またはシグナリングメッセージを破棄する。 （セクション4.5.1およびQ.2931の5.6.8.1、Q.2957のセクション1.9、及び詳細はQ.2971附属書Dを参照）。
To enable reliable User-user information element transfer, when the calling party sends a SETUP or ADD PARTY message with a User-user information element, the CONNECT or ADD PARTY ACK message returned by the called party must contain a User-user information element. The called party may not respond with the same user information received from the calling party. The calling party should confirm that the response message contains a User-user information element. This rule enables negotiation; this document does not specify the detailed procedure of this negotiation.
発呼者がSETUPを送信するときに、信頼性の高いユーザ・ユーザ情報要素の転送を有効にするか、または、ユーザ・ユーザ情報要素とCONNECTをPARTYメッセージを追加したりするためにユーザ・ユーザ情報要素が含まれている必要があり、着信側によって返さPARTY ACKメッセージを追加します。被呼者は、発呼者から受信した同一のユーザ情報に応答しないことがあります。発呼者は、応答メッセージは、ユーザ・ユーザ情報要素が含まれていることを確認する必要があります。このルールは、交渉を可能にします。この文書では、この交渉の詳細な手順を指定していません。
The format of the RSVP message is shown in Fig. 4.7.
RSVPメッセージのフォーマットは、図に示されている。4.7。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = User-user information element (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol discriminator |
| = Internet protocol/application (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Internet protocol/application identifier |
| = RSVP message (0x02) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| RSVP message | 7-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.7: RSVP message.
図4.7：RSVPメッセージ。
The Internet protocol/application identifier field is the RSVP message (0x02).
インターネットプロトコル/アプリケーション識別子フィールドは、RSVPメッセージ（0×02）です。
The RSVP message [12] is assigned to the Internet protocol/application related information field. The SETUP message may contain the RSVP Resv message. The CONNECT message may contain the RSVP ResvConf message. The RELEASE message may contain the RSVP ResvErr or ResvTear message.
RSVPメッセージ[12]は、インターネットプロトコル/アプリケーション関連情報フィールドに割り当てられます。 SETUPメッセージは、RSVP Resvメッセージが含まれていてもよいです。 CONNECTメッセージは、RSVP ResvConfメッセージが含まれていてもよいです。 RELEASEメッセージは、RSVP ResvErrかたResvTearメッセージが含まれていてもよいです。
The format of the Experiment/Organization specific is shown in Fig. 4.8.
実験/組織特定のフォーマットは、図に示されている。4.8。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = User-user information element (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol discriminator |
| = Internet protocol/application (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Internet protocol/application identifier |
| = Experiment/Organization specific (0xFE) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Organizationally unique identifier (OUI) | 7-9
+-----+-----+-----+-----+-----+-----+-----+-----+
| Experiment/Organization specific info. | 10-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.8: Experiment/Organization specific.
図4.8：実験/組織の特定。
The Internet protocol/application identifier field is the Experiment/Organization specific (0xFE).
インターネットプロトコル/アプリケーション識別子フィールドは、実験/組織特異的（0xFEの）です。
The first 3 octets in the Internet protocol/application related information field must contain the Organizationally unique identifier (OUI) (as specified in IEEE 802-1990; section 5.1).
インターネットプロトコル/アプリケーション関連情報フィールドの最初の3つのオクテットは（;セクション5.1 IEEE 802から1990で指定されるように）組織固有識別子（OUI）を含んでいなければなりません。
The following issues are still remain in this document.
次の問題は、まだこの文書に残っています。
o Generic Identifier support for session aggregation.
セッション集約のためのOの汎用識別子のサポート。
Session aggregation support may be needed in a backbone environment. Wild card style aggregated session identifier may be feasible. However, before specifying Generic Identifier support for it, session aggregation model in ATM VCs should be clarified.
セッション集約サポートは、バックボーン環境で必要とすることができます。ワイルドカードスタイルの集約セッション識別子が実現可能です。しかし、そのための一般的な識別子のサポートを指定する前に、ATMのVCのセッション集約モデルを明確にする必要があります。
o Generic Identifier support for the IPv6 flow label and traffic classes.
IPv6のフローラベルおよびトラフィッククラスに対するOの汎用識別子のサポート。
The IPv6 flow label and traffic classes support may be needed in future. However, currently their semantics are not clear.
IPv6のフローラベルおよびトラフィッククラスのサポートは、将来的に必要とすることができます。しかし、現在はその意味は明確ではありません。
When the Identifier related standard/application field in the Q.2941.2 Generic Identifier information element is the IPv4, ST2+, IPv6, or MPLS, numbers between 0x10-0xFD in the Identifier type field are reserved for IANA assignment. (See section 3.1.) Following the policies outlined in [14], these numbers are allocated through an IETF Consensus action.
Q.2941.2汎用識別子情報要素内の識別子に関連する標準/アプリケーションのフィールドは、IPv4、ST2 +、IPv6の、またはMPLSの場合には、識別子タイプフィールドに0x10-0xFD間の数字は、IANA割り当てのために予約されています。 （セクション3.1を参照。）[14]に概説された方針に続いて、これらの数字は、IETF Consensus動作を通じて割り当てられます。
When the Protocol discriminator field in the Q.2957 User-user information element is the Internet protocol/application, numbers between 0x03-0xFD in the Internet protocol/application identifier field are reserved for IANA assignment. (See section 4.2.1.) Following the policies outlined in [14], these numbers are allocated through an IETF Consensus action.
Q.2957ユーザ・ユーザ情報要素内のプロトコル識別子フィールドは、インターネットプロトコル/アプリケーションである場合、インターネットプロトコル/アプリケーション識別子フィールドに0x03-0xFD間の数字は、IANA割り当てのために予約されています。 （セクション4.2.1を参照。）[14]に概説された方針に続いて、これらの数字は、IETF Consensus動作を通じて割り当てられます。
This document specifies the information field and protocol identifier assignment in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol, so these do not weaken the security of the B-ISDN signaling.
この文書では、Q.2941ジェネリック識別子とQ.2957ユーザ間のインターネットプロトコルのためのシグナリングにおける情報フィールドとプロトコル識別子の割り当てを指定するので、これらは、B-ISDNシグナリングのセキュリティを弱めないでください。
In a called party of the B-ISDN signaling, if the incoming SETUP message contains the calling party number and if it is verified and passed by the ATM network or it is provided by the network, then it is feasible to use the calling party number for part of the calling party authentication to strengthen security.
それが確認され、ATMネットワークによって渡されたか、それがネットワークによって提供されている場合は、着信SETUPメッセージは、発信者番号が含まれているとあればB-ISDNシグナリングの着呼側では、発信者番号を使用することが可能です発信者認証の一部のセキュリティを強化します。
Appendix. Information Field and Protocol Identifier Assignment for ST2+
付録。 ST2のための情報フィールドとプロトコル識別子の割り当て+
This appendix specifies information field and protocol identifier assignment in the Generic Identifier and User-to-user Signaling for ST2+. Note that this appendix is NOT part of the standard.
この付録では、ST2の+ための情報フィールドと共通識別子のプロトコル識別子の割り当ておよびユーザツーユーザシグナリングを指定します。この付録では、標準の一部ではないことに注意してください。
A.1 ST2+ session identifier
A.1のST2 +セッション識別子
If the Identifier related standard/application field in the Generic Identifier information element is the ST2+, and the Identifier type field in the identifier is the Session, the identifier is the ST2+ session identifier. The format of the ST2+ session identifier is shown in Fig. A.1.
汎用識別子情報要素内の識別子に関連する標準/アプリケーションフィールドがST2 +であり、識別子内の識別子タイプフィールドがセッションである場合、識別子は、ST2 +セッション識別子です。 ST2 +セッション識別子のフォーマットは、図A.1に示されています。
Bits Octet
8 7 6 5 4 3 2 1 length
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier type |
| = Session (0x01) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifier length |
| = 6 octets (0x06) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Stream ID (SID) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. A.1: ST2+ session identifier.
図A.1：ST2 +セッション識別子。
The Identifier type field is the Session (0x01).
識別子タイプフィールドは、セッション（0×01）です。
The Identifier length is 6 octets.
識別子の長さは6つのオクテットです。
The Stream ID (SID) [11] is assigned to the Identifier value field.
ストリームID（SID）[11]は識別子値フィールドに割り当てられます。
A.2 ST2+ SCMP
A.2 ST2 + SCMP
The format of the User-user information element for the ST2+ SCMP is shown in Fig. A.2.
ST2 + SCMPためのユーザ・ユーザ情報要素のフォーマットは、図に示されている。A.2。
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier |
| = User-user information element (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Coding | IE instruction field |
| Ext | standard |Flag |Res. | IE action ind. | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Length of contents of information element | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocol discriminator |
| = Internet protocol/application (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Internet protocol/application identifier |
| = ST2+ SCMP (0x01) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| ST2+ SCMP | 7-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. A.2: ST2+ SCMP.
図A.2：ST2 + SCMP。
The Internet protocol/application identifier field is the ST2+ SCMP (0x01).
インターネットプロトコル/アプリケーション識別子フィールドは、ST2 + SCMP（0×01）です。
The ST2+ SCMP [11] is assigned to the Internet protocol/application related information field. The SETUP and ADD PARTY messages may contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY ACK messages may contain the ST2+ SCMP ACCEPT message. The RELEASE and DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message. The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP PARTY messages may contain the ST2+ SCMP REFUSE message.
ST2 + SCMP [11]は、インターネットプロトコル/アプリケーション関連情報フィールドに割り当てられます。 SETUPとPARTYメッセージを追加するには、ST2 + SCMP CONNECTメッセージが含まれていてもよいです。 CONNECTおよびADD PARTY ACKメッセージは、ST2が含まれていてもよい+ SCMPは、メッセージを受け入れます。 RELEASEおよびDROP PARTYメッセージはST2 + SCMPのDISCONNECTメッセージが含まれていてもよいです。 RELEASE、RELEASE COMPLETEのは、PARTYが拒否ADD、およびDROP PARTYメッセージは、メッセージを拒否ST2 + SCMPが含まれていてもよいです。
References
リファレンス
[1] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control," ITU-T Recommendation Q.2931, September 1995.
[1] ITU-T、 "ブロードバンドサービス総合デジタル網（B-ISDN） - デジタル加入者シグナリングシステム2号（DSS 2） - ユーザ - ネットワークインタフェース（UNI）は基本的なコール/接続制御のための3仕様層と、" ITU -T勧告Q.2931、1995年9月。
[2] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)- Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface Layer 3 Specification for Point-to-Multipoint Call/Connection Control," ITU-T Recommendation Q.2971, October 1995.
[2] ITU-T、 "ブロードバンドサービス総合デジタル網（B-ISDN） - デジタル加入者線信号方式番号2ポイントツーマルチポイントコール/接続制御のための（DSS 2） - ユーザ - ネットワークインタフェースレイヤ3仕様、" ITU-T勧告Q.2971、1995年10月。
[3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport," ITU-T New Recommendation Q.2941.1, September 1997.
[3] ITU-T、 "ブロードバンドサービス総合デジタル網（B-ISDN）、デジタル加入者線信号方式番号2（DSS 2）：共通識別子トランスポート、" ITU-T新勧告Q.2941.1、1997年9月。
[4] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport Extensions," ITU-T New Recommendation Q.2941.2, December 1999.
[4] ITU-T、 "ブロードバンドサービス総合デジタル網（B-ISDN）、デジタル加入者線信号方式番号2（DSS 2）：共通識別子トランスポート拡張、" ITU-T新勧告Q.2941.2 1999年12月。
[5] ITU-T, "Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)," ITU-T Recommendation Q.2957, February 1995.
[5] ITU-T、 "B-ISDNデジタル加入者シグナリングシステム2号（DSS 2） - 基本コール項1ユーザツーユーザシグナリング（UUS）を使用して追加情報転送付加サービスのためのステージ3の説明において、" ITU -T勧告Q.2957、1995年2月。
[6] ITU-T, "Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)," ITU-T Recommendation Q.2957 Amendment 1, December 1999.
[6] ITU-T、 "B-ISDNデジタル加入者シグナリングシステム2号（DSS 2） - 基本コール項1ユーザツーユーザシグナリング（UUS）を使用して追加情報転送付加サービスのためのステージ3の説明において、" ITU -T勧告Q.2957改正1、1999年12月。
[7] Postel, J., Ed., "Internet Protocol", STD 5, RFC 791, September 1981.
[7]ポステル、J.、エド。、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[8]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[9] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[9]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[10] Postel, J., Ed., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[10]ポステル、J.、編、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[11] Delgrossi, L. and L. Berger, Ed., "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[11] Delgrossi、L.およびL.バーガー、エド、 "インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様 - バージョンST2 +"。、RFC 1819、1995年8月。
[12] Braden, R., Ed., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[12]ブレーデン、R.、エド、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、1997年9月。
[13] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.
[13]永見、K.、Demizu、N.、江崎、H.、勝部、Y.、およびP. Doolan、 "LDPのためのATMリンク上VCID通知"、RFC 3038、2001年1月。
[14] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[14] Narten氏、T.、およびH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[15] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996.
[15] P.ニューマン、T.リヨン、及びG. Minshall、 "IP標識フロー：ATMへコネクションアプローチ" PROC。 IEEEインフォコム、1996年3月。
[16] S. Damaskos and A. Gavras, "Connection Oriented Protocols over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, February 1994.
[16] S. Damaskos及びA. Gavras、 "ATM上コネクション指向プロトコル：ケーススタディ、" PROC。 SPIE、巻。 2188年、pp.226-278、1994年2月。
[17] ITU-T, "Integrated Services Digital Network (ISDN) Overall Network Aspects and Functions ISDN Protocol Reference Model," ITU-T Recommendation I.320, November 1993.
[17] ITU-T、 "総合デジタル通信網（ISDN）ネットワーク全体の側面および機能ISDNプロトコル参照モデル、" ITU-T勧告I.320、1993年11月。
[18] ITU-T, "Digital Subscriber Signaling System No. 1 (DSS 1) Specification of a Synchronization and Coordination Function for the Provision of the OSI Connection-mode Network Service in an ISDN Environment," ITU-T Recommendation Q.923, February 1995.
[18] ITU-T、「デジタル加入者シグナリングシステム1号（DSS 1）ISDN環境におけるOSI接続モードネットワークサービスを提供するための同期および調整機能の仕様、」ITU-T勧告Q.923 、1995年2月。
Acknowledgments
謝辞
I would like to thank Kenichi Kitami of the NTT Information Sharing Lab. Group, who is also the chair of ITU-T SG11 WP1, Shinichi Kuribayashi of the NTT Information Sharing Platform Labs., Hiroshi Yao and Takumi Ohba of the NTT Network Service Systems Labs., and Noriyuki Takahashi of the NTT Information Sharing Platform Labs., for their valuable comments and discussions.
私は、NTT情報流通研究所の健一北見市に感謝したいと思います。また、ITU-T SG11 WP1、NTT情報流通プラットフォーム研究所の伸一栗林の椅子です。グループ、。、宏八尾およびNTTネットワークサービスシステム研究所の匠大場。、およびNTT情報流通プラットフォーム研究所の則行高橋。 、彼らの貴重なコメントや議論のために。
And I would also like to thank the active members of IETF, ITU-T, and ATM Forum, especially Joel Halpern of Newbridge Networks, Andrew Malis of Ascend Communications, George Swallow and Bruce Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of AT&T, Greg Ratta of Lucent, Kaoru Kenyoshi of NEC, Hiroto Uno of Hitachi, Hiroshi Esaki and Kenichi Nagami of Toshiba, and Noritoshi Demizu of NAIST for their valuable comments and suggestions.
そして、私はまた、IETF、ITU-T、およびATMフォーラムのアクティブメンバー、特にニューブリッジネットワークスのジョエル・ハルパーン、アセンド・コミュニケーションズのアンドリューMalis、ジョージ・ツバメとシスコシステムズ、IBMのラオCherukuri、ラジブ・カプールのブルースデイビーに感謝したいと思いますAT＆T、ルーセントのグレッグRatta、NECの薫Kenyoshi、日立の弘人宇野、江崎浩、東芝の健一永見、およびNAISTの典俊Demizuの貴重な意見や提案のため。
Also, this specification is based on various discussions during the ST2+ over ATM project at the NTT Multimedia Joint Project with NACSIS. I would like to thank Professor Shoichiro Asano of the National Center for Science Information Systems for his invaluable advice in this area.
また、この仕様は、NACSISとNTTマルチメディア共同プロジェクトでのATMプロジェクトにわたるST2の+の間に様々な議論に基づいています。私はこの分野での彼の貴重なアドバイスを学術情報センターの教授正一郎浅野に感謝したいと思います。
Author's Address
著者のアドレス
Muneyoshi Suzuki NTT Information Sharing Platform Laboratories 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585, Japan
むねよし すずき んっｔ いんふぉｒまちおん しゃりんｇ Ｐぁｔふぉｒｍ ぁぼらとりえｓ ３ー９ー１１、 みどりーちょ むさしのーし、 ときょ １８０ー８５８５、 じゃぱん
Phone: +81-422-59-2119 Fax: +81-422-37-7691 EMail: suzuki.muneyoshi@lab.ntt.co.jp
電話：+ 81-422-59-2119ファックス：+ 81-422-37-7691 Eメール：suzuki.muneyoshi@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。