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