idnits 2.17.1 draft-ietf-mpls-git-uus-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 2 instances 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 (March 29, 1999) is 9158 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: '14' is defined on line 926, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 933, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 937, 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. '6' ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 793 (ref. '10') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '11') -- 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 (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Muneyoshi Suzuki 3 INTERNET DRAFT NTT 4 Expires September 29, 1999 March 29, 1999 6 The Assignment of the Information Field and Protocol Identifier 7 in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling 8 for the Internet Protocol 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 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 1. Purpose of Document 46 The purpose of this document is to specify the assignment of the 47 information field and protocol identifier in the Q.2941 Generic 48 Identifier and Q.2957 User-to-user Signaling for the Internet 49 protocol. 51 The assignment, that is specified in section 4 of this document, is 52 designed for advanced B-ISDN signaling support of the Internet 53 protocol, especially the B-ISDN signaling support for the connection 54 that corresponds to the session in the Internet protocol which is 55 clarified in section 2. Needless to say, the purpose of this 56 specification is not limited to this support, and it should also be 57 applicable to other purposes. 59 This specification provides an indispensable framework for the 60 implementation of long-lived session and QoS-sensitive session 61 transfers over ATM. Note that this document only specifies the 62 assignment of the information field and protocol identifier, and that 63 it may not specify complete protocol that enables interoperable 64 implementation. This is because it is beyond the scope of this 65 document and will be specified in a separate document. 67 2. Session-related ATM Connection 69 With the development of new multimedia applications on the current 70 Internet, the demands for multimedia support are increasing in the IP 71 network, which currently supports best effort communications. In 72 particular, demands to support QoS guaranteed communications are 73 increasing with the development of voice, audio, and video 74 communications applications. And it may also be necessary to 75 introduce the mechanism that can efficiently transfer the huge volume 76 of traffic expected with these applications. 78 The major features of B-ISDN are high speed, logical multiplexing 79 with the VP/VC, and flexible QoS management per VC, so it is quite 80 natural to use these distinctive functions of B-ISDN to implement a 81 multimedia support mechanism in the IP network. The flexible QoS 82 management and logical multiplexing functions in B-ISDN are the 83 expected method of implementing the QoS guaranteed communications in 84 the Internet. And when a long-lived session is supported by a 85 particular VC, efficient packet forwarding may be possible using the 86 high speed and logical multiplexing of B-ISDN. 88 This section clarifies B-ISDN signaling functions that are required 89 when the session is supported by the VC, for advanced B-ISDN 90 signaling support of the Internet protocol. 92 2.1 Long-lived Session Signaling 94 An example scenario for establishing a VC for a long-lived session is 95 shown in Fig. 2.1. 97 IP Router ATM SW ATM SW IP Router 98 +----+ Default VC +----+ 99 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 100 +--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+ 101 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 102 | | | / \ | | / \ | | | 103 +------+ +-----+ +-----+ +------+ 105 A. New session initially forwarded over a default VC. 107 IP Router ATM SW ATM SW IP Router 108 +----+ Default VC +----+ 109 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 110 +--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+ 111 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 112 | |<------+-/-\-+--------+-/-\-+------>| | 113 +------+ +-----+ +-----+ +------+ 114 New VC is set up 116 B. New VC is set up for the long-lived session. 118 IP Router ATM SW ATM SW IP Router 119 +----+ Default VC +----+ 120 | WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS | 121 +--+-+ | |<------+-\-/-+--------+-\-/-+------>| | +-+--+ 122 |.....|__ |===||==| X |========| X |==||===| __|.....| 123 | \-->|<------+-/-\-+--------+-/-\-+------>|<--/ | 124 +------+ +-----+ +-----+ +------+ 125 New VC 127 C. Transfer of the long-lived session to a new VC. 129 Fig. 2.1: Example scenario for establishing a VC for a long-lived session. 131 First, a session is multiplexed into the default VC connecting the 132 routers. Then, if a router detects that it is a long-lived session, 133 it sets up a new VC for the session. If the new VC is established 134 successfully, the long-lived session is moved to the new VC. 136 In this procedure involving an ATM VC setup, the B-ISDN signaling 137 entity in the called side router must detect that the incoming call 138 corresponds to a session of the Internet protocol and notify that 139 fact to the IP layer entity. Based on this information, the IP layer 140 entity moves the session to the new VC. 142 Therefore, to implement this signaling procedure, the B-ISDN 143 signaling must include an session identifier as an information 144 element. The B-LLI, B-HLI, User-user, and Generic Identifier 145 information elements are all capable of transferring this 146 information. Considering the original purposes of these information 147 elements, the most appropriate one to use is the Generic Identifier 148 information element. 150 2.2 QoS-sensitive Session Signaling 152 The major difference between QoS-sensitive session signaling and 153 long-lived session signaling is that call setup is not initiated by 154 the detection of a long-lived session, but is explicitly initiated by 155 the setup protocol such as ST2+ and RSVP. To implement QoS-sensitive 156 session signaling using ATM, the ATM network between the routers must 157 forward not only the session identifier but also the setup protocol. 159 There are two schemes for forwarding the setup protocol. One is to 160 multiplex the protocol into a default VC connecting the routers, or 161 to forward the protocol through a particular VC. In this case, the 162 QoS-sensitive session and the ATM VC are established sequentially. 163 The second scheme is to forward the setup protocol as an information 164 element in the B-ISDN signaling. In this case, the QoS-sensitive 165 session and the ATM VC are established simultaneously. The latter 166 scheme has the following advantages compared with the former one. 168 o Easier to implement. 170 - Admission control is simplified, because admission control for 171 the IP and ATM layers can be done simultaneously. 173 - Watchdog timer processing is simplified, because there is no need 174 to watch the IP layer establishment and ATM layer establishment 175 sequentially. 177 o If the setup protocol supports negotiation, then an ATM VC whose 178 QoS is based on the result of negotiation can be established. 180 However, the latter scheme, at least, cannot support a case where a 181 PVC is used to support a QoS-sensitive session. Therefore, both 182 procedures should be taken into account. 184 An example of a message sequence that simultaneously establishes a 185 QoS-sensitive session and an ATM VC is shown in Fig. 2.2. 187 IP Router ATM SW ATM SW IP Router 188 +----+ B-ISDN Signaling +----+ 189 | WS | +------+ UNI +-----+ Setup +-----+ UNI +------+ | WS | 190 +--+-+ | /->|<------+-\-/--Protocol--\-/-+------>|<-\ | +-+--+ 191 |.....|__/ |===||==| X |========| X |==||===| \__|.....| 192 | \-->|<------+-/-\-+--------+-/-\-+------>|<--/ | 193 +------+ +-----+ Data +-----+ +------+ 194 QoS VC 195 N-CONNECT | | 196 ---------->| | | | | | 197 |->| SETUP | | | | 198 | |------------>| | | | 199 | |<------------| | | | 200 | | CALL PROC |----------->| SETUP | | 201 | | | |------------>| | 202 | | | | |->| N-CONNECT 203 | | | | | |----------> 204 | | | | | |<---------- 205 | | | | CONN |<-| N-CONNECT-ACK 206 | | | |<------------| | 207 | | | |------------>| | 208 | | CONN |<-----------| CONN ACK |->| 209 | |<------------| | | | 210 | |------------>| | | | 211 |<-| CONN ACK | | | | 212 <----------| | | | | | 213 N-CONNECT | | 214 -ACK 216 Fig. 2.2: Example procedure for simultaneous QoS-sensitive session and 217 ATM VC establishment. 219 Both ST2+ and RSVP are currently proposed for the setup protocol and 220 new setup protocols are likely to be developed in the near future. 221 Therefore, to generalize the discussion, the procedure for the setup 222 protocol in this example is the general connection setup procedure 223 using confirmed service. 225 To implement this signaling procedure, the B-ISDN signaling must 226 include the User-user information element that the capacity is 227 sufficient to forward the setup protocol. 229 3. Overview of the Generic Identifier and User-to-user Signaling 231 3.1 Overview of the Generic Identifier 233 The Generic Identifier enables the transfer of identifiers between 234 end-to-end users in the ATM network, and it is defined in the Q.2941 235 Part 1 (Q.2941.1) [3] and Part 2 (Q.2941.2) [4] as an optional 236 information element for the Q.2931 [1] and Q.2971 [2] UNI signaling 237 protocol. The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, 238 ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP 239 PARTY, and DROP PARTY ACK messages that are transferred between end- 240 to-end users in the ATM network may contain up to three Generic 241 Identifier information elements. The ATM network transfers the 242 Generic Identifier information element transparently if it contains 243 no coding rule errors. 245 The format of the Generic Identifier information element specified in 246 the Q.2941 is shown in Fig. 3.1. 248 Bits 249 8 7 6 5 4 3 2 1 Octets 250 +-----+-----+-----+-----+-----+-----+-----+-----+ 251 | Information element identifier | 252 | = Generic identifier transport IE (0x7F) | 1 253 +-----+-----+-----+-----+-----+-----+-----+-----+ 254 | 1 | Coding | IE instruction field | 255 | Ext | standard |Flag |Res. | IE action ind. | 2 256 +-----+-----+-----+-----+-----+-----+-----+-----+ 257 | Length of contents of information element | 3-4 258 +-----+-----+-----+-----+-----+-----+-----+-----+ 259 | Identifier related standard/application | 5 260 +-----+-----+-----+-----+-----+-----+-----+-----+ 261 | Identifier type | 6 262 +-----+-----+-----+-----+-----+-----+-----+-----+ 263 | Identifier length | 7 264 +-----+-----+-----+-----+-----+-----+-----+-----+ 265 | Identifier value | 8- 266 = = 267 +-----+-----+-----+-----+-----+-----+-----+-----+ 268 = = 269 +-----+-----+-----+-----+-----+-----+-----+-----+ 270 | Identifier type | 271 +-----+-----+-----+-----+-----+-----+-----+-----+ 272 | Identifier length | 273 +-----+-----+-----+-----+-----+-----+-----+-----+ 274 | Identifier value | 275 = = 276 +-----+-----+-----+-----+-----+-----+-----+-----+ 278 Fig. 3.1: Format of the Generic Identifier information element. 280 The usage of the first 4 octets of fields is specified in section 4 281 of the Q.2931. 283 The Identifier related standard/application field identifies the 284 standard or application that uses the identifier. Assignment of the 285 Identifier related standard/application field for the Intenet 286 protocol is as follows. A leading 0x means hexadecimal. 288 0x03: IPv4. 290 0x04: ST2+. 292 0x05: IPv6. 294 0x06: MPLS. 296 Note: DSM-CC, H.310/H.321, MPOA, ATM VCC Trunking, AAL2, and 297 H.323/H.245 are also supported. 299 A transferred identifier is given by the combination of the 300 Identifier type, length and value fields, and a Generic Identifier 301 information element may contain multiple identifiers. 303 Assignment of the Identifier type field for the Intenet protocol is 304 as follows. A leading 0x means hexadecimal. 306 0x01: Session. 308 0x02: Resource. 310 0x03-0xFD: Reserved for IANA assignment. 312 0xFE: Experiment/Organization specific. 314 The maximum length of the Generic Identifier information element is 315 63 octets. 317 See the Q.2941.1 and Draft Q.2941.2 for detailed protocol 318 specifications of the Generic Identifier. 320 3.2 Overview of the User-to-user Signaling 322 The User-to-user Signaling enables the transfer of information 323 between end-to-end users in the ATM network, and it is defined in 324 Q.2957 [5, 6] and in Q.2971 annex D [2] as an optional information 325 element for the Q.2931 [1] and Q.2971 [2] UNI signaling protocol. 326 The SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS, 327 ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP 328 PARTY, and DROP PARTY ACK messages that are transferred between end- 329 to-end users in the ATM network may contain a User-user information 330 element. The ATM network transfers the User-user information element 331 transparently if it contains no coding rule errors. 333 From the viewpoint of B-ISDN signaling applications, it seems the 334 Generic Identifier and User-to-user Signaling are similar functions. 335 But their rules for processing exceptions are not completely the 336 same, because their purposes are different. The Generic Identifier is 337 designed for the transfer of identifiers between the c-planes, while 338 the User-to-user Signaling is designed for the transfer of user data 339 via the c-planes. Another difference is that the latter supports 340 interworking with the user-user information element in the Q.931 N- 341 ISDN signaling, but the Generic Identifier does not. Note that the 342 ATM network may check the contents of the Generic Identifier 343 information element, but does not check the contents of the User-to- 344 user information element. 346 The format of the User-user information element is shown in Fig. 3.2. 348 Bits 349 8 7 6 5 4 3 2 1 Octets 350 +-----+-----+-----+-----+-----+-----+-----+-----+ 351 | Information element identifier | 352 | = User-user information element (0x7E) | 1 353 +-----+-----+-----+-----+-----+-----+-----+-----+ 354 | 1 | Coding | IE instruction field | 355 | Ext | standard |Flag |Res. | IE action ind. | 2 356 +-----+-----+-----+-----+-----+-----+-----+-----+ 357 | Length of contents of information element | 3-4 358 +-----+-----+-----+-----+-----+-----+-----+-----+ 359 | Protocol discriminator | 5 360 +-----+-----+-----+-----+-----+-----+-----+-----+ 361 | User information | 6- 362 = = 363 | | 364 +-----+-----+-----+-----+-----+-----+-----+-----+ 366 Fig. 3.2: Format of the User-user information element. 368 The usage of the first 4 octets of fields is specified in section 4 369 of the Q.2931. 371 The Protocol discriminator field identifies the upper layer protocol 372 that uses the user-user information. 374 The User information field contains the user-user information to be 375 transferred. 377 The maximum length of the User-user information element is 133 378 octets. 380 See Q.2957, Draft Q.2957 amendment 1, and Q.2971 annex D for detailed 381 protocol specifications of the User-to-user Signaling. 383 4. Information Field and Protocol Identifier Assignment 385 4.1 Assignment in the Generic Identifier Information Element 387 4.1.1 Use of Generic Identifier 389 The information field and protocol identifier assignment principle 390 for the Internet protocol in the Generic Identifier information 391 element is shown in Fig. 4.1. 393 Bits 394 8 7 6 5 4 3 2 1 Octets 395 +-----+-----+-----+-----+-----+-----+-----+-----+ 396 | Information element identifier | 397 | = Generic identifier transport IE (0x7F) | 1 398 +-----+-----+-----+-----+-----+-----+-----+-----+ 399 | 1 | Coding | IE instruction field | 400 | Ext | standard |Flag |Res. | IE action ind. | 2 401 +-----+-----+-----+-----+-----+-----+-----+-----+ 402 | Length of contents of information element | 3-4 403 +-----+-----+-----+-----+-----+-----+-----+-----+ 404 | Identifier related standard/application | 405 | = IPv4, ST2+, IPv6, or MPLS | 5 406 +-----+-----+-----+-----+-----+-----+-----+-----+ 407 | Identifier type | 408 | = Session, Resource, or Experiment | 6 409 +-----+-----+-----+-----+-----+-----+-----+-----+ 410 | Identifier length | 7 411 +-----+-----+-----+-----+-----+-----+-----+-----+ 412 | Identifier value | 8- 413 = = 414 +-----+-----+-----+-----+-----+-----+-----+-----+ 415 = = 416 +-----+-----+-----+-----+-----+-----+-----+-----+ 417 | Identifier type | 418 | = Session, Resource, or Experiment | 419 +-----+-----+-----+-----+-----+-----+-----+-----+ 420 | Identifier length | 421 +-----+-----+-----+-----+-----+-----+-----+-----+ 422 | Identifier value | 423 = = 424 +-----+-----+-----+-----+-----+-----+-----+-----+ 426 Fig. 4.1: Principle of assignment in the Generic Identifier 427 information element. 429 The Identifier related standard/application field is the IPv4, ST2+, 430 IPv6, or MPLS. 432 The Identifier type field is the Session, Resource, or 433 Experiment/Organization specific. 435 The Identifier value field is assigned to Internet protocol related 436 information which is identified by the Identifier related 437 standard/application field and Identifier type field. The following 438 identifiers are specified. 440 Std./app. Id type 442 IPv4 session identifier IPv4 Session 444 ST2+ session identifier ST2+ Session 446 IPv6 session identifier IPv6 Session 448 MPLS VCID MPLS Resource 450 Exp./Org. specific IPv4/ST2+/IPv6/MPLS Experiment 452 As described in section 3.1, the B-ISDN signaling message transferred 453 between end-to-end users may contain up to three Generic Identifier 454 information elements. These elements may contain multiple 455 identifiers. This document does not specify the order of identifiers 456 when multiple identifiers appear in a signaling message. 458 This document also does not specify the semantics when multiple 459 identifiers having the same Identifier type appear in a signaling 460 message, or when a signaling message contains a Generic Identifier 461 information element that does not contain identifiers. 463 When a B-ISDN signaling message containing a Generic Identifier 464 information element enters an ATM network that does not support the 465 Generic Identifier, the network clears the call, discards the 466 information element, or discards the signaling message. (See 467 sections 4.5.1 and 5.6.8.1 of Q.2931 and section 9.3 of Q.2941.1 for 468 details.) 470 To enable reliable Generic Identifier information element transfer, 471 when the calling party sends a SETUP or ADD PARTY message with up to 472 three Generic Identifier information elements, the CONNECT or ADD 473 PARTY ACK message returned by the called party must contain at least 474 one Generic Identifier information element. The called party may not 475 respond with the same identifiers received from the calling party. 477 The calling party should confirm that the response message contains 478 at least one Generic Identifier information element. This rule 479 enables identifier negotiation; this document does not specify the 480 detailed procedure of this negotiation. 482 4.1.2 IPv4 session identifier 484 If the Identifier related standard/application field in the Generic 485 Identifier information element is the IPv4, and the Identifier type 486 field in the identifier is the Session, the identifier is the IPv4 487 session identifier. The format of the IPv4 session identifier is 488 shown in Fig. 4.2. 490 Bits Octet 491 8 7 6 5 4 3 2 1 length 492 +-----+-----+-----+-----+-----+-----+-----+-----+ 493 | Identifier type | 494 | = Session (0x01) | 1 495 +-----+-----+-----+-----+-----+-----+-----+-----+ 496 | Identifier length | 497 | = 13 octets (0x0D) | 1 498 +-----+-----+-----+-----+-----+-----+-----+-----+ 499 | Source IPv4 address | 4 500 +-----+-----+-----+-----+-----+-----+-----+-----+ 501 | Destination IPv4 address | 4 502 +-----+-----+-----+-----+-----+-----+-----+-----+ 503 | Protocol | 1 504 +-----+-----+-----+-----+-----+-----+-----+-----+ 505 | Source Port | 2 506 +-----+-----+-----+-----+-----+-----+-----+-----+ 507 | Destination Port | 2 508 +-----+-----+-----+-----+-----+-----+-----+-----+ 510 Fig. 4.2: IPv4 session identifier. 512 The Identifier type field is the Session (0x01). 514 The Identifier length is 13 octets. 516 The Source IPv4 address, Destination IPv4 address, Protocol, Source 517 Port, and Destination Port [7, 9, 10] are assigned in that order to 518 the Identifier value field. 520 Note: This specific session identifier is intended for use only with 521 the explicit reservation. If wild card associations are needed at a 522 later date, another identifier type will be used. 524 4.1.3 ST2+ session identifier 526 If the Identifier related standard/application field in the Generic 527 Identifier information element is the ST2+, and the Identifier type 528 field in the identifier is the Session, the identifier is the ST2+ 529 session identifier. The format of the ST2+ session identifier is 530 shown in Fig. 4.3. 532 Bits Octet 533 8 7 6 5 4 3 2 1 length 534 +-----+-----+-----+-----+-----+-----+-----+-----+ 535 | Identifier type | 536 | = Session (0x01) | 1 537 +-----+-----+-----+-----+-----+-----+-----+-----+ 538 | Identifier length | 539 | = 6 octets (0x06) | 1 540 +-----+-----+-----+-----+-----+-----+-----+-----+ 541 | Stream ID (SID) | 6 542 +-----+-----+-----+-----+-----+-----+-----+-----+ 544 Fig. 4.3: ST2+ session identifier. 546 The Identifier type field is the Session (0x01). 548 The Identifier length is 6 octets. 550 The Stream ID (SID) [11] is assigned to the Identifier value field. 552 4.1.4 IPv6 session identifier 554 If the Identifier related standard/application field in the Generic 555 Identifier information element is the IPv6, and the Identifier type 556 field in the identifier is the Session, the identifier is the IPv6 557 session identifier. The format of the IPv6 session identifier is 558 shown in Fig. 4.4. 560 Bits Octet 561 8 7 6 5 4 3 2 1 length 562 +-----+-----+-----+-----+-----+-----+-----+-----+ 563 | Identifier type | 564 | = Session (0x01) | 1 565 +-----+-----+-----+-----+-----+-----+-----+-----+ 566 | Identifier length | 567 | = 37 octets (0x25) | 1 568 +-----+-----+-----+-----+-----+-----+-----+-----+ 569 | Source IPv6 address | 16 570 +-----+-----+-----+-----+-----+-----+-----+-----+ 571 | Destination IPv6 address | 16 572 +-----+-----+-----+-----+-----+-----+-----+-----+ 573 | Protocol | 1 574 +-----+-----+-----+-----+-----+-----+-----+-----+ 575 | Source Port | 2 576 +-----+-----+-----+-----+-----+-----+-----+-----+ 577 | Destination Port | 2 578 +-----+-----+-----+-----+-----+-----+-----+-----+ 580 Fig. 4.4: IPv6 session identifier. 582 The Identifier type field is the Session (0x01). 584 The Identifier length is 37 octets. 586 The Source IPv6 address, Destination IPv6 address, Protocol, Source 587 Port, and Destination Port [8, 9, 10] are assigned in that order to 588 the Identifier value field. 590 Note: This specific session identifier is intended for use only with 591 the explicit reservation. If wild card associations are needed at a 592 later date, another identifier type will be used. 594 4.1.5 MPLS VCID 596 If the Identifier related standard/application field in the Generic 597 Identifier information element is the MPLS, and the Identifier type 598 field in the identifier is the Resource, the identifier is the MPLS 599 VCID. The format of the MPLS VCID is shown in Fig. 4.5. 601 Bits Octet 602 8 7 6 5 4 3 2 1 length 603 +-----+-----+-----+-----+-----+-----+-----+-----+ 604 | Identifier type | 605 | = Resource (0x02) | 1 606 +-----+-----+-----+-----+-----+-----+-----+-----+ 607 | Identifier length | 608 | = 4 octets (0x04) | 1 609 +-----+-----+-----+-----+-----+-----+-----+-----+ 610 | MPLS VCID | 4 611 +-----+-----+-----+-----+-----+-----+-----+-----+ 613 Fig. 4.5: MPLS VCID. 615 The Identifier type field is the Resource (0x02). 617 The Identifier length is 4 octets. 619 The MPLS VCID [13] is assigned to the Identifier value field. 621 4.1.6 Experiment/Organization specific 623 If the Identifier related standard/application field in the Generic 624 Identifier information element is the IPv4, ST2+, IPv6, or MPLS, and 625 the Identifier type field in the identifier is the 626 Experiment/Organization specific, the identifier is the 627 Experiment/Organization specific. The format of the 628 Experiment/Organization specific is shown in Fig. 4.6. 630 Bits Octet 631 8 7 6 5 4 3 2 1 length 632 +-----+-----+-----+-----+-----+-----+-----+-----+ 633 | Identifier type | 634 | = Experiment/Organization specific (0xFE) | 1 635 +-----+-----+-----+-----+-----+-----+-----+-----+ 636 | Identifier length | 1 637 +-----+-----+-----+-----+-----+-----+-----+-----+ 638 | Organizationally unique identifier (OUI) | 3 639 +-----+-----+-----+-----+-----+-----+-----+-----+ 640 | Experiment/Organization specific info. | 641 = = 642 | | 643 +-----+-----+-----+-----+-----+-----+-----+-----+ 645 Fig. 4.6: Experiment/Organization specific. 647 The Identifier type field is the Experiment/Organization specific 648 (0xFE). 650 The first 3 octets in the Identifier value field must contain the 651 Organizationally unique identifier (OUI) (as specified in IEEE 802- 652 1990; section 5.1). 654 4.2 Assignment in the User-user Information Element 656 4.2.1 Use of User-to-user Signaling 658 The information field and protocol identifier assignment principle 659 for the Internet protocol in the User-user information element is 660 shown in Fig. 4.7. 662 Bits 663 8 7 6 5 4 3 2 1 Octets 664 +-----+-----+-----+-----+-----+-----+-----+-----+ 665 | Information element identifier | 666 | = User-user information element (0x7E) | 1 667 +-----+-----+-----+-----+-----+-----+-----+-----+ 668 | 1 | Coding | IE instruction field | 669 | Ext | standard |Flag |Res. | IE action ind. | 2 670 +-----+-----+-----+-----+-----+-----+-----+-----+ 671 | Length of contents of information element | 3-4 672 +-----+-----+-----+-----+-----+-----+-----+-----+ 673 | Protocol discriminator | 674 | = Internet protocol/application (0x06) | 5 675 +-----+-----+-----+-----+-----+-----+-----+-----+ 676 | Internet protocol/application identifier | 6 677 +-----+-----+-----+-----+-----+-----+-----+-----+ 678 | Internet protocol/application related info. | 7- 679 = = 680 | | 681 +-----+-----+-----+-----+-----+-----+-----+-----+ 683 Fig. 4.7: Principle of assignment in the User-user information element. 685 The Protocol discriminator field is the Internet protocol/application 686 (0x06). In this case, the first 1 octet in the User information 687 field is the Internet protocol/application identifier field. 689 Assignment of the Internet protocol/application identifier field is 690 as follows. A leading 0x means hexadecimal. 692 0x00: Reserved. 694 0x01: ST2+ SCMP. 696 0x02: RSVP message. 698 0x03-0xFD: Reserved for IANA assignment. 700 0xFE: Experiment/Organization specific. 702 0xFF: Reserved. 704 The field that follows the Internet protocol/application identifier 705 field is assigned to Internet protocol/application related 706 information that is identified by the Internet protocol/application 707 identifier field. 709 When a B-ISDN signaling message containing a User-user information 710 element enters an ATM network that does not support the User-to-user 711 Signaling, the network clears the call, discards the information 712 element, or discards the signaling message. (See sections 4.5.1 and 713 5.6.8.1 of Q.2931, section 1.9 of Q.2957, and Q.2971 annex D for 714 details.) 716 To enable reliable User-user information element transfer, when the 717 calling party sends a SETUP or ADD PARTY message with a User-user 718 information element, the CONNECT or ADD PARTY ACK message returned by 719 the called party must contain a User-user information element. The 720 called party may not respond with the same user information received 721 from the calling party. The calling party should confirm that the 722 response message contains a User-user information element. This rule 723 enables negotiation; this document does not specify the detailed 724 procedure of this negotiation. 726 4.2.2 ST2+ SCMP 728 The format of the ST2+ SCMP is shown in Fig. 4.8. 730 Bits 731 8 7 6 5 4 3 2 1 Octets 732 +-----+-----+-----+-----+-----+-----+-----+-----+ 733 | Information element identifier | 734 | = User-user information element (0x7E) | 1 735 +-----+-----+-----+-----+-----+-----+-----+-----+ 736 | 1 | Coding | IE instruction field | 737 | Ext | standard |Flag |Res. | IE action ind. | 2 738 +-----+-----+-----+-----+-----+-----+-----+-----+ 739 | Length of contents of information element | 3-4 740 +-----+-----+-----+-----+-----+-----+-----+-----+ 741 | Protocol discriminator | 742 | = Internet protocol/application (0x06) | 5 743 +-----+-----+-----+-----+-----+-----+-----+-----+ 744 | Internet protocol/application identifier | 745 | = ST2+ SCMP (0x01) | 6 746 +-----+-----+-----+-----+-----+-----+-----+-----+ 747 | ST2+ SCMP | 7- 748 = = 749 | | 750 +-----+-----+-----+-----+-----+-----+-----+-----+ 752 Fig. 4.8: ST2+ SCMP. 754 The Internet protocol/application identifier field is the ST2+ SCMP 755 (0x01). 757 The ST2+ SCMP [11] is assigned to the Internet protocol/application 758 related information field. The SETUP and ADD PARTY messages may 759 contain the ST2+ SCMP CONNECT message. The CONNECT and ADD PARTY ACK 760 messages may contain the ST2+ SCMP ACCEPT message. The RELEASE and 761 DROP PARTY messages may contain the ST2+ SCMP DISCONNECT message. 762 The RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and DROP PARTY 763 messages may contain the ST2+ SCMP REFUSE message. 765 4.2.3 RSVP message 767 The format of the RSVP message is shown in Fig. 4.9. 769 Bits 770 8 7 6 5 4 3 2 1 Octets 771 +-----+-----+-----+-----+-----+-----+-----+-----+ 772 | Information element identifier | 773 | = User-user information element (0x7E) | 1 774 +-----+-----+-----+-----+-----+-----+-----+-----+ 775 | 1 | Coding | IE instruction field | 776 | Ext | standard |Flag |Res. | IE action ind. | 2 777 +-----+-----+-----+-----+-----+-----+-----+-----+ 778 | Length of contents of information element | 3-4 779 +-----+-----+-----+-----+-----+-----+-----+-----+ 780 | Protocol discriminator | 781 | = Internet protocol/application (0x06) | 5 782 +-----+-----+-----+-----+-----+-----+-----+-----+ 783 | Internet protocol/application identifier | 784 | = RSVP message (0x02) | 6 785 +-----+-----+-----+-----+-----+-----+-----+-----+ 786 | RSVP message | 7- 787 = = 788 | | 789 +-----+-----+-----+-----+-----+-----+-----+-----+ 791 Fig. 4.9: RSVP message. 793 The Internet protocol/application identifier field is the RSVP 794 message (0x02). 796 The RSVP message [12] is assigned to the Internet 797 protocol/application related information field. The SETUP message 798 may contain the RSVP Resv message. The CONNECT message may contain 799 the RSVP ResvConf message. The RELEASE message may contain the RSVP 800 ResvErr or ResvTear message. 802 4.2.4 Experiment/Organization specific 804 The format of the Experiment/Organization specific is shown in Fig. 805 4.10. 807 Bits 808 8 7 6 5 4 3 2 1 Octets 809 +-----+-----+-----+-----+-----+-----+-----+-----+ 810 | Information element identifier | 811 | = User-user information element (0x7E) | 1 812 +-----+-----+-----+-----+-----+-----+-----+-----+ 813 | 1 | Coding | IE instruction field | 814 | Ext | standard |Flag |Res. | IE action ind. | 2 815 +-----+-----+-----+-----+-----+-----+-----+-----+ 816 | Length of contents of information element | 3-4 817 +-----+-----+-----+-----+-----+-----+-----+-----+ 818 | Protocol discriminator | 819 | = Internet protocol/application (0x06) | 5 820 +-----+-----+-----+-----+-----+-----+-----+-----+ 821 | Internet protocol/application identifier | 822 | = Experiment/Organization specific (0xFE) | 6 823 +-----+-----+-----+-----+-----+-----+-----+-----+ 824 | Organizationally unique identifier (OUI) | 7-9 825 +-----+-----+-----+-----+-----+-----+-----+-----+ 826 | Experiment/Organization specific info. | 10- 827 = = 828 | | 829 +-----+-----+-----+-----+-----+-----+-----+-----+ 831 Fig. 4.10: Experiment/Organization specific. 833 The Internet protocol/application identifier field is the 834 Experiment/Organization specific (0xFE). 836 The first 3 octets in the Internet protocol/application related 837 information field must contain the Organizationally unique identifier 838 (OUI) (as specified in IEEE 802-1990; section 5.1). 840 5. Open Issues 842 The following issues are still remain in this document. 844 o Generic Identifier support for session aggregation. 846 Session aggregation support may be needed in a backbone 847 environment. Wild card style aggregated session identifier may be 848 feasible. However, before specifying Generic Identifier support 849 for it, session aggregation model in ATM VCs should be clarified. 851 o Generic Identifier support for the IPv6 flow label and traffic 852 classes. 854 The IPv6 flow label and traffic classes support may be needed in 855 future. However, currently their semantics are not clear. 857 6. Security Considerations 859 This document specifies the information field and protocol identifier 860 assignment in the Q.2941 Generic Identifier and Q.2957 User-to-user 861 Signaling for the Internet protocol, so these do not weaken the 862 security of the B-ISDN signaling. 864 In a called party of the B-ISDN signaling, if the incoming SETUP 865 message contains the calling party number and if it is verified and 866 passed by the ATM network or it is provided by the network, then it 867 is feasible to use the calling party number for part of the calling 868 party authentication to strengthen security. 870 References 872 [1] ITU-T, "Broadband Integrated Services Digital Network (B- 873 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 874 Network Interface (UNI) Layer 3 Specification for Basic 875 Call/Connection Control," ITU-T Recommendation Q.2931, September 876 1995. 878 [2] ITU-T, "Broadband Integrated Services Digital Network (B- 879 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 880 Network Interface Layer 3 Specification for Point-to-Multipoint 881 Call/Connection Control," ITU-T Recommendation Q.2971, October 882 1995. 884 [3] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) 885 Digital Subscriber Signaling System No. 2 (DSS 2): Generic 886 Identifier Transport," Draft ITU-T New Recommendation Q.2941.1, 887 September 1997. 889 [4] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN) 890 Digital Subscriber Signaling System No. 2 (DSS 2): Generic 891 Identifier Transport," Draft ITU-T New Recommendation Q.2941.2, 892 March 1999. 894 [5] ITU-T, "Stage 3 Description for Additional Information 895 Transfer Supplementary Service Using B-ISDN Digital Subscriber 896 Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User 897 Signalling (UUS)," ITU-T Recommendation Q.2957, February 1995. 899 [6] ITU-T, "Stage 3 Description for Additional Information 900 Transfer Supplementary Service Using B-ISDN Digital Subscriber 901 Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User 902 Signalling (UUS)," Draft ITU-T Recommendation Q.2957 Amendment 1, 903 March 1999. 905 [7] J. Postel Ed., "Internet Protocol," RFC 791, September 1981. 907 [8] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 908 Specification," RFC 2460, December 1998. 910 [9] J. Postel, "User Datagram Protocol," RFC 768, August 1980. 912 [10] J. Postel Ed., "Transmission Control Protocol," RFC 793, 913 September 1981. 915 [11] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 916 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 917 August 1995. 919 [12] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 920 1 Functional Specification," RFC 2205, September 1997. 922 [13] K. Nagami, N. Demizu, H. Esaki, Y. Katsube, and P. Doolan, 923 "VCID Notification over ATM link," Internet Draft, December 1998, 924 . 926 [14] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A 927 Connectionless Approach to ATM," Proc. IEEE Infocom, March 1996. 929 [15] S. Damaskos and A. Gavras, "Connection Oriented Protocols 930 over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, 931 February 1994. 933 [16] ITU-T, "Integrated Services Digital Network (ISDN) Overall 934 Network Aspects and Functions ISDN Protocol Reference Model," 935 ITU-T Recommendation I.320, November 1993. 937 [17] ITU-T, "Digital Subscriber Signaling System No. 1 (DSS 1) 938 Specification of a Synchronization and Coordination Function for 939 the Provision of the OSI Connection-mode Network Service in an 940 ISDN Environment," ITU-T Recommendation Q.923, February 1995. 942 Acknowledgments 944 I would like to thank Kenichi Kitami of the NTT Information 945 Sharing Lab. Group, who is also the chair of ITU-T SG11 WP1, 946 Shinichi Kuribayashi of the NTT Information Sharing Platform 947 Labs., Hiroshi Yao and Takumi Ohba of the NTT Network Service 948 Systems Labs., and Noriyuki Takahashi of the NTT Information 949 Sharing Platform Labs., for their valuable comments and 950 discussions. 952 And I would also like to thank the active members of IETF, ITU-T, 953 and ATM Forum, especially Joel Halpern of Newbridge Networks, 954 Andrew Malis of Ascend Communications, George Swallow and Bruce 955 Davie of Cisco Systems, Rao Cherukuri of IBM, Rajiv Kapoor of 956 AT&T, Greg Ratta of Lucent, Kaoru Kenyoshi of NEC, Hiroto Uno of 957 Hitachi, Hiroshi Esaki and Kenichi Nagami of Toshiba, and 958 Noritoshi Demizu of NAIST for their valuable comments and 959 suggestions. 961 Also this specification is based on various discussions during the 962 ST2+ over ATM project at the NTT Multimedia Joint Project with 963 NACSIS. I would like to thank Professor Shoichiro Asano of the 964 National Center for Science Information Systems for his invaluable 965 advice in this area. 967 Author's Address 969 Muneyoshi Suzuki 970 NTT Information Sharing Platform Laboratories 971 3-9-11, Midori-cho 972 Musashino-shi, Tokyo 180-8585, Japan 974 Phone: +81-422-59-2119 975 Fax: +81-422-59-3203 976 EMail: suzuki@nal.ecl.net