idnits 2.17.1 draft-ietf-mpls-git-uus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 1998) is 9427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 914, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 926, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 937, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 964, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 967, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 971, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 980, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 793 (ref. '9') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Muneyoshi Suzuki 2 INTERNET DRAFT NTT 3 Expires December 29, 1998 June 29, 1998 5 The Assignment of the Information Field and Protocol Identifier 6 in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling 7 for the Internet Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 The purpose of this document is to specify the assignment of the 32 information field and protocol identifier in the Q.2941 Generic 33 Identifier and Q.2957 User-to-user Signaling for the Internet 34 protocol. 36 The assignment, that is specified in section 4 of this document, is 37 designed for advanced B-ISDN signaling support of the Internet 38 protocol, especially the B-ISDN signaling support for the connection 39 that corresponds to the session in the Internet protocol which is 40 clarified in section 2. This specification provides an indispensable 41 framework for the implementation of long-lived session and QoS- 42 sensitive session transfers over ATM. 44 0. Background 46 In the ITU-T SG11 WP1 Kochi meeting held in January 1998, SG11 WP1, 47 which has responsibility for the B-ISDN signaling protocol 48 recommendation, decided to discuss B-ISDN signalling support for the 49 Internet protocol based on draft-suzuki-git-uus-assignment-00.txt. 51 In the ITU-T SG11 Geneva meeting held in May 1998, WP1 decided to 52 enhance the Q.2941 Generic Identifier Transport based on draft- 53 suzuki-git-uus-assignment-02.txt and developed the Awaiting-review 54 text (initial draft) [4]. WP1 also decided to continue discussion on 55 the User-to-user signaling support for the Internet protocol. 56 Expected standard development process (fastest case) for the 57 enhancement of the Generic Identifier is: 59 November 1998: Enhance the Awaiting-review text based on inputs and 60 develop the Cooling text (Draft Recommendations to be frozen in the 61 next meeting, if no significant technical changes are proposed in 62 that meeting). 64 March 1999: Freeze the Draft Recommendations and letter ballot is 65 requested. 67 February 2000: The Draft Recommendations are decided (final 68 approval). 70 The purpose of this document is to specify the assignment of the 71 information field and protocol identifier in the Q.2941 Generic 72 Identifier and Q.2957 User-to-user Signaling for the Internet 73 protocol. To enable this specification, section 6 of this document 74 clarifies amendments to the current User-to-user Signaling. ITU-T 75 SG11 will enhance the current User-to-user Signaling based on this 76 clarification. 78 Note that the assignment rule for Generic Identifer described in this 79 document may be subject to change. 81 Note that the assignment rule for the User-to-user Signaling 82 described in this document may be subject to change, so it should not 83 be implemented until ITU-T SG11 WP1 decides to enhance the User-to- 84 user Signaling based on this request. 86 1. Purpose of Document 88 The purpose of this document is to specify the assignment of the 89 information field and protocol identifier in the Q.2941 Generic 90 Identifier and Q.2957 User-to-user Signaling for the Internet 91 protocol. 93 The assignment, that is specified in section 4 of this document, is 94 designed for advanced B-ISDN signaling support of the Internet 95 protocol, especially the B-ISDN signaling support for the connection 96 that corresponds to the session in the Internet protocol which is 97 clarified in section 2. Needless to say, the purpose of this 98 specification is not limited to this support, and it should also be 99 applicable to other purposes. 101 This specification provides an indispensable framework for the 102 implementation of long-lived session and QoS-sensitive session 103 transfers over ATM. Note that this document only specifies the 104 assignment of the information field and protocol identifier, and that 105 it may not specify complete protocol that enables interoperable 106 implementation. This is because it is beyond the scope of this 107 document and will be specified in a separate document. 109 2. Session-related ATM Connection 111 With the development of new multimedia applications on the current 112 Internet, the demands for multimedia support are increasing in the IP 113 network, which currently supports best effort communications. In 114 particular, demands to support QoS guaranteed communications are 115 increasing with the development of voice, audio, and video 116 communications applications. And it may also be necessary to 117 introduce the mechanism that can efficiently transfer the huge volume 118 of traffic expected with these applications. 120 The major features of B-ISDN are high speed, logical multiplexing 121 with the VP/VC, and flexible QoS management per VC, so it is quite 122 natural to use these distinctive functions of B-ISDN to implement a 123 multimedia support mechanism in the IP network. The flexible QoS 124 management and logical multiplexing functions in B-ISDN are the 125 expected method of implementing the QoS guaranteed communications in 126 the Internet. And when a long-lived session is supported by a 127 particular VC, efficient packet forwarding may be possible using the 128 high speed and logical multiplexing of B-ISDN. 130 This section clarifies B-ISDN signaling functions that are required 131 when the session is supported by the VC, for advanced B-ISDN 132 signaling support of the Internet protocol. 134 2.1 Long-lived Session Signaling 136 An example scenario for establishing a VC for a long-lived session is 137 shown in Fig. 2.1. 139 IP Router ATM SW ATM SW IP Router 140 +----+ Default VC +----+ 141 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 142 +--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+ 143 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 144 | | | / \ | | / \ | | | 145 +------+ +-----+ +-----+ +------+ 147 A. New session initially forwarded over a default VC. 149 IP Router ATM SW ATM SW IP Router 150 +----+ Default VC +----+ 151 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 152 +--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+ 153 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 154 | |<------+-/-\-+--------+-/-\-+------>| | 155 +------+ +-----+ +-----+ +------+ 156 New VC is set up 158 B. New VC is set up for the long-lived session. 160 IP Router ATM SW ATM SW IP Router 161 +----+ Default VC +----+ 162 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 163 +--+-+ | |<------+-\-/-+--------+-\-/-+------>| | +-+--+ 164 |.....|__ |===||==| X |========| X |==||===| __|.....| 165 | \-->|<------+-/-\-+--------+-/-\-+------>|<--/ | 166 +------+ +-----+ +-----+ +------+ 167 New VC 169 C. Transfer of the long-lived session to a new VC. 171 Fig. 2.1: Example scenario for establishing a VC for a long-lived session. 173 First, a session is multiplexed into the default VC connecting the 174 routers. Then, if a router detects that it is a long-lived session, 175 it sets up a new VC for the session. If the new VC is established 176 successfully, the long-lived session is moved to the new VC. 178 In this procedure involving an ATM VC setup, the B-ISDN signaling 179 entity in the called side router must detect that the incoming call 180 corresponds to a session of the Internet protocol and notify that 181 fact to the IP layer entity. Based on this information, the IP layer 182 entity moves the session to the new VC. 184 Therefore, to implement this signaling procedure, the B-ISDN 185 signaling must include an session identifier as an information 186 element. The B-LLI, B-HLI, User-user, and Generic Identifier 187 information elements are all capable of transferring this 188 information. Considering the original purposes of these information 189 elements, the most appropriate one to use is the Generic Identifier 190 information element. 192 2.2 QoS-sensitive Session Signaling 194 The major difference between QoS-sensitive session signaling and 195 long-lived session signaling is that call setup is not initiated by 196 the detection of a long-lived session, but is explicitly initiated by 197 the setup protocol such as ST2+ and RSVP. To implement QoS-sensitive 198 session signaling using ATM, the ATM network between the routers must 199 forward not only the session identifier but also the setup protocol. 201 There are two schemes for forwarding the setup protocol. One is to 202 multiplex the protocol into a default VC connecting the routers, or 203 to forward the protocol through a particular VC. In this case, the 204 QoS-sensitive session and the ATM VC are established sequentially. 205 The second scheme is to forward the setup protocol as an information 206 element in the B-ISDN signaling. In this case, the QoS-sensitive 207 session and the ATM VC are established simultaneously. The latter 208 scheme has the following advantages compared with the former one. 210 o Easier to implement. 212 - Admission control is simplified, because admission control for 213 the IP and ATM layers can be done simultaneously. 215 - Watchdog timer processing is simplified, because there is no need 216 to watch the IP layer establishment and ATM layer establishment 217 sequentially. 219 o If the setup protocol supports negotiation, then an ATM VC whose 220 QoS is based on the result of negotiation can be established. 222 However, the latter scheme, at least, cannot support a case where a 223 PVC is used to support a QoS-sensitive session. Therefore, both 224 procedures should be taken into account. 226 An example of a message sequence that simultaneously establishes a 227 QoS-sensitive session and an ATM VC is shown in Fig. 2.2. 229 IP Router ATM SW ATM SW IP Router 230 +----+ B-ISDN Signaling +----+ 231 | WS | +------+ UNI +-----+ Setup +-----+ UNI +------+ | WS | 232 +--+-+ | /->|<------+-\-/--Protocol--\-/-+------>|<-\ | +-+--+ 233 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 234 | \-->|<------+-/-\-+--------+-/-\-+------>|<--/ | 235 +------+ +-----+ Data +-----+ +------+ 236 QoS VC 237 N-CONNECT | | 238 ---------->| | | | | | 239 |->| SETUP | | | | 240 | |------------>| | | | 241 | |<------------| | | | 242 | | CALL PROC |----------->| SETUP | | 243 | | | |------------>| | 244 | | | | |->| N-CONNECT 245 | | | | | |----------> 246 | | | | | |<---------- 247 | | | | CONN |<-| N-CONNECT-ACK 248 | | | |<------------| | 249 | | | |------------>| | 250 | | CONN |<-----------| CONN ACK |->| 251 | |<------------| | | | 252 | |------------>| | | | 253 |<-| CONN ACK | | | | 254 <----------| | | | | | 255 N-CONNECT | | 256 -ACK 258 Fig. 2.2: Example procedure for simultaneous QoS-sensitive session and 259 ATM VC establishment. 261 Both ST2+ and RSVP are currently proposed for the setup protocol and 262 new setup protocols are likely to be developed in the near future. 263 Therefore, to generalize the discussion, the procedure for the setup 264 protocol in this example is the general connection setup procedure 265 using confirmed service. 267 To implement this signaling procedure, the B-ISDN signaling must 268 include the User-user information element that the capacity is 269 sufficient to forward the setup protocol. 271 3. Overview of the Generic Identifier and User-to-user Signaling 273 3.1 Overview of the Generic Identifier 275 The Generic Identifier enables the transfer of identifiers between 276 end-to-end users in the ATM network, and it is defined in the Q.2941 277 Part 1 (Q.2941.1) and Part 2 (Q.2941.2) as an optional information 278 element for the Q.2931 and Q.2971 UNI signaling protocol. The SETUP, 279 ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, ADD PARTY, PARTY 280 ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY 281 ACK messages that are transferred between end-to-end users in the ATM 282 network may contain up to three Generic Identifier information 283 elements. The ATM network transfers the Generic Identifier 284 information element transparently if it contains no coding rule 285 errors. 287 The format of the Generic Identifier information element specified in 288 the Q.2941 is shown in Fig. 3.1. 290 Bits 291 8 7 6 5 4 3 2 1 Octets 292 +-----+-----+-----+-----+-----+-----+-----+-----+ 293 | Information element identifier | 294 | = Generic identifier transport IE (0x7F) | 1 295 +-----+-----+-----+-----+-----+-----+-----+-----+ 296 | 1 | Coding | IE instruction field | 297 | Ext | standard |Flag |Res. | IE action ind. | 2 298 +-----+-----+-----+-----+-----+-----+-----+-----+ 299 | Length of contents of information element | 3-4 300 +-----+-----+-----+-----+-----+-----+-----+-----+ 301 | Identifier related standard/application | 5 302 +-----+-----+-----+-----+-----+-----+-----+-----+ 303 | Identifier type | 6 304 +-----+-----+-----+-----+-----+-----+-----+-----+ 305 | Identifier length | 7 306 +-----+-----+-----+-----+-----+-----+-----+-----+ 307 | Identifier value | 8- 308 = = 309 +-----+-----+-----+-----+-----+-----+-----+-----+ 310 = = 311 +-----+-----+-----+-----+-----+-----+-----+-----+ 312 | Identifier type | 313 +-----+-----+-----+-----+-----+-----+-----+-----+ 314 | Identifier length | 315 +-----+-----+-----+-----+-----+-----+-----+-----+ 316 | Identifier value | 317 = = 318 +-----+-----+-----+-----+-----+-----+-----+-----+ 320 Fig. 3.1: Format of the Generic Identifier information element. 322 The usage of the first 4 octets of fields is specified in section 4 323 of the Q.2931. 325 The Identifier related standard/application field identifies the 326 standard or application that uses the identifier. Assignment of the 327 Identifier related standard/application field for the Intenet 328 protocol is as follows. A leading 0x means hexadecimal. 330 0x03: IPv4. 332 0x04: ST2+. 334 0x05: IPv6. 336 0x06: MPLS. 338 Note: DSM-CC, H.310/H.321, and AAL2 application are also supported. 340 A transferred identifier is given by the combination of the 341 Identifier type, length and value fields, and a Generic Identifier 342 information element may contain multiple identifiers. 344 Assignment of the Identifier type field for the Intenet protocol is 345 as follows. A leading 0x means hexadecimal. 347 0x01: Session. 349 0x02: Resource. 351 0x03-0xFD: Reserved for IANA assignment. 353 0xFE: Experiment/Organization specific. 355 The maximum length of the Generic Identifier information element is 356 63 octets. (See Draft Q.2941.2.) 358 See the Q.2941.1 and Draft Q.2941.2 for detailed protocol 359 specifications of the Generic Identifier. 361 3.2 Overview of the User-to-user Signaling 363 The User-to-user Signaling enables the transfer of information 364 between end-to-end users in the ATM network, and it is defined in 365 Q.2957 and in Q.2971 annex D as an optional information element for 366 the Q.2931 and Q.2971 UNI signaling protocol. The SETUP, ALERTING, 367 CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS, ADD PARTY, PARTY 368 ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, and DROP PARTY 369 ACK messages that are transferred between end-to-end users in the ATM 370 network may contain a User-user information element. The ATM network 371 transfers the User-user information element transparently if it 372 contains no coding rule errors. 374 From the viewpoint of B-ISDN signaling applications, it seems the 375 Generic Identifier and User-to-user Signaling are similar functions. 376 But their rules for processing exceptions are not completely the 377 same, because their purposes are different. The Generic Identifier is 378 designed for the transfer of identifiers between the c-planes, while 379 the User-to-user Signaling is designed for the transfer of user data 380 via the c-planes. Another difference is that the latter supports 381 interworking with the user-user information element in the Q.931 N- 382 ISDN signaling, but the Generic Identifier does not. Note that the 383 ATM network may check the contents of the Generic Identifier 384 information element, but does not check the contents of the User-to- 385 user information element. 387 The format of the User-user information element is shown in Fig. 3.2. 389 Bits 390 8 7 6 5 4 3 2 1 Octets 391 +-----+-----+-----+-----+-----+-----+-----+-----+ 392 | Information element identifier | 393 | = User-user information element (0x7E) | 1 394 +-----+-----+-----+-----+-----+-----+-----+-----+ 395 | 1 | Coding | IE instruction field | 396 | Ext | standard |Flag |Res. | IE action ind. | 2 397 +-----+-----+-----+-----+-----+-----+-----+-----+ 398 | Length of contents of information element | 3-4 399 +-----+-----+-----+-----+-----+-----+-----+-----+ 400 | Protocol discriminator | 5 401 +-----+-----+-----+-----+-----+-----+-----+-----+ 402 | User information | 6- 403 = = 404 | | 405 +-----+-----+-----+-----+-----+-----+-----+-----+ 407 Fig. 3.2: Format of the User-user information element. 409 The usage of the first 4 octets of fields is specified in section 4 410 of the Q.2931. 412 The Protocol discriminator field identifies the upper layer protocol 413 that uses the user-user information. 415 The User information field contains the user-user information to be 416 transferred. 418 The maximum length of the User-user information element is currently 419 133 octets. 421 See Q.2957 and Q.2971 annex D for detailed protocol specifications of 422 the User-to-user Signaling. 424 4. Information Field and Protocol Identifier Assignment 426 4.1 Assignment in the Generic Identifier Information Element 428 4.1.1 Use of Generic Identifier 430 The information field and protocol identifier assignment principle 431 for the Internet protocol in the Generic Identifier information 432 element is shown in Fig. 4.1. 434 Bits 435 8 7 6 5 4 3 2 1 Octets 436 +-----+-----+-----+-----+-----+-----+-----+-----+ 437 | Information element identifier | 438 | = Generic identifier transport IE (0x7F) | 1 439 +-----+-----+-----+-----+-----+-----+-----+-----+ 440 | 1 | Coding | IE instruction field | 441 | Ext | standard |Flag |Res. | IE action ind. | 2 442 +-----+-----+-----+-----+-----+-----+-----+-----+ 443 | Length of contents of information element | 3-4 444 +-----+-----+-----+-----+-----+-----+-----+-----+ 445 | Identifier related standard/application | 446 | = IPv4, ST2+, IPv6, or MPLS | 5 447 +-----+-----+-----+-----+-----+-----+-----+-----+ 448 | Identifier type | 449 | = Session, Resource, or Experiment | 6 450 +-----+-----+-----+-----+-----+-----+-----+-----+ 451 | Identifier length | 7 452 +-----+-----+-----+-----+-----+-----+-----+-----+ 453 | Identifier value | 8- 454 = = 455 +-----+-----+-----+-----+-----+-----+-----+-----+ 456 = = 457 +-----+-----+-----+-----+-----+-----+-----+-----+ 458 | Identifier type | 459 | = Session, Resource, or Experiment | 460 +-----+-----+-----+-----+-----+-----+-----+-----+ 461 | Identifier length | 462 +-----+-----+-----+-----+-----+-----+-----+-----+ 463 | Identifier value | 464 = = 465 +-----+-----+-----+-----+-----+-----+-----+-----+ 467 Fig. 4.1: Principle of assignment in the Generic Identifier 468 information element. 470 The Identifier related standard/application field is the IPv4, ST2+, 471 IPv6, or MPLS. 473 The Identifier type field is the Session, Resource, or 474 Experiment/Organization specific. 476 The Identifier value field is assigned to Internet protocol related 477 information which is identified by the Identifier related 478 standard/application field and Identifier type field. The following 479 identifiers are specified. 481 Std./app. Id type 483 IPv4 session identifier IPv4 Session 485 ST2+ session identifier ST2+ Session 487 IPv6 session identifier IPv6 Session 489 MPLS VCID MPLS Resource 491 Exp./Org. specific IPv4/ST2+/IPv6/MPLS Experiment 493 As described in section 3.1, the B-ISDN signaling message transferred 494 between end-to-end users may contain up to three Generic Identifier 495 information elements. These elements may contain multiple 496 identifiers. This document does not specify the order of identifiers 497 when multiple identifiers appear in a signaling message. 499 This document also does not specify the semantics when multiple 500 identifiers having the same Identifier type appear in a signaling 501 message, or when a signaling message contains a Generic Identifier 502 information element that does not contain identifiers. 504 When a B-ISDN signaling message containing a Generic Identifier 505 information element enters an ATM network that does not support the 506 Generic Identifier, the network clears the call, discards the 507 information element, or discards the signaling message. (See 508 sections 4.5.1 and 5.6.8.1 of Q.2931 and section 9.3 of Q.2941.1 for 509 details.) 511 To enable reliable Generic Identifier information element transfer, 512 when the calling party sends a SETUP or ADD PARTY message with up to 513 three Generic Identifier information elements, the CONNECT or ADD 514 PARTY ACK message returned by the called party must contain at least 515 one Generic Identifier information element. The called party may not 516 respond with the same identifiers received from the calling party. 518 The calling party should confirm that the response message contains 519 at least one Generic Identifier information element. 521 4.1.2 IPv4 session identifier 523 If the Identifier related standard/application field in the Generic 524 Identifier information element is the IPv4, and the Identifier type 525 field in the identifier is the Session, the identifier is the IPv4 526 session identifier. The format of the IPv4 session identifier is 527 shown in Fig. 4.2. 529 Bits Octet 530 8 7 6 5 4 3 2 1 length 531 +-----+-----+-----+-----+-----+-----+-----+-----+ 532 | Identifier type | 533 | = Session (0x01) | 1 534 +-----+-----+-----+-----+-----+-----+-----+-----+ 535 | Identifier length | 536 | = 13 octets (0x0D) | 1 537 +-----+-----+-----+-----+-----+-----+-----+-----+ 538 | Source IPv4 address | 4 539 +-----+-----+-----+-----+-----+-----+-----+-----+ 540 | Destination IPv4 address | 4 541 +-----+-----+-----+-----+-----+-----+-----+-----+ 542 | Protocol | 1 543 +-----+-----+-----+-----+-----+-----+-----+-----+ 544 | Source Port | 2 545 +-----+-----+-----+-----+-----+-----+-----+-----+ 546 | Destination Port | 2 547 +-----+-----+-----+-----+-----+-----+-----+-----+ 549 Fig. 4.2: IPv4 session identifier. 551 The Identifier type field is the Session (0x01). 553 The Identifier length is 13 octets. 555 The Source IPv4 address, Destination IPv4 address, Protocol, Source 556 Port, and Destination Port [6, 8, 9] are assigned in that order to 557 the Identifier value field. 559 Note: This specific session identifier is intended for use only with 560 the explicit reservation. If wild card associations are needed at a 561 later date, another identifier type will be used. 563 4.1.3 ST2+ session identifier 565 If the Identifier related standard/application field in the Generic 566 Identifier information element is the ST2+, and the Identifier type 567 field in the identifier is the Session, the identifier is the ST2+ 568 session identifier. The format of the ST2+ session identifier is 569 shown in Fig. 4.3. 571 Bits Octet 572 8 7 6 5 4 3 2 1 Length 573 +-----+-----+-----+-----+-----+-----+-----+-----+ 574 | Identifier type | 575 | = Session (0x01) | 1 576 +-----+-----+-----+-----+-----+-----+-----+-----+ 577 | Identifier length | 578 | = 6 octets (0x06) | 1 579 +-----+-----+-----+-----+-----+-----+-----+-----+ 580 | Stream ID (SID) | 6 581 +-----+-----+-----+-----+-----+-----+-----+-----+ 583 Fig. 4.3: ST2+ session identifier. 585 The Identifier type field is the Session (0x01). 587 The Identifier length is 6 octets. 589 The Stream ID (SID) [10] is assigned to the Identifier value field. 591 4.1.4 IPv6 session identifier 593 If the Identifier related standard/application field in the Generic 594 Identifier information element is the IPv6, and the Identifier type 595 field in the identifier is the Session, the identifier is the IPv6 596 session identifier. The format of the IPv6 session identifier is 597 shown in Fig. 4.4. 599 Bits Octet 600 8 7 6 5 4 3 2 1 length 601 +-----+-----+-----+-----+-----+-----+-----+-----+ 602 | Identifier type | 603 | = Session (0x01) | 1 604 +-----+-----+-----+-----+-----+-----+-----+-----+ 605 | Identifier length | 606 | = 37 octets (0x25) | 1 607 +-----+-----+-----+-----+-----+-----+-----+-----+ 608 | Source IPv6 address | 16 609 +-----+-----+-----+-----+-----+-----+-----+-----+ 610 | Destination IPv6 address | 16 611 +-----+-----+-----+-----+-----+-----+-----+-----+ 612 | Protocol | 1 613 +-----+-----+-----+-----+-----+-----+-----+-----+ 614 | Source Port | 2 615 +-----+-----+-----+-----+-----+-----+-----+-----+ 616 | Destination Port | 2 617 +-----+-----+-----+-----+-----+-----+-----+-----+ 619 Fig. 4.4: IPv6 session identifier. 621 The Identifier type field is the Session (0x01). 623 The Identifier length is 37 octets. 625 The Source IPv6 address, Destination IPv6 address, Protocol, Source 626 Port, and Destination Port [7, 8, 9] are assigned in that order to 627 the Identifier value field. 629 Note: This specific session identifier is intended for use only with 630 the explicit reservation. If wild card associations are needed at a 631 later date, another identifier type will be used. 633 4.1.5 MPLS VCID 635 If the Identifier related standard/application field in the Generic 636 Identifier information element is the MPLS, and the Identifier type 637 field in the identifier is the Resource, the identifier is the MPLS 638 VCID. The format of the MPLS VCID is shown in Fig. 4.5. 640 Bits Octet 641 8 7 6 5 4 3 2 1 length 642 +-----+-----+-----+-----+-----+-----+-----+-----+ 643 | Identifier type | 644 | = Resource (0x02) | 1 645 +-----+-----+-----+-----+-----+-----+-----+-----+ 646 | Identifier length | 647 | = 4 octets (0x04) | 1 648 +-----+-----+-----+-----+-----+-----+-----+-----+ 649 | MPLS VCID | 4 650 +-----+-----+-----+-----+-----+-----+-----+-----+ 652 Fig. 4.5: MPLS VCID. 654 The Identifier type field is the Resource (0x02). 656 The Identifier length is 4 octets. 658 The MPLS VCID [12] is assigned to the Identifier value field. 660 4.1.6 Experiment/Organization specific 662 If the Identifier related standard/application field in the Generic 663 Identifier information element is the IPv4, ST2+, IPv6, or MPLS, and 664 the Identifier type field in the identifier is the 665 Experiment/Organization specific, the identifier is the 666 Experiment/Organization specific. The format of the 667 Experiment/Organization specific is shown in Fig. 4.6. 669 Bits Octet 670 8 7 6 5 4 3 2 1 length 671 +-----+-----+-----+-----+-----+-----+-----+-----+ 672 | Identifier type | 673 | = Experiment/Organization specific (0xFE) | 1 674 +-----+-----+-----+-----+-----+-----+-----+-----+ 675 | Identifier length | 1 676 +-----+-----+-----+-----+-----+-----+-----+-----+ 677 | Organizationally unique identifier (OUI) | 3 678 +-----+-----+-----+-----+-----+-----+-----+-----+ 679 | Experiment/Organization specific info. | 680 = = 681 | | 682 +-----+-----+-----+-----+-----+-----+-----+-----+ 684 Fig. 4.6: Experiment/Organization specific. 686 The Identifier type field is the Experiment/Organization specific 687 (0xFE). 689 The first 3 octets in the Identifier value field must contain the 690 Organizationally unique identifier (OUI) (as specified in IEEE 802- 691 1990; section 5.1). 693 4.2 Assignment in the User-user Information Element 695 4.2.1 Use of User-to-user Signaling 697 The information field and protocol identifier assignment principle 698 for the Internet protocol in the User-user information element is 699 shown in Fig. 4.7. 701 Bits 702 8 7 6 5 4 3 2 1 Octets 703 +-----+-----+-----+-----+-----+-----+-----+-----+ 704 | Information element identifier | 705 | = User-user information element (0x7E) | 1 706 +-----+-----+-----+-----+-----+-----+-----+-----+ 707 | 1 | Coding | IE instruction field | 708 | Ext | standard |Flag |Res. | IE action ind. | 2 709 +-----+-----+-----+-----+-----+-----+-----+-----+ 710 | Length of contents of information element | 3-4 711 +-----+-----+-----+-----+-----+-----+-----+-----+ 712 | Protocol discriminator | 713 | = Internet protocol/application (TBD) | 5 714 +-----+-----+-----+-----+-----+-----+-----+-----+ 715 | Internet protocol/application identifier | 6 716 +-----+-----+-----+-----+-----+-----+-----+-----+ 717 | Internet protocol/application related info. | 7- 718 = = 719 | | 720 +-----+-----+-----+-----+-----+-----+-----+-----+ 722 Fig. 4.7: Principle of assignment in the User-user information element. 724 The Protocol discriminator field is the Internet protocol/application 725 (TBD). In this case, the first 1 octet in the User information field 726 is the Internet protocol/application identifier field. 728 Assignment of the Internet protocol/application identifier field is 729 as follows. A leading 0x means hexadecimal. 731 0x00: Reserved. 733 0x01: ST2+ SCMP. 735 0x02: RSVP message. 737 0x03-0xFD: Reserved for IANA assignment. 739 0xFE: Experiment/Organization specific. 741 0xFF: Reserved. 743 The field that follows the Internet protocol/application identifier 744 field is assigned to Internet protocol/application related 745 information that is identified by the Internet protocol/application 746 identifier field. 748 4.2.2 ST2+ SCMP 750 The format of the ST2+ SCMP is shown in Fig. 4.8. 752 Bits 753 8 7 6 5 4 3 2 1 Octets 754 +-----+-----+-----+-----+-----+-----+-----+-----+ 755 | Information element identifier | 756 | = User-user information element (0x7E) | 1 757 +-----+-----+-----+-----+-----+-----+-----+-----+ 758 | 1 | Coding | IE instruction field | 759 | Ext | standard |Flag |Res. | IE action ind. | 2 760 +-----+-----+-----+-----+-----+-----+-----+-----+ 761 | Length of contents of information element | 3-4 762 +-----+-----+-----+-----+-----+-----+-----+-----+ 763 | Protocol discriminator | 764 | = Internet protocol/application (TBD) | 5 765 +-----+-----+-----+-----+-----+-----+-----+-----+ 766 | Internet protocol/application identifier | 767 | = ST2+ SCMP (0x01) | 6 768 +-----+-----+-----+-----+-----+-----+-----+-----+ 769 | ST2+ SCMP | 7- 770 = = 771 | | 772 +-----+-----+-----+-----+-----+-----+-----+-----+ 774 Fig. 4.8: ST2+ SCMP. 776 The Internet protocol/application identifier field is the ST2+ SCMP 777 (0x01). 779 The ST2+ SCMP [10] is assigned to the Internet protocol/application 780 related information field. The SETUP and ADD PARTY messages may 781 contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY ACK 782 messages may contain the ST2+ SCMP ACCEPT message. The RELEASE and 783 DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message. 784 The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP PARTY 785 messages may contain the ST2+ SCMP REFUSE message. 787 4.2.3 RSVP message 789 The format of the RSVP message is shown in Fig. 4.9. 791 Bits 792 8 7 6 5 4 3 2 1 Octets 793 +-----+-----+-----+-----+-----+-----+-----+-----+ 794 | Information element identifier | 795 | = User-user information element (0x7E) | 1 796 +-----+-----+-----+-----+-----+-----+-----+-----+ 797 | 1 | Coding | IE instruction field | 798 | Ext | standard |Flag |Res. | IE action ind. | 2 799 +-----+-----+-----+-----+-----+-----+-----+-----+ 800 | Length of contents of information element | 3-4 801 +-----+-----+-----+-----+-----+-----+-----+-----+ 802 | Protocol discriminator | 803 | = Internet protocol/application (TBD) | 5 804 +-----+-----+-----+-----+-----+-----+-----+-----+ 805 | Internet protocol/application identifier | 806 | = RSVP message (0x02) | 6 807 +-----+-----+-----+-----+-----+-----+-----+-----+ 808 | RSVP message | 7- 809 = = 810 | | 811 +-----+-----+-----+-----+-----+-----+-----+-----+ 813 Fig. 4.9: RSVP message. 815 The Internet protocol/application identifier field is the RSVP 816 message (0x02). 818 The RSVP message [11] is assigned to the Internet 819 protocol/application related information field. The SETUP message 820 may contain the RSVP Resv message. The CONNECT message may contain 821 the RSVP ResvConf message. The RELEASE message may contain the RSVP 822 ResvErr or ResvTear message. 824 4.2.4 Experiment/Organization specific 826 The format of the Experiment/Organization specific is shown in Fig. 827 4.10. 829 Bits 830 8 7 6 5 4 3 2 1 Octets 831 +-----+-----+-----+-----+-----+-----+-----+-----+ 832 | Information element identifier | 833 | = User-user information element (0x7E) | 1 834 +-----+-----+-----+-----+-----+-----+-----+-----+ 835 | 1 | Coding | IE instruction field | 836 | Ext | standard |Flag |Res. | IE action ind. | 2 837 +-----+-----+-----+-----+-----+-----+-----+-----+ 838 | Length of contents of information element | 3-4 839 +-----+-----+-----+-----+-----+-----+-----+-----+ 840 | Protocol discriminator | 841 | = Internet protocol/application (TBD) | 5 842 +-----+-----+-----+-----+-----+-----+-----+-----+ 843 | Internet protocol/application identifier | 844 | = Experiment/Organization specific (0xFE) | 6 845 +-----+-----+-----+-----+-----+-----+-----+-----+ 846 | Organizationally unique identifier (OUI) | 7-9 847 +-----+-----+-----+-----+-----+-----+-----+-----+ 848 | Experiment/Organization specific info. | 10- 849 = = 850 | | 851 +-----+-----+-----+-----+-----+-----+-----+-----+ 853 Fig. 4.10: Experiment/Organization specific. 855 The Internet protocol/application identifier field is the 856 Experiment/Organization specific (0xFE). 858 The first 3 octets in the Internet protocol/application related 859 information field must contain the Organizationally unique identifier 860 (OUI) (as specified in IEEE 802-1990; section 5.1). 862 5. Open Issues 864 The following issues are still remain in this document. 866 o Generic Identifier support for session aggregation. 868 Session aggregation support may be needed in a backbone 869 environment. Wild card style aggregated session identifier may be 870 feasible. However, before specifying Generic Identifier support 871 for it, session aggregation model in ATM VCs should be clarified. 873 o Generic Identifier support for the IPv6 flow label and traffic 874 classes. 876 The IPv6 flow label and traffic classes support may be needed in 877 future. However, currently their semantics are not clear. 879 6. Required Amendments to the User-to-user Signaling 881 The information field and protocol identifier assignment in the 882 Generic Identifier information element and User-user information 883 element, which are described in section 4, are required for advanced 884 B-ISDN signaling support of the Internet protocol. 886 To enable advanced B-ISDN signaling support for the Internet 887 protocol, the following amendments should be applied to the Q.2957 888 and Q.2971 annex D User-to-user Signaling. 890 o Add the Internet protocol/application to the Protocol 891 discriminator. 893 o Increase the maximum length of the User-user information element to 894 sufficiently long, e.g. 262 octets, to forward the setup protocol 895 such as ST2+ and RSVP. This amendment is not applied and remains 896 133 octets when the User-user information element interworks with 897 the N-ISDN user-user information element. 899 7. Security Considerations 901 This document specifies the information field and protocol identifier 902 assignment in the Q.2941 Generic Identifier and Q.2957 User-to-user 903 Signaling for the Internet protocol, so these do not weaken the 904 security of the B-ISDN signaling. 906 In a called party of the B-ISDN signaling, if the incoming SETUP 907 message contains the calling party number and if it is verified and 908 passed by the ATM network or it is provided by the network, then it 909 is feasible to use the calling party number for part of the calling 910 party authentication to strengthen security. 912 References 914 [1] ITU-T, "Broadband Integrated Services Digital Network (B- 915 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 916 Network Interface (UNI) Layer 3 Specification for Basic 917 Call/Connection Control," ITU-T Recommendation Q.2931, September 918 1995. 920 [2] ITU-T, "Broadband Integrated Services Digital Network (B- 921 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 922 Network Interface Layer 3 Specification for Point-to-Multipoint 923 Call/Connection Control," ITU-T Recommendation Q.2971, October 924 1995. 926 [3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) 927 Digital Subscriber Signaling System No. 2 (DSS 2): Generic 928 Identifier Transport," Draft ITU-T New Recommendation Q.2941.1, 929 September 1997. 931 [4] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) 932 Digital Subscriber Signaling System No. 2 (DSS 2): Generic 933 Identifier Transport," Draft ITU-T New Recommendation Q.2941.2, 934 May 1998. (http://www.nal.ecl.net/SG11WP1/itu-t-sg11-tmp-doc- 935 td55r2.ps) 937 [5] ITU-T, "Stage 3 Description for Additional Information 938 Transfer Supplementary Service Using B-ISDN Digital Subscriber 939 Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User 940 Signalling (UUS)," ITU-T Recommendation Q.2957, February 1995. 942 [6] J. Postel Ed., "Internet Protocol," RFC 791, September 1981. 944 [7] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 945 Specification," Internet Draft, July 1997, . 948 [8] J. Postel, "User Datagram Protocol," RFC 768, August 1980. 950 [9] J. Postel Ed., "Transmission Control Protocol," RFC 793, 951 September 1981. 953 [10] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 954 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 955 August 1995. 957 [11] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 958 1 Functional Specification," RFC 2205, September 1997. 960 [12] K. Nagami, N. Demizu, H. Esaki, and P. Doolan, "VCID 961 Notification over ATM link," Internet Draft, March 1998, . 964 [13] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A 965 Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996. 967 [14] S. Damaskos and A. Gavras, "Connection Oriented Protocols 968 over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, 969 February 1994. 971 [15] ITU-T, "Integrated Services Digital Network (ISDN) Overall 972 Network Aspects and Functions ISDN Protocol Reference Model," 973 ITU-T Recommendation I.320, November 1993. 975 [16] ITU-T, "Digital Subscriber Signaling System No. 1 (DSS 1) 976 Specification of a Synchronization and Coordination Function for 977 the Provision of the OSI Connection-mode Network Service in an 978 ISDN Environment," ITU-T Recommendation Q.923, February 1995. 980 [17] K. Kitami, "Proposed Direction for B-ISDN & Multimedia 981 Signaling," ITU-T SG11 Delayed Contribution D.647, January 1998, 982 (http://www.nal.ecl.net/SG11WP1/itu-t-sg11-del-contrib-d647.ps). 984 Acknowledgments 986 I would like to thank Kenichi Kitami of the NTT Network Innovation 987 Planning and Promotion Dept., who is also the chair of ITU-T SG11 988 WP1, Shinichi Kuribayashi of the NTT Business Communications Hqs., 989 Hiroshi Yao and Takumi Ohba of the NTT Network Service Systems 990 Labs., and Noriyuki Takahashi of the NTT Multimedia Networks Labs. 991 for their valuable comments and discussions. 993 And I would also like to thank the active members of IETF, ITU-T, 994 and ATM Forum, especially Joel Halpern of Newbridge Networks, 995 Andrew Malis of Ascend Communications, George Swallow and Bruce 996 Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of 997 AT&T, Greg Ratta of Lucent, Hiroshi Esaki and Kenichi Nagami of 998 Toshiba, and Noritoshi Demizu of NAIST for their valuable comments 999 and suggestions. 1001 Also this specification is based on various discussions during the 1002 ST2+ over ATM project at the NTT Multimedia Joint Project with 1003 NACSIS. I would like to thank Professor Shoichiro Asano of the 1004 National Center for Science Information Systems for his invaluable 1005 advice in this area. 1007 Author's Address 1009 Muneyoshi Suzuki 1010 NTT Multimedia Networks Laboratories 1011 3-9-11, Midori-cho 1012 Musashino-shi, Tokyo 180-8585, Japan 1014 Phone: +81-422-59-2119 1015 Fax: +81-422-59-2829 1016 EMail: suzuki@nal.ecl.net