idnits 2.17.1 draft-ietf-mpls-vcid-atm-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-03-28) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (September 1998) is 9326 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) == Missing Reference: 'LDP' is mentioned on line 61, but not defined == Missing Reference: 'Note' is mentioned on line 111, but not defined -- Possible downref: Normative reference to a draft: ref. 'VCID' -- Possible downref: Normative reference to a draft: ref. 'VCPOOL' == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. 'ARCH' -- No information found for draft-suzuki-git-uus-assignment - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UUS' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Ken-ichi Nagami (Toshiba Corp.) 2 INTERNET DRAFT Noritoshi Demizu (SonyCSL/NAIST) 3 Hiroshi Esaki (Toshiba Corp.) 4 Paul Doolan (Ennovate Networks) 5 March 1998 6 Expires September 1998 8 VCID Notification over ATM link 9 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 Several label switching schemes have been proposed to integrate Layer 33 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of 34 the major applications of label switching. Because the ATM layer 35 labels (VPI and VCI) associated with a VC may change on each VC of 36 that VCC, it is not possible to use them to identify a VCC in label 37 binding messages. The concept of Virtual Connection Identifier (VCID) 38 is introduced to solve this problem. VCID has the same value at both 39 ends of a VCC. This document specifies the procedures for the 40 communication of VCID values between neighboring ATM-LSRs that must 41 occur in order to ensure this property. 43 1. Introduction 45 Several label switching schemes have been proposed to integrate Layer 46 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the 47 major applications of label switching. 49 In the case of ATM VCCs, the VPI and VCI labels are, in the general 51 Nagami, et al. [Page 1] 52 case, rewritten with new values at every switch node through which 53 the VCC passes and cannot be used to provide end to end 54 identification of a VCC. 56 In the context of MPLS 'flows', which are classes of packets that 57 have some common charachteristic that may be deduced by examination 58 of the layer 3 header in the packets, are bound to layer 2 'labels'. 59 We speak of flows being 'bound' to l abels. These bindings are 60 conveyed between peer LSRs by means of a Label Distributi on Protocol 61 [LDP]. 63 In order to apply MPLS to ATM links, we need some way to identify ATM 64 VCCs in LDP binding messages. In [VCID], an identifier called a 65 Virtual Connection ID (VCID) is introduced. VCID has the same value 66 at both ends of a VCC. This document specifies the procedures for 67 the communication of VCID values between neighboring ATM-LSRs that 68 must occur in order to ensure this property. 70 2. Overview of VCID Notification Procedures 72 2.1 VCID Notification procedures 74 The ATM has several types of VCCs (transparent point-to-point 75 link/VP/PVC/SVC). A transparent point-to-point link is defined as one 76 that has the same VPI/VCI label at both ends of a VCC. For example, 77 two nodes are directly connected (i.e., without intervening ATM 78 switches) or are connected through a VP with the same VPI value at 79 both ends of the VP. 81 There are two broad categories of VCID notification procedures; 82 inband and out of band. The categorisation refers to the connection 83 over which the messages of the VCID notification procedure are 84 forwarded. In the case of the inband procedures, those messages are 85 forwarded over the VCC to which they refer. In contrast the out of 86 band procedures transmit the messages over some other connection 87 (than the VCC to which they refer). 89 We list below the various types of link and briefly mention the VCID 90 notification procedures employed and the rational for that 91 choice. The procedures themselves are discussed in detail in later 92 sections. 94 Transparent point-to-point link : no VCID notification 95 VCID notification procedure is not necessary because the label 96 (i.e., VPI/VCI) is the same at each end of the VC. 98 VP : inband notification (as a default mechanism) 100 Nagami, et al. [Page 2] 101 - Inband notification 102 VCID notification is needed because the VPI at each end of the VC 103 may not be the same. Inband VCID notification [VCID] is used in 104 this case. 106 - No notification 107 If a node has only one VP to a neighboring node, VCID notification 108 procedure is not mandatory. The VCI can be used as the VCID. This 109 is because the VCI value is the same at each end of the VP. 111 [Note] For easier implementation, using inband notification even 112 in the case of a single VP is recommended. 114 PVC : inband notification 115 Inband VCID notification [VCID] is used in this case because the 116 labels at each end of the VC may not be the same. 118 SVC : there are three possibilities 119 - Out of band notification 120 If a signaling message has a field which is large enough to carry 121 a VCID value (e.g., UUS [UUS]), then the VCID is carried directly 122 in it. 124 - Outband notification using a small-sized field 125 If a signaling message has a field which is not large enough to 126 carry a VCID value, this procedure is used. 128 - Inband notification 129 If a signaling message can not carry user information, this 130 procedure is used. 132 When an LSP is a point-to-multipoint VC and an ATM switch in an 133 LSR is not capable of VC merge, it may cause problems in 134 performance and quality of service. When the LSR wants to add a 135 new leaf to the LSP, it needs to split the active LSP temporarily 136 to send an inband notification message. 138 2.2 VCID Assignment 140 A VCID value is assigned by either an upstream node or a downstream 141 node depending on the type of VC. For a point-to-point VC, either 142 the upstream node or the downstream node could assign a VCID 143 value. For a point-to-multipoint VC, only an upstream (root) node can 144 assign a VCID value. 146 3. VCID Notification Procedures 148 Nagami, et al. [Page 3] 149 3.1 Inband Notification Procedures 151 3.1.1 Inband Notification for Point-to-point VC 153 VCID notification is performed by transmitting a control message 154 through the VCC newly established (by signalling or management) for 155 use as an label switched path (LSP) [ARCH], The procedure for VCID 156 notification between two nodes A and B is detailed below. 158 0. Node A establishes a VCC to the destination LSR B. (by signalling 159 or management) 161 1. Node A selects a VCID value. 163 2. Node A sends a message which contains the VCID value through the 164 newly established VCC to Node B. 166 3. Node A establishes an association between the label for the VC and 167 the VCID value. 169 4. Node B receives the message from the VCC and establishes an 170 association between the VCID in the message and that VCC. 172 5. Node B sends an ACK message to node A. 174 6. After Node A receives the ACK message, node A and node B both 175 associate the VCID with the same VCC. 177 Node A Node B 178 | | 179 |--------------->| 180 | VCID | 181 | | 182 |<---------------| 183 | ACK | 185 3.1.2 Inband notification for point-to-multipoint VC 187 VCID notification is performed by sending a control message through 188 the VCC to be used as an LSP. The upstream node must assign the VCID 189 value, the procedure by which it notifies the downstream node of that 190 value is given below. The procedure is used when a new VCC is created 191 or a new leaf is added to the VCC. 193 First, the procedure for establishing the first VC is described. 195 1. The upstream node assigns a VCID value for the VCC. When the VCID 196 value is already assigned to a VCC, it is used for VCID. 198 Nagami, et al. [Page 4] 199 2. The upstream node sends a message which contains the VCID value 200 and the address of the upstream node through the VCC used for a 201 label switched path. This message is transferred to all leaf 202 nodes. 204 3. The upstream node establishes an association between the label for 205 the VC and the VCID value. 207 4. The downstream nodes receiving the message check the address of 208 the upstream node. If the address is not the same network prefix 209 as own address, the message is discarded. Otherwise, the 210 downstream nodes establish an association between the VCID in the 211 message and the VC from which the message is received. 213 5. The downstream nodes send an ACK message to the upstream node. 215 6. After the upstream node receives the ACK messages, the upstream 216 node and the downstream nodes share the VCID. 218 Upstream Downstream 1 Downstream 2 219 | | | 220 |-----------+--->| | 221 | VCID +------------------->| 222 | | | 223 |<---------------| | 224 | ACK | | 225 |<-------------------------------| 226 | ACK | 228 Second, the procedure for adding a leaf to the existing 229 point-to-multipoint VC is described. 231 0. The upstream node adds the downstream node, using the ATM 232 signaling. 234 1. The VCID value which already assigned to the VCC is used. 236 2. The upstream node sends a message which contains the VCID value 237 and the address of the upstream node through the VCC used for a 238 label switched path. This message is transferred to all leaf 239 nodes. 241 3. The downstream nodes receiving the message check the address of 242 the upstream node. If the address is not the same network prefix 243 as own address, the message is discarded. Otherwise, the 244 downstream nodes establish an association between the VCID in the 245 message and the VC from which the message is received. 247 Nagami, et al. [Page 5] 248 4. After the upstream node receives the ACK messages, the upstream 249 node and the downstream nodes share the VCID. 251 3.2 Outband Notification using a small-sized field 253 This method can be applied when a VC is established using a signaling 254 message and the message has a field which is not large enough to 255 carry a VCID value. 257 The signaling SETUP message of ATM Forum UNI 3.1/4.0 has a 7-bit 258 mandatory field for the user. This is a user specific field in the 259 Layer 3 protocol field in the BLLI IE (Broadband Low Layer 260 Information Information Element). 262 The BLLI value is used as a temporary identifier for a VC during a 263 VCID notification procedure. This mechanism is defined as "Outband 264 Notification using a small-sized field" described in [VCID]. The BLLI 265 value of a new VC must not be assigned to other VCs during the 266 procedure to avoid identifier conflict. When the association among 267 the BLLI value, a VCID value, and the corresponding VC is 268 established, the BLLI value can be reused for a new VC. VCID values 269 can be assigned independently from BLLI values. 271 Node A Node B 272 | | 273 |<-------------->| 274 | ATM Signaling | 275 | with BLLI | 276 | | 277 |--------------->| 278 | BLLI & VCID | 279 | | 280 |<---------------| 281 | ACK | 283 A point-to-multipoint VC can also be established using ADD_PARTY of 284 ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC 285 or an existing VC tree. In this procedure, the BLLI value of 286 ADD_PARTY has to be the same value as that used to establish the 287 first point-to-point VC of the tree. The same BLLI value can be used 288 in different VC trees only when these VC trees can not add a leaf at 289 the same time. As a result, the BLLI value used in the signaling must 290 be determined by the root node of the multicast tree. 292 [note] 293 BLLI value is unique at the sender node. But BLLI value is not 294 unique at the reciever node because multiple sender nodes allocate 296 Nagami, et al. [Page 6] 297 the same BLLI value. So, the receiver node must recognize BLLI 298 value and the sender address. ATM Signaling messages(SETUP and 299 ADD_PARTY) carry both the BLLI and the sender ATM address. The 300 receiver node can realize which node sends the BLLI message. 302 3.2.1 Outband notification using a small-sized field for point-to-point VC 304 This subsection describes procedures for establishing a VCC and for 305 notification of its VCID between neighboring LSRs for unicast 306 traffic. VC pool [VCPOOL] can be applied. 308 For point-to-point VC, either an upstream LSR or a downstream LSR can 309 allocate a VCID for a new VC. 311 The procedure employed when the upstream LSR assigns a VCID is as 312 follows. 314 1. An upstream LSR establishes a VCC to the downstream LSR using ATM 315 signaling and supplies a value in the BLLI field that it is not 316 currently using for any other (incomplete) VCID notification 317 transaction with this peer. 319 2. The upstream LSR notifies the downstream LSR of the association 320 between the BLLI and VCID values. The precise form of the message 321 used is outside the scope of this document but it could be 322 dedicated to this purpose or a modified LDP BIND message. 324 3. The downstream LSR establishes the association between the VCC 325 with the BLLI value and the VCID and sends an ACK message to the 326 upstream LSR. If the VCID is associated with some other VCC 327 between the upstream and downstream LSRs, that old VCC is removed 328 from service. 330 4. After the upstream LSR receives the ACK message, it establishes 331 the association between the VCC and the VCID. The VCC is ready to 332 be used. At this time the BLLI value employed in this transaction 333 is free for reuse. 335 The procedure employed when a downstream LSR assigns a VCID is 336 as follows: 338 1. An upstream LSR establishes a VCC by ATM signaling between the 339 downstream LSR with a unique BLLI value at this time. 341 2. The downstream LSR notifies the upstream LSR of a paired BLLI 342 value and VCID using a message dedicated for this purpose or 343 together within a BIND message. 345 Nagami, et al. [Page 7] 346 3. The upstream LSR establishes the association between the VCC with 347 the BLLI value and the VCID and sends an ACK message to the 348 downstream LSR. If the VCID is associated with some other VCC 349 between the upstream and downstream LSRs, that old VCC is removed 350 from service. 352 4. After the downstream LSR receives the ACK message, it establishes 353 the association between the VC and the VCID. The VC is ready to 354 be used.At this time the BLLI value employed in this transaction 355 is free for reuse. 357 3.2.2 Outband notification using a small-sized field 358 for point-to-multipoint VC 360 This subsection describes procedures for establishing the first VC 361 for a multicast tree and for adding a new VC leaf to an existing VCC 362 tree including the notification of its VCID for a multicast stream 363 using point-to-multipoint VCs. 365 In this procedure, an upstream LSR determines both the VCID and BLLI 366 value in the multicast case. The reason that the BLLI value is 367 determined by an upstream LSR is described above. 369 First, the procedure for establishing the first VC is described. 371 1. An upstream LSR establishes a VC by ATM Forum Signaling between 372 the downstream LSR with a unique BLLI value at this time. 374 2. The upstream LSR notifies the downstream LSR of a paired BLLI 375 value and VCID using a message dedicated for this purpose or 376 together within a BIND message. 378 3. The downstream LSR establishes the association between the VC with 379 the BLLI value and the VCID and sends an ACK message to the 380 upstream LSR. If the VCID is used by some other VC between the 381 upstream and downstream LSRs, the old VC is discarded. 383 4. After the upstream LSR receives the ACK message, the VC is ready 384 to be used and the BLLI value can be used for another VC. 386 Second, the procedure for adding a leaf to the existing 387 point-to-multipoint VC is described. 389 1. The upstream LSR establishes a VC by ATM Forum Signaling between 390 its downstream LSR with the BLLI value that was used during the 391 first signaling procedure. If another VC is using the BLLI value 392 at the same time, the upstream waits for the completion of the 393 signaling procedure that is using this BLLI value. 395 Nagami, et al. [Page 8] 396 2. Go to step 2 of the procedure for the first VC. 398 3.3 Outband notification 400 This method can be applied when a VC is established using a signaling 401 message and the message has a field (e.g., UUS [UUS]) which is large 402 enough to carry a VCID value. 404 Node A Node B 405 | | 406 |<-------------->| 407 | ATM Signaling | 408 | with VCID | 410 Security Considerations 412 Security issues are not discussed in this document. 414 Intellectual Property Considerations 416 Toshiba Corporation and Ennovate Networks may seek patent or other 417 intellectual property protection for some of the aspects of the 418 technology discussed in this document. If any standards arising from 419 this document are or become protected by one or more patents assigned 420 to Toshiba Corporation, Toshiba intends to license them on reasonable 421 and non- discriminatory terms. 423 Acknowledgments 425 The authors would like to acknowledge the valuable technical comments 426 of the members of the LAST-WG of the WIDE Project. 428 References 430 [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", 431 draft-demizu-mpls-vcid-01.txt, Oct. 1997 433 [VCPOOL] N. Demizu, et al., "VC pool", 434 draft-demizu-mpls-vcpool-00.txt, Oct. 1997 436 [ARCH] R. Callon, et al., "A Framework for Multiprotocol Label 437 Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 439 Nagami, et al. [Page 9] 441 [UUS] M. Suzuki, "The Assignment of the Information Field and 442 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 443 User-to-user Signaling for the Internet Protocol", 444 draft-suzuki-git-uus-assignment-00.txt, Nov. 1997 446 Authors Information 448 Ken-ichi Nagami 449 R&D Center, Toshiba Corporation, 450 1 Komukai-Toshiba-cho, Saiwai-ku, 451 Kawasaki, 210, Japan 452 Phone: +81-44-549-2231 453 Email: nagami@isl.rdc.toshiba.co.jp 455 Noritoshi Demizu 456 Sony Computer Science Laboratory, Inc. 457 Takanawa Muse Bldg. 458 3-14-13, Higashigotanda, 459 Shinagawa-ku, Tokyo, 141 Japan 460 Phone: +81-3-5448-4380 461 E-mail: demizu@csl.sony.co.jp 462 E-mail: nori-d@is.aist-nara.ac.jp 464 Hiroshi Esaki 465 Computer and Network Division, 466 Toshiba Corporation, 467 1-1-1 Shibaura, 468 Minato-ku, 105-01, Japan 469 Email: hiroshi@isl.rdc.toshiba.co.jp 471 Paul Doolan 472 Ennovate Networks 473 330 Codman Hill Road 474 Boxborough, MA 475 Phone: 978-263-2002 x103 476 Email: pdoolan@ennovatenetworks.com