doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

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]
+