From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3033.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc3033.txt (limited to 'doc/rfc/rfc3033.txt') diff --git a/doc/rfc/rfc3033.txt b/doc/rfc/rfc3033.txt new file mode 100644 index 0000000..1934270 --- /dev/null +++ b/doc/rfc/rfc3033.txt @@ -0,0 +1,1403 @@ + + + + + + +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 + + +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. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +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. + + 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. + +1. Purpose of Document + + 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. + + 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 + + + +Suzuki Standards Track [Page 1] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + 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. + +2. Session-related ATM Connection + + 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. + + 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. + + 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. + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 2] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +2.1 Long-lived Session Signaling + + An example scenario for establishing a VC for a long-lived session is + shown in Fig. 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. + + + 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. + + + 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. + + Fig. 2.1: Example scenario for establishing a VC for a long-lived + session. + + 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. + + + + + +Suzuki Standards Track [Page 3] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + 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. + +2.2 QoS-sensitive Session Signaling + + 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. + + 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. + + o Easier to implement. + + - Admission control is simplified, because admission control for + the IP and ATM layers can be done simultaneously. + + - Watchdog timer processing is simplified, because there is no need + to watch the IP layer establishment and ATM layer establishment + sequentially. + + o If the setup protocol supports negotiation, then an ATM VC whose + QoS is based on the result of negotiation can be established. + + 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. + + + + +Suzuki Standards Track [Page 4] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + An example of a message sequence that simultaneously establishes a + QoS-sensitive session and an ATM VC is shown in Fig. 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. + + 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. + + + + + + + +Suzuki Standards Track [Page 5] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +3. Overview of the Generic Identifier and User-to-user Signaling + +3.1 Overview of the Generic Identifier + + 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. + + The format of the Generic Identifier information element specified in + the Q.2941 is shown in Fig. 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 6] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + The usage of the first 4 octets of fields is specified in section 4 + of the Q.2931. + + 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. + + 0x03: IPv4. + + 0x04: ST2+. + + 0x05: IPv6. + + 0x06: MPLS. + + + + +Suzuki Standards Track [Page 7] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + Note: DSM-CC, H.310/H.321, MPOA, ATM VCC Trunking, AAL2, and + H.323/H.245 are also supported. + + 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. + + 0x01: Session. + + 0x02: Resource. + + 0x10-0xFD: Reserved for IANA assignment. + + 0xFE: Experiment/Organization specific. + + The maximum length of the Generic Identifier information element is + 63 octets. + + See the Q.2941.1 and Draft Q.2941.2 for detailed protocol + specifications of the Generic Identifier. + +3.2 Overview of the User-to-user Signaling + + 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. + + 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 + + + + + + +Suzuki Standards Track [Page 8] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + The format of the User-user information element is shown in Fig. 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. + + The usage of the first 4 octets of fields is specified in section 4 + of the Q.2931. + + 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. + + See Q.2957, Draft Q.2957 amendment 1, and Q.2971 annex D for detailed + protocol specifications of the User-to-user Signaling. + + + + + + + + + + +Suzuki Standards Track [Page 9] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +4. Information Field and Protocol Identifier Assignment + +4.1 Assignment in the Generic Identifier Information Element + +4.1.1 Use of Generic Identifier + + The information field and protocol identifier assignment principle + for the Internet protocol in the Generic Identifier information + element is shown in Fig. 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. + + The Identifier related standard/application field is the IPv4, ST2+, + IPv6, or MPLS. + + + +Suzuki Standards Track [Page 10] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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 + + IPv4 session identifier IPv4 Session + + IPv6 session identifier IPv6 Session + + MPLS VCID MPLS Resource + + Exp./Org. specific IPv4/ST2+/IPv6/MPLS Experiment + + 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. + + 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.) + + 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. + + + + + +Suzuki Standards Track [Page 11] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +4.1.2 IPv4 session identifier + + 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. + + 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. + + The Identifier type field is the Session (0x01). + + The Identifier length is 13 octets. + + 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. + + 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. + +4.1.3 IPv6 session identifier + + 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 + + + +Suzuki Standards Track [Page 12] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + shown in Fig. 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. + + The Identifier type field is the Session (0x01). + + The Identifier length is 37 octets. + + 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. + + 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. + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 13] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +4.1.4 MPLS VCID + + 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. + + 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. + + The Identifier type field is the Resource (0x02). + + The Identifier length is 4 octets. + + The MPLS VCID [13] is assigned to the Identifier value field. + +4.1.5 Experiment/Organization specific + + 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. + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 14] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + The Identifier type field is the Experiment/Organization specific + (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). + +4.2 Assignment in the User-user Information Element + +4.2.1 Use of User-to-user Signaling + + The information field and protocol identifier assignment principle + for the Internet protocol in the User-user information element is + shown in Fig. 4.6. + + + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 15] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + + 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. + + Assignment of the Internet protocol/application identifier field is + as follows. A leading 0x means hexadecimal. + + 0x00: Reserved. + + 0x01: Reserved for ST2+. + + 0x02: RSVP message. + + 0x03-0xFD: Reserved for IANA assignment. + + 0xFE: Experiment/Organization specific. + + 0xFF: Reserved. + + 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. + + + + +Suzuki Standards Track [Page 16] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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.) + + 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. + +4.2.2 RSVP message + + The format of the RSVP message is shown in Fig. 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. + + The Internet protocol/application identifier field is the RSVP + message (0x02). + + + + +Suzuki Standards Track [Page 17] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + 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. + +4.2.3 Experiment/Organization specific + + The format of the Experiment/Organization specific is shown in Fig. + 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. + + The Internet protocol/application identifier field is the + Experiment/Organization specific (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). + +5. Open Issues + + The following issues are still remain in this document. + + + + +Suzuki Standards Track [Page 18] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + o Generic Identifier support for session aggregation. + + 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. + + o Generic Identifier support for the IPv6 flow label and traffic + classes. + + The IPv6 flow label and traffic classes support may be needed in + future. However, currently their semantics are not clear. + +6. IANA Considerations + + 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. + + 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. + +7. Security Considerations + + 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. + + 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. + + + + + + + + + + +Suzuki Standards Track [Page 19] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +Appendix. Information Field and Protocol Identifier Assignment for 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. + +A.1 ST2+ session identifier + + 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. + + 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. + + The Identifier type field is the Session (0x01). + + The Identifier length is 6 octets. + + The Stream ID (SID) [11] is assigned to the Identifier value field. + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 20] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +A.2 ST2+ SCMP + + The format of the User-user information element for the ST2+ SCMP is + shown in Fig. 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. + + The Internet protocol/application identifier field is the ST2+ SCMP + (0x01). + + 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. + + + + + + + + + + + + +Suzuki Standards Track [Page 21] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +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. + + [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. + + [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. + + [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. + + [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. + + [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. + + [7] Postel, J., Ed., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [9] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [10] Postel, J., Ed., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + + + + + +Suzuki Standards Track [Page 22] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + + [11] Delgrossi, L. and L. Berger, Ed., "Internet Stream Protocol + Version 2 (ST2) Protocol Specification - Version ST2+", RFC + 1819, August 1995. + + [12] Braden, R., Ed., "Resource ReSerVation Protocol (RSVP) - Version + 1 Functional Specification", RFC 2205, September 1997. + + [13] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan, + "VCID Notification over ATM link for LDP", RFC 3038, January + 2001. + + [14] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [15] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A + Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996. + + [16] S. Damaskos and A. Gavras, "Connection Oriented Protocols over + ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, February + 1994. + + [17] ITU-T, "Integrated Services Digital Network (ISDN) Overall + Network Aspects and Functions ISDN Protocol Reference Model," + ITU-T Recommendation I.320, November 1993. + + [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. + + + + + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 23] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +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. + + 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. + + 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. + +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 + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 24] + +RFC 3033 GIT and UUS Assignment for IP January 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + 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. + + + + + + + + + + + + + + + + + + + +Suzuki Standards Track [Page 25] + -- cgit v1.2.3