draft-ietf-mpls-git-uus-01.txt   draft-ietf-mpls-git-uus-02.txt 
Network Working Group Muneyoshi Suzuki Network Working Group Muneyoshi Suzuki
INTERNET DRAFT NTT INTERNET DRAFT NTT
Expires June 15, 1999 December 15, 1998 Expires September 29, 1999 March 29, 1999
The Assignment of the Information Field and Protocol Identifier The Assignment of the Information Field and Protocol Identifier
in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling
for the Internet Protocol for the Internet Protocol
<draft-ietf-mpls-git-uus-01.txt> <draft-ietf-mpls-git-uus-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the list Internet-Draft Shadow Directories, see
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/shadow.html.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The purpose of this document is to specify the assignment of the The purpose of this document is to specify the assignment of the
information field and protocol identifier in the Q.2941 Generic information field and protocol identifier in the Q.2941 Generic
Identifier and Q.2957 User-to-user Signaling for the Internet Identifier and Q.2957 User-to-user Signaling for the Internet
protocol. protocol.
The assignment, that is specified in section 4 of this document, is The assignment, that is specified in section 4 of this document, is
designed for advanced B-ISDN signaling support of the Internet designed for advanced B-ISDN signaling support of the Internet
protocol, especially the B-ISDN signaling support for the connection protocol, especially the B-ISDN signaling support for the connection
that corresponds to the session in the Internet protocol which is that corresponds to the session in the Internet protocol which is
clarified in section 2. This specification provides an indispensable clarified in section 2. This specification provides an indispensable
framework for the implementation of long-lived session and QoS- framework for the implementation of long-lived session and QoS-
sensitive session transfers over ATM. sensitive session transfers over ATM.
0. Background
In the ITU-T SG11 Geneva meeting held in May 1998, SG11 WP1, which
has responsibility for the B-ISDN signaling protocol recommendation,
decided to enhance the Q.2941 Generic Identifier Transport based on
this document and developed the Awaiting-review text. WP1 also
decided to continue discussion on the User-to-user Signaling support
for the Internet protocol.
In the ITU-T SG11 WP1 Oostend meeting held in November 1998, WP1
developed the Cooling text (Draft Recommendations to be frozen in the
next meeting, if no significant technical changes are proposed in
that meeting) of Q.2941.2 GIT [4]. WP1 also decided to enhance the
Q.2957 User-to-user Signaling based on this document and developed
the Awaiting-review text [5].
Expected standard development process (fastest case) for the
enhancement of the Generic Identifier and User-to-user Signaling is:
March 1999: Freeze the Draft Recommendations and letter ballot is
requested.
February 2000: The Draft Recommendations are decided (final
approval).
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. Note that the assignment rule for Generic Identifier and
User-to-user Signaling described in this document may be subject to
change.
1. Purpose of Document 1. Purpose of Document
The purpose of this document is to specify the assignment of the The purpose of this document is to specify the assignment of the
information field and protocol identifier in the Q.2941 Generic information field and protocol identifier in the Q.2941 Generic
Identifier and Q.2957 User-to-user Signaling for the Internet Identifier and Q.2957 User-to-user Signaling for the Internet
protocol. protocol.
The assignment, that is specified in section 4 of this document, is The assignment, that is specified in section 4 of this document, is
designed for advanced B-ISDN signaling support of the Internet designed for advanced B-ISDN signaling support of the Internet
protocol, especially the B-ISDN signaling support for the connection protocol, especially the B-ISDN signaling support for the connection
skipping to change at page 7, line 11 skipping to change at page 6, line 15
To implement this signaling procedure, the B-ISDN signaling must To implement this signaling procedure, the B-ISDN signaling must
include the User-user information element that the capacity is include the User-user information element that the capacity is
sufficient to forward the setup protocol. sufficient to forward the setup protocol.
3. Overview of the Generic Identifier and User-to-user Signaling 3. Overview of the Generic Identifier and User-to-user Signaling
3.1 Overview of the Generic Identifier 3.1 Overview of the Generic Identifier
The Generic Identifier enables the transfer of identifiers between 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 end-to-end users in the ATM network, and it is defined in the Q.2941
Part 1 (Q.2941.1) and Part 2 (Q.2941.2) as an optional information Part 1 (Q.2941.1) [3] and Part 2 (Q.2941.2) [4] as an optional
element for the Q.2931 and Q.2971 UNI signaling protocol. The SETUP, information element for the Q.2931 [1] and Q.2971 [2] UNI signaling
ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, ADD PARTY, PARTY protocol. The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE,
ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP
ACK messages that are transferred between end-to-end users in the ATM PARTY, and DROP PARTY ACK messages that are transferred between end-
network may contain up to three Generic Identifier information to-end users in the ATM network may contain up to three Generic
elements. The ATM network transfers the Generic Identifier Identifier information elements. The ATM network transfers the
information element transparently if it contains no coding rule Generic Identifier information element transparently if it contains
errors. no coding rule errors.
The format of the Generic Identifier information element specified in The format of the Generic Identifier information element specified in
the Q.2941 is shown in Fig. 3.1. the Q.2941 is shown in Fig. 3.1.
Bits Bits
8 7 6 5 4 3 2 1 Octets 8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier | | Information element identifier |
| = Generic identifier transport IE (0x7F) | 1 | = Generic identifier transport IE (0x7F) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
skipping to change at page 9, line 5 skipping to change at page 8, line 7
protocol is as follows. A leading 0x means hexadecimal. protocol is as follows. A leading 0x means hexadecimal.
0x03: IPv4. 0x03: IPv4.
0x04: ST2+. 0x04: ST2+.
0x05: IPv6. 0x05: IPv6.
0x06: MPLS. 0x06: MPLS.
Note: DSM-CC, H.310/H.321, Trunking, and MPOA are also supported. 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 A transferred identifier is given by the combination of the
Identifier type, length and value fields, and a Generic Identifier Identifier type, length and value fields, and a Generic Identifier
information element may contain multiple identifiers. information element may contain multiple identifiers.
Assignment of the Identifier type field for the Intenet protocol is Assignment of the Identifier type field for the Intenet protocol is
as follows. A leading 0x means hexadecimal. as follows. A leading 0x means hexadecimal.
0x01: Session. 0x01: Session.
skipping to change at page 9, line 32 skipping to change at page 8, line 35
The maximum length of the Generic Identifier information element is The maximum length of the Generic Identifier information element is
63 octets. 63 octets.
See the Q.2941.1 and Draft Q.2941.2 for detailed protocol See the Q.2941.1 and Draft Q.2941.2 for detailed protocol
specifications of the Generic Identifier. specifications of the Generic Identifier.
3.2 Overview of the User-to-user Signaling 3.2 Overview of the User-to-user Signaling
The User-to-user Signaling enables the transfer of information The User-to-user Signaling enables the transfer of information
between end-to-end users in the ATM network, and it is defined in between end-to-end users in the ATM network, and it is defined in
Q.2957 and in Q.2971 annex D as an optional information element for Q.2957 [5, 6] and in Q.2971 annex D [2] as an optional information
the Q.2931 and Q.2971 UNI signaling protocol. The SETUP, ALERTING, element for the Q.2931 [1] and Q.2971 [2] UNI signaling protocol.
CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS, ADD PARTY, PARTY The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS,
ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP
ACK messages that are transferred between end-to-end users in the ATM PARTY, and DROP PARTY ACK messages that are transferred between end-
network may contain a User-user information element. The ATM network to-end users in the ATM network may contain a User-user information
transfers the User-user information element transparently if it element. The ATM network transfers the User-user information element
contains no coding rule errors. transparently if it contains no coding rule errors.
From the viewpoint of B-ISDN signaling applications, it seems the From the viewpoint of B-ISDN signaling applications, it seems the
Generic Identifier and User-to-user Signaling are similar functions. Generic Identifier and User-to-user Signaling are similar functions.
But their rules for processing exceptions are not completely the But their rules for processing exceptions are not completely the
same, because their purposes are different. The Generic Identifier is same, because their purposes are different. The Generic Identifier is
designed for the transfer of identifiers between the c-planes, while designed for the transfer of identifiers between the c-planes, while
the User-to-user Signaling is designed for the transfer of user data the User-to-user Signaling is designed for the transfer of user data
via the c-planes. Another difference is that the latter supports via the c-planes. Another difference is that the latter supports
interworking with the user-user information element in the Q.931 N- interworking with the user-user information element in the Q.931 N-
ISDN signaling, but the Generic Identifier does not. Note that the ISDN signaling, but the Generic Identifier does not. Note that the
skipping to change at page 10, line 40 skipping to change at page 9, line 43
The Protocol discriminator field identifies the upper layer protocol The Protocol discriminator field identifies the upper layer protocol
that uses the user-user information. that uses the user-user information.
The User information field contains the user-user information to be The User information field contains the user-user information to be
transferred. transferred.
The maximum length of the User-user information element is 133 The maximum length of the User-user information element is 133
octets. octets.
See Draft Q.2957 and Q.2971 annex D for detailed protocol See Q.2957, Draft Q.2957 amendment 1, and Q.2971 annex D for detailed
specifications of the User-to-user Signaling. protocol specifications of the User-to-user Signaling.
4. Information Field and Protocol Identifier Assignment 4. Information Field and Protocol Identifier Assignment
4.1 Assignment in the Generic Identifier Information Element 4.1 Assignment in the Generic Identifier Information Element
4.1.1 Use of Generic Identifier 4.1.1 Use of Generic Identifier
The information field and protocol identifier assignment principle The information field and protocol identifier assignment principle
for the Internet protocol in the Generic Identifier information for the Internet protocol in the Generic Identifier information
element is shown in Fig. 4.1. element is shown in Fig. 4.1.
skipping to change at page 13, line 6 skipping to change at page 12, line 6
details.) details.)
To enable reliable Generic Identifier information element transfer, To enable reliable Generic Identifier information element transfer,
when the calling party sends a SETUP or ADD PARTY message with up to when the calling party sends a SETUP or ADD PARTY message with up to
three Generic Identifier information elements, the CONNECT or ADD three Generic Identifier information elements, the CONNECT or ADD
PARTY ACK message returned by the called party must contain at least PARTY ACK message returned by the called party must contain at least
one Generic Identifier information element. The called party may not one Generic Identifier information element. The called party may not
respond with the same identifiers received from the calling party. respond with the same identifiers received from the calling party.
The calling party should confirm that the response message contains The calling party should confirm that the response message contains
at least one Generic Identifier information element. at least one Generic Identifier information element. This rule
enables identifier negotiation; this document does not specify the
detailed procedure of this negotiation.
4.1.2 IPv4 session identifier 4.1.2 IPv4 session identifier
If the Identifier related standard/application field in the Generic If the Identifier related standard/application field in the Generic
Identifier information element is the IPv4, and the Identifier type Identifier information element is the IPv4, and the Identifier type
field in the identifier is the Session, the identifier is the IPv4 field in the identifier is the Session, the identifier is the IPv4
session identifier. The format of the IPv4 session identifier is session identifier. The format of the IPv4 session identifier is
shown in Fig. 4.2. shown in Fig. 4.2.
Bits Octet Bits Octet
skipping to change at page 13, line 43 skipping to change at page 12, line 45
| Destination Port | 2 | Destination Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.2: IPv4 session identifier. Fig. 4.2: IPv4 session identifier.
The Identifier type field is the Session (0x01). The Identifier type field is the Session (0x01).
The Identifier length is 13 octets. The Identifier length is 13 octets.
The Source IPv4 address, Destination IPv4 address, Protocol, Source The Source IPv4 address, Destination IPv4 address, Protocol, Source
Port, and Destination Port [6, 8, 9] are assigned in that order to Port, and Destination Port [7, 9, 10] are assigned in that order to
the Identifier value field. the Identifier value field.
Note: This specific session identifier is intended for use only with Note: This specific session identifier is intended for use only with
the explicit reservation. If wild card associations are needed at a the explicit reservation. If wild card associations are needed at a
later date, another identifier type will be used. later date, another identifier type will be used.
4.1.3 ST2+ session identifier 4.1.3 ST2+ session identifier
If the Identifier related standard/application field in the Generic If the Identifier related standard/application field in the Generic
Identifier information element is the ST2+, and the Identifier type Identifier information element is the ST2+, and the Identifier type
skipping to change at page 14, line 31 skipping to change at page 13, line 31
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| Stream ID (SID) | 6 | Stream ID (SID) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.3: ST2+ session identifier. Fig. 4.3: ST2+ session identifier.
The Identifier type field is the Session (0x01). The Identifier type field is the Session (0x01).
The Identifier length is 6 octets. The Identifier length is 6 octets.
The Stream ID (SID) [10] is assigned to the Identifier value field. The Stream ID (SID) [11] is assigned to the Identifier value field.
4.1.4 IPv6 session identifier 4.1.4 IPv6 session identifier
If the Identifier related standard/application field in the Generic If the Identifier related standard/application field in the Generic
Identifier information element is the IPv6, and the Identifier type Identifier information element is the IPv6, and the Identifier type
field in the identifier is the Session, the identifier is the IPv6 field in the identifier is the Session, the identifier is the IPv6
session identifier. The format of the IPv6 session identifier is session identifier. The format of the IPv6 session identifier is
shown in Fig. 4.4. shown in Fig. 4.4.
Bits Octet Bits Octet
skipping to change at page 15, line 40 skipping to change at page 14, line 40
| Destination Port | 2 | Destination Port | 2
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.4: IPv6 session identifier. Fig. 4.4: IPv6 session identifier.
The Identifier type field is the Session (0x01). The Identifier type field is the Session (0x01).
The Identifier length is 37 octets. The Identifier length is 37 octets.
The Source IPv6 address, Destination IPv6 address, Protocol, Source The Source IPv6 address, Destination IPv6 address, Protocol, Source
Port, and Destination Port [7, 8, 9] are assigned in that order to Port, and Destination Port [8, 9, 10] are assigned in that order to
the Identifier value field. the Identifier value field.
Note: This specific session identifier is intended for use only with Note: This specific session identifier is intended for use only with
the explicit reservation. If wild card associations are needed at a the explicit reservation. If wild card associations are needed at a
later date, another identifier type will be used. later date, another identifier type will be used.
4.1.5 MPLS VCID 4.1.5 MPLS VCID
If the Identifier related standard/application field in the Generic If the Identifier related standard/application field in the Generic
Identifier information element is the MPLS, and the Identifier type Identifier information element is the MPLS, and the Identifier type
skipping to change at page 16, line 30 skipping to change at page 15, line 30
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| MPLS VCID | 4 | MPLS VCID | 4
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.5: MPLS VCID. Fig. 4.5: MPLS VCID.
The Identifier type field is the Resource (0x02). The Identifier type field is the Resource (0x02).
The Identifier length is 4 octets. The Identifier length is 4 octets.
The MPLS VCID [12] is assigned to the Identifier value field. The MPLS VCID [13] is assigned to the Identifier value field.
4.1.6 Experiment/Organization specific 4.1.6 Experiment/Organization specific
If the Identifier related standard/application field in the Generic If the Identifier related standard/application field in the Generic
Identifier information element is the IPv4, ST2+, IPv6, or MPLS, and Identifier information element is the IPv4, ST2+, IPv6, or MPLS, and
the Identifier type field in the identifier is the the Identifier type field in the identifier is the
Experiment/Organization specific, the identifier is the Experiment/Organization specific, the identifier is the
Experiment/Organization specific. The format of the Experiment/Organization specific. The format of the
Experiment/Organization specific is shown in Fig. 4.6. Experiment/Organization specific is shown in Fig. 4.6.
skipping to change at page 19, line 25 skipping to change at page 18, line 25
element, or discards the signaling message. (See sections 4.5.1 and 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 5.6.8.1 of Q.2931, section 1.9 of Q.2957, and Q.2971 annex D for
details.) details.)
To enable reliable User-user information element transfer, when the To enable reliable User-user information element transfer, when the
calling party sends a SETUP or ADD PARTY message with a User-user calling party sends a SETUP or ADD PARTY message with a User-user
information element, the CONNECT or ADD PARTY ACK message returned by information element, the CONNECT or ADD PARTY ACK message returned by
the called party must contain a User-user information element. The the called party must contain a User-user information element. The
called party may not respond with the same user information received called party may not respond with the same user information received
from the calling party. The calling party should confirm that the from the calling party. The calling party should confirm that the
response message contains a User-user information element. 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 ST2+ SCMP 4.2.2 ST2+ SCMP
The format of the ST2+ SCMP is shown in Fig. 4.8. The format of the ST2+ SCMP is shown in Fig. 4.8.
Bits Bits
8 7 6 5 4 3 2 1 Octets 8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| Information element identifier | | Information element identifier |
| = User-user information element (0x7E) | 1 | = User-user information element (0x7E) | 1
skipping to change at page 20, line 36 skipping to change at page 19, line 36
| ST2+ SCMP | 7- | ST2+ SCMP | 7-
= = = =
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.8: ST2+ SCMP. Fig. 4.8: ST2+ SCMP.
The Internet protocol/application identifier field is the ST2+ SCMP The Internet protocol/application identifier field is the ST2+ SCMP
(0x01). (0x01).
The ST2+ SCMP [10] is assigned to the Internet protocol/application The ST2+ SCMP [11] is assigned to the Internet protocol/application
related information field. The SETUP and ADD PARTY messages may related information field. The SETUP and ADD PARTY messages may
contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY ACK contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY ACK
messages may contain the ST2+ SCMP ACCEPT message. The RELEASE and messages may contain the ST2+ SCMP ACCEPT message. The RELEASE and
DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message. DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message.
The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP PARTY The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP PARTY
messages may contain the ST2+ SCMP REFUSE message. messages may contain the ST2+ SCMP REFUSE message.
4.2.3 RSVP message 4.2.3 RSVP message
The format of the RSVP message is shown in Fig. 4.9. The format of the RSVP message is shown in Fig. 4.9.
skipping to change at page 21, line 36 skipping to change at page 20, line 36
| RSVP message | 7- | RSVP message | 7-
= = = =
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 4.9: RSVP message. Fig. 4.9: RSVP message.
The Internet protocol/application identifier field is the RSVP The Internet protocol/application identifier field is the RSVP
message (0x02). message (0x02).
The RSVP message [11] is assigned to the Internet The RSVP message [12] is assigned to the Internet
protocol/application related information field. The SETUP message protocol/application related information field. The SETUP message
may contain the RSVP Resv message. The CONNECT message may contain may contain the RSVP Resv message. The CONNECT message may contain
the RSVP ResvConf message. The RELEASE message may contain the RSVP the RSVP ResvConf message. The RELEASE message may contain the RSVP
ResvErr or ResvTear message. ResvErr or ResvTear message.
4.2.4 Experiment/Organization specific 4.2.4 Experiment/Organization specific
The format of the Experiment/Organization specific is shown in Fig. The format of the Experiment/Organization specific is shown in Fig.
4.10. 4.10.
skipping to change at page 24, line 10 skipping to change at page 23, line 10
1995. 1995.
[3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) [3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)
Digital Subscriber Signaling System No. 2 (DSS 2): Generic Digital Subscriber Signaling System No. 2 (DSS 2): Generic
Identifier Transport," Draft ITU-T New Recommendation Q.2941.1, Identifier Transport," Draft ITU-T New Recommendation Q.2941.1,
September 1997. September 1997.
[4] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) [4] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)
Digital Subscriber Signaling System No. 2 (DSS 2): Generic Digital Subscriber Signaling System No. 2 (DSS 2): Generic
Identifier Transport," Draft ITU-T New Recommendation Q.2941.2, Identifier Transport," Draft ITU-T New Recommendation Q.2941.2,
November 1998. (http://www.nal.ecl.net/SG11WP1/itu-t-sg11-tmp- March 1999.
doc-td87r2.ps)
[5] ITU-T, "Stage 3 Description for Additional Information [5] ITU-T, "Stage 3 Description for Additional Information
Transfer Supplementary Service Using B-ISDN Digital Subscriber Transfer Supplementary Service Using B-ISDN Digital Subscriber
Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User
Signalling (UUS)," Draft ITU-T New Recommendation Q.2957, November Signalling (UUS)," ITU-T Recommendation Q.2957, February 1995.
1998. (http://www.nal.ecl.net/SG11WP1/itu-t-sg11-tmp-doc-
td103.ps)
[6] J. Postel Ed., "Internet Protocol," RFC 791, September 1981. [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)," Draft ITU-T Recommendation Q.2957 Amendment 1,
March 1999.
[7] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) [7] J. Postel Ed., "Internet Protocol," RFC 791, September 1981.
[8] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification," RFC 2460, December 1998. Specification," RFC 2460, December 1998.
[8] J. Postel, "User Datagram Protocol," RFC 768, August 1980. [9] J. Postel, "User Datagram Protocol," RFC 768, August 1980.
[9] J. Postel Ed., "Transmission Control Protocol," RFC 793, [10] J. Postel Ed., "Transmission Control Protocol," RFC 793,
September 1981. September 1981.
[10] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol [11] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
August 1995. August 1995.
[11] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version [12] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version
1 Functional Specification," RFC 2205, September 1997. 1 Functional Specification," RFC 2205, September 1997.
[12] K. Nagami, N. Demizu, H. Esaki, Y. Katsube, and P. Doolan, [13] K. Nagami, N. Demizu, H. Esaki, Y. Katsube, and P. Doolan,
"VCID Notification over ATM link," Internet Draft, November 1998, "VCID Notification over ATM link," Internet Draft, December 1998,
<draft-ietf-mpls-vcid-atm-02.txt>. <draft-ietf-mpls-vcid-atm-02.txt>.
[13] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A [14] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A
Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996. Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996.
[14] S. Damaskos and A. Gavras, "Connection Oriented Protocols [15] S. Damaskos and A. Gavras, "Connection Oriented Protocols
over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278,
February 1994. February 1994.
[15] ITU-T, "Integrated Services Digital Network (ISDN) Overall [16] ITU-T, "Integrated Services Digital Network (ISDN) Overall
Network Aspects and Functions ISDN Protocol Reference Model," Network Aspects and Functions ISDN Protocol Reference Model,"
ITU-T Recommendation I.320, November 1993. ITU-T Recommendation I.320, November 1993.
[16] ITU-T, "Digital Subscriber Signaling System No. 1 (DSS 1) [17] ITU-T, "Digital Subscriber Signaling System No. 1 (DSS 1)
Specification of a Synchronization and Coordination Function for Specification of a Synchronization and Coordination Function for
the Provision of the OSI Connection-mode Network Service in an the Provision of the OSI Connection-mode Network Service in an
ISDN Environment," ITU-T Recommendation Q.923, February 1995. ISDN Environment," ITU-T Recommendation Q.923, February 1995.
[17] K. Kitami, "Proposed Direction for B-ISDN & Multimedia
Signaling," ITU-T SG11 Delayed Contribution D.647, January 1998,
(http://www.nal.ecl.net/SG11WP1/itu-t-sg11-del-contrib-d647.ps).
Acknowledgments Acknowledgments
I would like to thank Kenichi Kitami of the NTT Network Innovation I would like to thank Kenichi Kitami of the NTT Information
Planning and Promotion Dept., who is also the chair of ITU-T SG11 Sharing Lab. Group, who is also the chair of ITU-T SG11 WP1,
WP1, Shinichi Kuribayashi, Hiroshi Yao, and Takumi Ohba of the NTT Shinichi Kuribayashi of the NTT Information Sharing Platform
Network Service Systems Labs., and Noriyuki Takahashi of the NTT Labs., Hiroshi Yao and Takumi Ohba of the NTT Network Service
Multimedia Networks Labs. for their valuable comments and Systems Labs., and Noriyuki Takahashi of the NTT Information
Sharing Platform Labs., for their valuable comments and
discussions. discussions.
And I would also like to thank the active members of IETF, ITU-T, And I would also like to thank the active members of IETF, ITU-T,
and ATM Forum, especially Joel Halpern of Newbridge Networks, and ATM Forum, especially Joel Halpern of Newbridge Networks,
Andrew Malis of Ascend Communications, George Swallow and Bruce Andrew Malis of Ascend Communications, George Swallow and Bruce
Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of
AT&T, Greg Ratta of Lucent, Kaoru Kenyoshi of NEC, Hiroshi Esaki AT&T, Greg Ratta of Lucent, Kaoru Kenyoshi of NEC, Hiroto Uno of
and Kenichi Nagami of Toshiba, and Noritoshi Demizu of NAIST for Hitachi, Hiroshi Esaki and Kenichi Nagami of Toshiba, and
their valuable comments and suggestions. Noritoshi Demizu of NAIST for their valuable comments and
suggestions.
Also this specification is based on various discussions during the Also this specification is based on various discussions during the
ST2+ over ATM project at the NTT Multimedia Joint Project with ST2+ over ATM project at the NTT Multimedia Joint Project with
NACSIS. I would like to thank Professor Shoichiro Asano of the NACSIS. I would like to thank Professor Shoichiro Asano of the
National Center for Science Information Systems for his invaluable National Center for Science Information Systems for his invaluable
advice in this area. advice in this area.
Author's Address Author's Address
Muneyoshi Suzuki Muneyoshi Suzuki
NTT Multimedia Networks Laboratories NTT Information Sharing Platform Laboratories
3-9-11, Midori-cho 3-9-11, Midori-cho
Musashino-shi, Tokyo 180-8585, Japan Musashino-shi, Tokyo 180-8585, Japan
Phone: +81-422-59-2119 Phone: +81-422-59-2119
Fax: +81-422-59-2829 Fax: +81-422-59-3203
EMail: suzuki@nal.ecl.net EMail: suzuki@nal.ecl.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/