As per Relevance of the word signaling, we have this rfc below:
Network Working Group M.
Request for Comments: 3033
Category: Standards Track January 2001
The Assignment of the Information Field and Protocol
in the Q.2941 Generic Identifier and Q.2957 User-to-user
for the Internet
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The purpose of this document is to specify the assignment of
information field and protocol identifier in the Q.2941
Identifier and Q.2957 User-to-user Signaling for the
protocol
The assignment, that is specified in section 4 of this document,
designed for advanced B-ISDN signaling support of the
protocol, especially the B-ISDN signaling support for the
that corresponds to the session in the Internet protocol which
clarified in section 2. This specification provides an
framework for the implementation of long-lived session and QoS
sensitive session transfers over ATM
1. Purpose of
The purpose of this document is to specify the assignment of
information field and protocol identifier in the Q.2941
Identifier and Q.2957 User-to-user Signaling for the
protocol
The assignment, that is specified in section 4 of this document,
designed for advanced B-ISDN signaling support of the
protocol, especially the B-ISDN signaling support for the
that corresponds to the session in the Internet protocol which
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
specification is not limited to this support, and it should also
applicable to other purposes
This specification provides an indispensable framework for
implementation of long-lived session and QoS-sensitive
transfers over ATM. Note that this document only specifies
assignment of the information field and protocol identifier, and
it may not specify complete protocol that enables
implementation. This is because it is beyond the scope of
document and will be specified in a separate document
2. Session-related ATM
With the development of new multimedia applications on the
Internet, the demands for multimedia support are increasing in the
network, which currently supports best effort communications.
particular, demands to support QoS guaranteed communications
increasing with the development of voice, audio, and
communications applications. And it may also be necessary
introduce the mechanism that can efficiently transfer the huge
of traffic expected with these applications
The major features of B-ISDN are high speed, logical
with the VP/VC, and flexible QoS management per VC, so it is
natural to use these distinctive functions of B-ISDN to implement
multimedia support mechanism in the IP network. The flexible
management and logical multiplexing functions in B-ISDN are
expected method of implementing the QoS guaranteed communications
the Internet. And when a long-lived session is supported by
particular VC, efficient packet forwarding may be possible using
high speed and logical multiplexing of B-ISDN
This section clarifies B-ISDN signaling functions that are
when the session is supported by the VC, for advanced B-
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
An example scenario for establishing a VC for a long-lived session
shown in Fig. 2.1.
IP Router ATM SW ATM SW IP
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| | | / \ | | / \ | | |
+------+ +-----+ +-----+ +------+
A. New session initially forwarded over a default VC
IP Router ATM SW ATM SW IP
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| |<------+-/-\-+--------+-/-\-+------>| |
+------+ +-----+ +-----+ +------+
New VC is set
B. New VC is set up for the long-lived session
IP Router ATM SW ATM SW IP
+----+ Default VC +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | |<------+-\-/-+--------+-\-/-+------>| | +-+--+
|.....|__ |===||==| X |========| X |==||===| __|.....|
| \-->|<------+-/-\-+--------+-/-\-+------>|<--/ |
+------+ +-----+ +-----+ +------+
New
C. Transfer of the long-lived session to a new VC
Fig. 2.1: Example scenario for establishing a VC for a long-
session
First, a session is multiplexed into the default VC connecting
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
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
entity in the called side router must detect that the incoming
corresponds to a session of the Internet protocol and notify
fact to the IP layer entity. Based on this information, the IP
entity moves the session to the new VC
Therefore, to implement this signaling procedure, the B-
signaling must include an session identifier as an
element. The B-LLI, B-HLI, User-user, and Generic
information elements are all capable of transferring
information. Considering the original purposes of these
elements, the most appropriate one to use is the Generic
information element
2.2 QoS-sensitive Session
The major difference between QoS-sensitive session signaling
long-lived session signaling is that call setup is not initiated
the detection of a long-lived session, but is explicitly initiated
the setup protocol such as RSVP. To implement QoS-sensitive
signaling using ATM, the ATM network between the routers must
not only the session identifier but also the setup protocol
There are two schemes for forwarding the setup protocol. One is
multiplex the protocol into a default VC connecting the routers,
to forward the protocol through a particular VC. In this case,
QoS-sensitive session and the ATM VC are established sequentially
The second scheme is to forward the setup protocol as an
element in the B-ISDN signaling. In this case, the QoS-
session and the ATM VC are established simultaneously. The
scheme has the following advantages compared with the former one
o Easier to implement
- Admission control is simplified, because admission control
the IP and ATM layers can be done simultaneously
- Watchdog timer processing is simplified, because there is no
to watch the IP layer establishment and ATM layer
sequentially
o If the setup protocol supports negotiation, then an ATM VC
QoS is based on the result of negotiation can be established
However, the latter scheme, at least, cannot support a case where
PVC is used to support a QoS-sensitive session. Therefore,
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
QoS-sensitive session and an ATM VC is shown in Fig. 2.2.
IP Router ATM SW ATM SW IP
+----+ B-ISDN Signaling +----+
| WS | +------+ UNI +-----+ Setup +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/--Protocol--\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| \-->|<------+-/-\-+--------+-/-\-+------>|<--/ |
+------+ +-----+ Data +-----+ +------+
QoS
N-CONNECT | |
---------->| | | | | |
|->| SETUP | | | |
| |------------>| | | |
| |<------------| | | |
| | CALL PROC |----------->| SETUP | |
| | | |------------>| |
| | | | |->| N-
| | | | | |---------->
| | | | | |<----------
| | | | CONN |<-| N-CONNECT-
| | | |<------------| |
| | | |------------>| |
| | CONN |<-----------| CONN ACK |->|
| |<------------| | | |
| |------------>| | | |
|<-| CONN ACK | | | |
<----------| | | | | |
N-CONNECT | |
-
Fig. 2.2: Example procedure for simultaneous QoS-sensitive
and ATM VC establishment
RSVP is currently proposed for the setup protocol and new
protocols are likely to be developed in the future. Therefore,
generalize the discussion, the procedure for the setup protocol
this example is the general connection setup procedure
confirmed service
To implement this signaling procedure, the B-ISDN signaling
include the User-user information element that the capacity
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
3.1 Overview of the Generic
The Generic Identifier enables the transfer of identifiers
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
information element for the Q.2931 [1] and Q.2971 [2] UNI
protocol. The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE
ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT,
PARTY, and DROP PARTY ACK messages that are transferred between end
to-end users in the ATM network may contain up to three
Identifier information elements. The ATM network transfers
Generic Identifier information element transparently if it
no coding rule errors
The format of the Generic Identifier information element specified
the Q.2941 is shown in Fig. 3.1.
Suzuki Standards Track [Page 6]
RFC 3033 GIT and UUS Assignment for IP January 2001
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
standard or application that uses the identifier. Assignment of
Identifier related standard/application field for the
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,
H.323/H.245 are also supported
A transferred identifier is given by the combination of
Identifier type, length and value fields, and a Generic
information element may contain multiple identifiers
Assignment of the Identifier type field for the Internet protocol
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
63 octets
See the Q.2941.1 and Draft Q.2941.2 for detailed
specifications of the Generic Identifier
3.2 Overview of the User-to-user
The User-to-user Signaling enables the transfer of
between end-to-end users in the ATM network, and it is defined
Q.2957 [5, 6] and in Q.2971 annex D [2] as an optional
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,
PARTY, and DROP PARTY ACK messages that are transferred between end
to-end users in the ATM network may contain a User-user
element. The ATM network transfers the User-user information
transparently if it contains no coding rule errors
From the viewpoint of B-ISDN signaling applications, it seems
Generic Identifier and User-to-user Signaling are similar functions
But their rules for processing exceptions are not completely
same, because their purposes are different. The Generic
is designed for the transfer of identifiers between the c-planes
while the User-to-user Signaling is designed for the transfer of
data via the c-planes. Another difference is that the
supports interworking with the user-user information element in
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.
that the ATM network may check the contents of the Generic
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.
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
that uses the user-user information
The User information field contains the user-user information to
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
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
4.1 Assignment in the Generic Identifier Information
4.1.1 Use of Generic
The information field and protocol identifier assignment
for the Internet protocol in the Generic Identifier
element is shown in Fig. 4.1.
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
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,
Experiment/Organization specific
The Identifier value field is assigned to Internet protocol
information which is identified by the Identifier
standard/application field and Identifier type field. The
identifiers are specified
Std./app. Id
IPv4 session identifier IPv4
IPv6 session identifier IPv6
MPLS VCID MPLS
Exp./Org. specific IPv4/ST2+/IPv6/MPLS
As described in section 3.1, the B-ISDN signaling message
between end-to-end users may contain up to three Generic
information elements. These elements may contain
identifiers. This document does not specify the order of
when multiple identifiers appear in a signaling message
This document also does not specify the semantics when
identifiers having the same Identifier type appear in a
message, or when a signaling message contains a Generic
information element that does not contain identifiers
When a B-ISDN signaling message containing a Generic
information element enters an ATM network that does not support
Generic Identifier, the network clears the call, discards
information element, or discards the signaling message. (
sections 4.5.1 and 5.6.8.1 of Q.2931 and section 9.3 of Q.2941.1
details.)
To enable reliable Generic Identifier information element transfer
when the calling party sends a SETUP or ADD PARTY message with up
three Generic Identifier information elements, the CONNECT or
PARTY ACK message returned by the called party must contain at
one Generic Identifier information element. The called party may
respond with the same identifiers received from the calling party
The calling party should confirm that the response message
at least one Generic Identifier information element. This
enables identifier negotiation; this document does not specify
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
If the Identifier related standard/application field in the
Identifier information element is the IPv4, and the Identifier
field in the identifier is the Session, the identifier is the IPv
session identifier. The format of the IPv4 session identifier
shown in Fig. 4.2.
Bits
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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,
Port, and Destination Port [7, 9, 10] are assigned in that order
the Identifier value field
Note: This specific session identifier is intended for use only
the explicit reservation. If wild card associations are needed at
later date, another identifier type will be used
4.1.3 IPv6 session
If the Identifier related standard/application field in the
Identifier information element is the IPv6, and the Identifier
field in the identifier is the Session, the identifier is the IPv
session identifier. The format of the IPv6 session identifier
Suzuki Standards Track [Page 12]
RFC 3033 GIT and UUS Assignment for IP January 2001
shown in Fig. 4.3.
Bits
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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,
Port, and Destination Port [8, 9, 10] are assigned in that order
the Identifier value field
Note: This specific session identifier is intended for use only
the explicit reservation. If wild card associations are needed at
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
If the Identifier related standard/application field in the
Identifier information element is the MPLS, and the Identifier
field in the identifier is the Resource, the identifier is the
VCID. The format of the MPLS VCID is shown in Fig. 4.4.
Bits
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
If the Identifier related standard/application field in the
Identifier information element is the IPv4, ST2+, IPv6, or MPLS,
the Identifier type field in the identifier is
Experiment/Organization specific, the identifier is
Experiment/Organization specific. The format of
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
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
(0xFE).
The first 3 octets in the Identifier value field must contain
Organizationally unique identifier (OUI) (as specified in IEEE 802-
1990; section 5.1).
4.2 Assignment in the User-user Information
4.2.1 Use of User-to-user
The information field and protocol identifier assignment
for the Internet protocol in the User-user information element
shown in Fig. 4.6.
Suzuki Standards Track [Page 15]
RFC 3033 GIT and UUS Assignment for IP January 2001
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
element
The Protocol discriminator field is the Internet protocol/
(0x06). In this case, the first 1 octet in the User
field is the Internet protocol/application identifier field
Assignment of the Internet protocol/application identifier field
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
field is assigned to Internet protocol/application
information that is identified by the Internet protocol/
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
element enters an ATM network that does not support the User-to-
Signaling, the network clears the call, discards the
element, or discards the signaling message. (See sections 4.5.1
5.6.8.1 of Q.2931, section 1.9 of Q.2957, and Q.2971 annex D
details.)
To enable reliable User-user information element transfer, when
calling party sends a SETUP or ADD PARTY message with a User-
information element, the CONNECT or ADD PARTY ACK message returned
the called party must contain a User-user information element.
called party may not respond with the same user information
from the calling party. The calling party should confirm that
response message contains a User-user information element. This
enables negotiation; this document does not specify the
procedure of this negotiation
4.2.2 RSVP
The format of the RSVP message is shown in Fig. 4.7.
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
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
protocol/application related information field. The SETUP
may contain the RSVP Resv message. The CONNECT message may
the RSVP ResvConf message. The RELEASE message may contain the
ResvErr or ResvTear message
4.2.3 Experiment/Organization
The format of the Experiment/Organization specific is shown in Fig
4.8.
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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
Experiment/Organization specific (0xFE).
The first 3 octets in the Internet protocol/application
information field must contain the Organizationally unique
(OUI) (as specified in IEEE 802-1990; section 5.1).
5. Open
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
environment. Wild card style aggregated session identifier may
feasible. However, before specifying Generic Identifier
for it, session aggregation model in ATM VCs should be clarified
o Generic Identifier support for the IPv6 flow label and
classes
The IPv6 flow label and traffic classes support may be needed
future. However, currently their semantics are not clear
6. IANA
When the Identifier related standard/application field in
Q.2941.2 Generic Identifier information element is the IPv4, ST2+,
IPv6, or MPLS, numbers between 0x10-0xFD in the Identifier type
are reserved for IANA assignment. (See section 3.1.) Following
policies outlined in [14], these numbers are allocated through
IETF Consensus action
When the Protocol discriminator field in the Q.2957 User-
information element is the Internet protocol/application,
between 0x03-0xFD in the Internet protocol/application
field are reserved for IANA assignment. (See section 4.2.1.)
Following the policies outlined in [14], these numbers are
through an IETF Consensus action
7. Security
This document specifies the information field and protocol
assignment in the Q.2941 Generic Identifier and Q.2957 User-to-
Signaling for the Internet protocol, so these do not weaken
security of the B-ISDN signaling
In a called party of the B-ISDN signaling, if the incoming
message contains the calling party number and if it is verified
passed by the ATM network or it is provided by the network, then
is feasible to use the calling party number for part of the
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
assignment in the Generic Identifier and User-to-user Signaling
ST2+. Note that this appendix is NOT part of the standard
A.1 ST2+ session
If the Identifier related standard/application field in the
Identifier information element is the ST2+, and the Identifier
field in the identifier is the Session, the identifier is the ST2+
session identifier. The format of the ST2+ session identifier
shown in Fig. A.1.
Bits
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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+
The format of the User-user information element for the ST2+ SCMP
shown in Fig. A.2.
8 7 6 5 4 3 2 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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+
(0x01).
The ST2+ SCMP [11] is assigned to the Internet protocol/
related information field. The SETUP and ADD PARTY messages
contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY
messages may contain the ST2+ SCMP ACCEPT message. The RELEASE
DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message
The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP
messages may contain the ST2+ SCMP REFUSE message
Suzuki Standards Track [Page 21]
RFC 3033 GIT and UUS Assignment for IP January 2001
[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
Call/Connection Control," ITU-T Recommendation Q.2931,
1995.
[2] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)-
Digital Subscriber Signaling System No. 2 (DSS 2)-User-
Interface Layer 3 Specification for Point-to-
Call/Connection Control," ITU-T Recommendation Q.2971,
1995.
[3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN
Digital Subscriber Signaling System No. 2 (DSS 2):
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):
Identifier Transport Extensions," ITU-T New
Q.2941.2, December 1999.
[5] ITU-T, "Stage 3 Description for Additional Information
Supplementary Service Using B-ISDN Digital Subscriber
System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User
(UUS)," ITU-T Recommendation Q.2957, February 1995.
[6] ITU-T, "Stage 3 Description for Additional Information
Supplementary Service Using B-ISDN Digital Subscriber
System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User
(UUS)," ITU-T Recommendation Q.2957 Amendment 1, December 1999.
[7] Postel, J., Ed., "Internet Protocol", STD 5, RFC 791,
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,
1980.
[10] Postel, J., Ed., "Transmission Control Protocol", STD 7,
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
Version 2 (ST2) Protocol Specification - Version ST2+",
1819, August 1995.
[12] Braden, R., Ed., "Resource ReSerVation Protocol (RSVP) -
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,
2001.
[14] Narten, T., and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[15] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP:
Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996.
[16] S. Damaskos and A. Gavras, "Connection Oriented Protocols
ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278,
1994.
[17] ITU-T, "Integrated Services Digital Network (ISDN)
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
the Provision of the OSI Connection-mode Network Service in
ISDN Environment," ITU-T Recommendation Q.923, February 1995.
Suzuki Standards Track [Page 23]
RFC 3033 GIT and UUS Assignment for IP January 2001
I would like to thank Kenichi Kitami of the NTT Information
Lab. Group, who is also the chair of ITU-T SG11 WP1,
Kuribayashi of the NTT Information Sharing Platform Labs.,
Yao and Takumi Ohba of the NTT Network Service Systems Labs.,
Noriyuki Takahashi of the NTT Information Sharing Platform Labs.,
their valuable comments and discussions
And I would also like to thank the active members of IETF, ITU-T,
ATM Forum, especially Joel Halpern of Newbridge Networks,
Malis of Ascend Communications, George Swallow and Bruce Davie
Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of AT&T, Greg
of Lucent, Kaoru Kenyoshi of NEC, Hiroto Uno of Hitachi,
Esaki and Kenichi Nagami of Toshiba, and Noritoshi Demizu of
for their valuable comments and suggestions
Also, this specification is based on various discussions during
ST2+ over ATM project at the NTT Multimedia Joint Project
NACSIS. I would like to thank Professor Shoichiro Asano of
National Center for Science Information Systems for his
advice in this area
Author's
Muneyoshi
NTT Information Sharing Platform
3-9-11, Midori-
Musashino-shi, Tokyo 180-8585,
Phone: +81-422-59-2119
Fax: +81-422-37-7691
EMail: suzuki.muneyoshi@lab.ntt.co.
Suzuki Standards Track [Page 24]
RFC 3033 GIT and UUS Assignment for IP January 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Suzuki Standards Track [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
