idnits 2.17.1 draft-ietf-mpls-vcid-atm-04.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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 16 pages 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 6 instances of too long lines in the document, the longest one being 3 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 (January 2000) is 8868 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'GIT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ENCAPS' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 (NAIST) 3 Hiroshi Esaki (Univ. Tokyo) 4 Yasuhiro Katsube (Toshiba Corp.) 5 Paul Doolan (Ennovate Networks) 6 July 1999 7 Expires January 2000 9 VCID Notification over ATM link for LDP 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafrts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The ATM Label Switching Router (ATM-LSR) is one of the major 36 applications of label switching. Because the ATM layer labels (VPI 37 and VCI) associated with a VC rewritten with new value at every ATM 38 switch nodes, it is not possible to use them to identify a VC in 39 label mapping messages. The concept of Virtual Connection Identifier 40 (VCID) is introduced to solve this problem. VCID has the same value 41 at both ends of a VC. This document specifies the procedures for the 42 communication of VCID values between neighboring ATM-LSRs that must 43 occur in order to ensure this property. 45 1. Introduction 47 Several label switching schemes have been proposed to integrate Layer 48 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the 49 major applications of label switching. 51 In the case of ATM VCs, the VPI and VCI labels are, in the general 52 case, rewritten with new values at every switch node through which 53 the VC passes and cannot be used to provide end to end 54 identification of a VC. 56 In the context of MPLS 'stream', which are classes of packets that 57 have some common characteristic 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 stream being 'bound' to labels. These bindings are 60 conveyed between peer LSRs by means of a Label Distribution Protocol 61 [LDP]. 63 In order to apply MPLS to ATM links, we need some way to identify ATM 64 VCs in LDP mapping messages. An identifier called a Virtual 65 Connection ID (VCID) is introduced. VCID has the same value at both 66 ends of a VC. This document specifies the procedures for the 67 communication of VCID values between neighboring ATM-LSRs that must 68 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 VCs (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 VC. 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 outband. The categorization 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 VC to which they refer. In contrast the out of 86 band procedures transmit the messages over some other connection 87 (than the VC 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 or VPID notification or no notification 99 - Inband notification 100 VCID notification is needed because the VPI at each end of the VC 101 may not be the same. Inband VCID notification is used in this 102 case. 104 - VPID notification 105 VCID notification is needed because the VPI at each end of the VC 106 may not be the same. VPID notification is used in this case. 108 - No notification 109 If a node has only one VP to a neighboring node, VCID notification 110 procedure is not mandatory. The VCI can be used as the VCID. This 111 is because the VCI value is the same at each end of the VP. 113 PVC : inband notification 114 Inband VCID notification is used in this case because the labels 115 at each end of the VC may not be the same. 117 SVC : there are three possibilities 118 - Outband notification 119 If a signaling message has a field which is large enough to carry 120 a VCID value (e.g., GIT [GIT]), then the VCID is carried directly 121 in it. 123 - Outband notification using a small-sized field 124 If a signaling message has a field which is not large enough to 125 carry a VCID value, this procedure is used. 127 - Inband notification 128 If a signaling message can not carry user information, this 129 procedure is used. 131 When an LSP is a point-to-multipoint VC and an ATM switch in an 132 LSR is not capable of VC merge, it may cause problems in 133 performance and quality of service. When the LSR wants to add a 134 new leaf to the LSP, it needs to split the active LSP temporarily 135 to send an inband notification message. 137 2.2 VC direction 139 A VC has a directionality. The VCID procedure for a VC is always 140 triggered from the upstream node of the VC, i.e., the upstream node 141 notifies the downstream node of the VCID. 143 If bidirectional use of a label switched VC is allowed, the label 144 switched VC is said to be bidirectional. In this case, two VCID 145 procedures are taken, one for each direction. 147 If bidirectional use of a label switched VC is not allowed, the label 148 switched VC is said to be unidirectional. In this case, only one 149 VCID procedure is taken for the allowed direction. 151 VC directionality is communicated through LDP. 153 3. VCID Notification Procedures 155 3.1 Inband Notification Procedures 157 3.1.1 Inband Notification for Point-to-point VC 158 VCID notification is performed by transmitting a control message 159 through the VC newly established (by signalling or management) for 160 use as an label switched path (LSP) [FRAME]. The procedure for VCID 161 notification between two nodes A and B is detailed below. 163 0. The node A establishes a VC to the destination node B. (by signalling 164 or management) 166 1. The node A selects a VCID value. 168 2. The node A sends a VCID PROPOSE message which contains the VCID 169 value and a message ID through the newly established VC to the 170 node B. 172 3. The node A establishes an association between the outgoing label 173 (VPI/VCI) for the VC and the VCID value. 175 4. The node B receives the message from the VC and establishes an 176 association between the VCID in the message and the incoming 177 label(VPI/VCI) for the VC. Until the node B receives the LDP 178 Request message, the node B discards any packet received over the 179 VC other than the VCID PROPOSE message. 181 5. The node B sends an ACK message to the node A. This message 182 contains the same VCID and message ID as specified in the received 183 message. This message is sent through the VC for LDP. 185 6. When node A receives the ACK message, it checks whether the VCID 186 and the message ID in the message are the same as the registered 187 ones. If they are the same, node A regards that node B has 188 established the association between the VC and VCID. Otherwise, 189 the message is ignored. If the node A does not receive the ACK 190 message with the expected message ID and VCID during a given 191 period, the node A resends the VCID PROPOSE message to the node B. 193 7. After receiving the proposer ACK message, the node A sends an LDP 194 REQUEST message to the node B. It contains the message ID used for 195 VCID PROPOSE. When the node B receives the LDP REQUEST message, 196 it regards that the node A has received the ACK correctly. The 197 message exchange using VCID PROPOSE, VCID ACK, and LDP REQUEST 198 messages constitutes a 3-way handshake. The 3-way handshake 199 mechanism is required since the transmission of VCID PROPOSE 200 message is unreliable. Once the 3-way handshake completes, the 201 node B ignores all VCID PROPOSE messages received over the VC. The 202 node B sends an LDP Mapping message, which contains the VCID value 203 in the label TLV. 205 Node A Node B 206 | | 207 |--------------->| VCID PROPOSE 208 | | 209 |<---------------| VCID ACK 210 | | 211 |--------------->| LDP Label Request 212 | | 213 |<---------------| LDP Label Mapping 215 3.1.2 Inband notification for point-to-multipoint VC 217 Current LDP specification does not support multicast. But the VCID 218 notification procedure is defined for future use. VCID notification 219 is performed by sending a control message through the VC to be used 220 as an LSP. The upstream node assigns the VCID value. The procedure by 221 which it notifies the downstream node of that value is given 222 below. The procedure is used when a new VC is created or a new leaf 223 is added to the VC. 225 First, the procedure for establishing the first VC is described. 227 1. The upstream node assigns a VCID value for the VC. When the VCID 228 value is already assigned to a VC, it is used for VCID. 230 2. The upstream node sends a message which contains the VCID value 231 and a message ID through the VC used for an LSP. This message is 232 transferred to all leaf nodes. 234 3. The upstream node establishes an association between the outgoing 235 label for the VC and the VCID value. 237 4. When the downstream nodes receiving the message already received 238 the LDP REQUEST message for the VC, the received message is 239 discarded. Otherwise, the downstream nodes establish an 240 association between the VCID in the message and the VC from which 241 the message is received. 243 5. The downstream nodes send an ACK message to the upstream node. 245 6. After the upstream node receives the ACK messages, the upstream 246 node and the downstream nodes share the VCID. The upstream node 247 sends the LDP REQUEST message in order to make a 3-way handshake. 249 Upstream Downstream 1 Downstream 2 250 | | | 251 |-----------+--->| | VCID PROPOSE 252 | +------------------->| 253 | | | 254 |<---------------| | 255 | VCID ACK | | 256 |<-------------------------------| VCID ACK 258 Second, the procedure for adding a leaf to the existing 259 point-to-multipoint VC is described. 261 0. The upstream node adds the downstream node, using the ATM 262 signaling. 264 1. The VCID value which already assigned to the VC is used. 266 2. The upstream node sends a message which contains the VCID value 267 and a message ID through the VC used for an LSP. This message is 268 transferred to all leaf nodes. 270 3. When the downstream nodes receiving the message already received 271 the LDP REQUEST message for the VC, the received message is 272 discarded. Otherwise, the downstream nodes establish an 273 association between the VCID in the message and the VC from which 274 the message is received. 276 4. After the upstream node receives the ACK messages, the upstream 277 node and the downstream nodes share the VCID. The upstream node 278 sends the LDP REQUEST message in order to make a 3-way handshake. 280 3.2 Outband Notification using a small-sized field 282 This method can be applied when a VC is established using an ATM 283 signaling message and the message has a field which is not large 284 enough to carry a VCID value. 286 SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory 287 field for the user. This is a user specific field in the Layer 3 288 protocol field in the BLLI IE (Broadband Low Layer Information 289 Information Element). 291 The BLLI value is used as a temporary identifier for a VC during a 292 VCID notification procedure. This mechanism is defined as "Outband 293 Notification using a small-sized field". The BLLI value of a new VC 294 must not be assigned to other VCs during the procedure to avoid 295 identifier conflict. When the association among the BLLI value, a 296 VCID value, and the corresponding VC is established, the BLLI value 297 can be reused for a new VC. VCID values can be assigned independently 298 from BLLI values. 300 Node A Node B 301 | | 302 |--------------->| ATM Signaling with BLLI 303 |<---------------| 304 | | 305 |--------------->| VCID PROPOSE with BLLI 306 | | 307 |<---------------| VCID ACK 308 | | 309 |--------------->| LDP Label Request 310 | | 311 |<---------------| LDP Label Mapping 313 A point-to-multipoint VC can also be established using ADD_PARTY of 314 the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC 315 or an existing VC tree. In this procedure, the BLLI value of 316 ADD_PARTY has to be the same value as that used to establish the 317 first point-to-point VC of the tree. The same BLLI value can be used 318 in different VC trees only when these VC trees can not add a leaf at 319 the same time. As a result, the BLLI value used in the signaling must 320 be determined by the root node of the multicast tree. 322 [note] 323 BLLI value is unique at the sender node. But BLLI value is not 324 unique at the receiver node because multiple sender nodes may 325 allocate the same BLLI value. So, the receiver node must 326 recognize BLLI value and the sender address. ATM Signaling 327 messages(SETUP and ADD_PARTY) carry both the BLLI and the sender 328 ATM address. The receiver node can realize which node sends the 329 BLLI message. 331 3.2.1 Outband notification using a small-sized field for point-to-point VC 333 This subsection describes procedures for establishing a VC and for 334 notification of its VCID between neighboring LSRs for unicast 335 traffic. 337 The procedure employed when the upstream LSR assigns a VCID is as 338 follows. 340 1. An upstream LSR establishes a VC to the downstream LSR using ATM 341 signaling and supplies a value in the BLLI field that it is not 342 currently using for any other (incomplete) VCID notification 343 transaction with this peer. 345 2. The upstream LSR sends the VCID PROPOSE message through the VC for 346 LDP to notify the downstream LSR of the association 347 between the BLLI and VCID values. 349 3. The downstream LSR establishes the association between the VC 350 with the BLLI value and the VCID and sends an ACK message to the 351 upstream LSR. 353 4. After the upstream LSR receives the ACK message, it establishes 354 the association between the VC and the VCID. The VC is ready to 355 be used. At this time the BLLI value employed in this transaction 356 is free for reuse. 358 5. After VCID notification, the upstream node sends the LDP REQUEST 359 message to the downstream node. The downstream node sends the LDP 360 mapping message, which contains the VCID value in the label TLV of 361 LDP. 363 3.2.2 Outband notification using a small-sized field 364 for point-to-multipoint VC 366 This subsection describes procedures for establishing the first VC 367 for a multicast tree and for adding a new VC leaf to an existing VC 368 tree including the notification of its VCID for a multicast stream 369 using point-to-multipoint VCs. 371 In this procedure, an upstream LSR determines both the VCID and BLLI 372 value in the multicast case. The reason that the BLLI value is 373 determined by an upstream LSR is described above. 375 First, the procedure for establishing the first VC is described. 377 1. An upstream LSR establishes a VC by the ATM Forum Signaling between 378 the downstream LSR with a unique BLLI value at this time. 380 2. The upstream LSR notifies the downstream LSR of a paired BLLI 381 value and VCID using a message dedicated for this purpose. 383 3. The downstream LSR establishes the association between the VC with 384 the BLLI value and the VCID and sends an ACK message to the 385 upstream LSR. If the VCID is used by some other VC between the 386 upstream and downstream LSRs, the old VC is discarded. 388 4. After the upstream LSR receives the ACK message, the VC is ready 389 to be used and the BLLI value can be used for another VC. 391 Second, the procedure for adding a leaf to the existing 392 point-to-multipoint VC is described. 394 1. The upstream LSR establishes a VC by the ATM Forum Signaling between 395 its downstream LSR with the BLLI value that was used during the 396 first signaling procedure. If another VC is using the BLLI value 397 at the same time, the upstream waits for the completion of the 398 signaling procedure that is using this BLLI value. 400 2. Go to step 2 of the procedure for the first VC. 402 3.3 Outband notification 404 This method can be applied when a VC is established using a ATM 405 signaling message and the message has a field (e.g., GIT [GIT]) which 406 is large enough to carry a VCID value. Message format is described in 407 [GIT]. After the VCID notification, the node A sends the LDP request 408 message is sent to the node B. Then, the node B sends the LDP mapping 409 message to the node A. 411 Node A Node B 412 | | 413 |--------------->| ATM signaling with VCID 414 |<---------------| 415 | | 416 |--------------->| LDP Label Request 417 | | 418 |<---------------| LDP Label Mapping 420 4 VPID Notification Procedure 422 The approach that is used for the VCID notification procedure is also 423 applicable to share the same identifier between both ends for a VP. 424 VPID notification procedure is defined for this purpose. 426 A distinct VPID notification procedure is performed for each 427 direction of each VP. 429 After the VPID notification is finished for a VP, a VCID of a VC in 430 the VP is constructed with the VPID(MSB) and VCI(LSB) of the VC. The 431 VCID can be used by LDP without performing VCID notification 432 procedure. The message sequence is given below. 434 1. An upstream node sends the VPID PROPOSE message. 435 In the case of bidirectional label switched VC, both the upstream 436 and downstream nodes use VCI=33. In the case of unidirectional 437 label switched VC, the node which has larger LDP Identifier uses 438 VCI=33 and the other node uses VCI=34. Note that VCI=32, which is 439 used for unlabeled packet transfer, is not used for VPID 440 notification procedure so that the same encapsulation method can 441 be applied for both VPID procedure and inband VCID procedure. 443 2. The downstream node sends the VPID ACK message. 445 3. The upstream node sends the LDP Label Request message. 447 4. The downstream node sends the LDP Label Mapping message. 449 5 VCID Message Format 450 5.1 VCID Messages 452 An LDP VCID message consists of the LDP [LDP] fixed header followed 453 by one or more TLV. A VCID PROPOSE inband message and a VPID PROPOSE 454 message are sent as a null encapsulation packet through a VC to be 455 used as an LSP. There is only the label stack header before the LDP 456 VCID PDU. A label value in the label stack entry [ENCAPS] for the 457 VCID PROPOSE inband message and the VPID PROPOSE message are 4. 458 Other messages are sent as TCP packets. This is the same as LDP. 460 The VCID message type field is as follows: 461 VCID Propose inband Message = 0x0501 462 VCID Propose Message = 0x0502 463 VCID ACK Message = 0x0503 464 VCID NACK Message = 0x0504 465 VPID Propose inband Message = 0x0505 466 VPID ACK Message = 0x0506 467 VPID NACK Message = 0x0507 469 5.1.1 VCID Propose inband Message 470 This message is sent as a null encapsulation packet with LDP header 471 and label stack header through a VC to be used as an LSP. The label 472 value is 4. The reserved label value is required because the 473 downstream node may receive this message after receiving the LDP 474 Label Request message in the case of point-to-multipoint VC. The 475 downstream node must distinguish the VCID PROPOSE message from other 476 messages and ignore the VCID PROPOSE message when the node already 477 received the LDP Label Request message for the VC. 479 0 1 2 3 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |U|VCID Inband Propose (0x0501) | Message Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Message ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Label TLV | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Optional Parameters | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Message Id 492 Four octet integer used to identify this message. 494 Label TLV 495 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 497 5.1.2 VCID Propose Message 499 An LSR uses the VCID PROPOSE message for the VCID notification 500 procedure of the outband notification using a small-sized field. 501 This message is sent through the VC for the LDP. 503 0 1 2 3 504 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |U| VCID Propose (0x0502) | Message Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Message ID | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Label TLV | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Temporary ID TLV | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Optional Parameters | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Message ID 518 Four octet integer used to identify this message. 520 Label TLV 521 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 523 Temporary ID TLV 524 The value carried in the user specific field in the layer 3 525 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 526 Type of label TLV is VCID temporary ID(0x0702). 528 5.1.3 VCID ACK Message 530 An LSR send the VCID ACK message when the LSR accepts the VCID 531 PROPOSE message. 533 0 1 2 3 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 |U| VCID ACK (0x0503) | Message Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Message ID | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Label TLV | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | VCID Message ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Optional Parameters | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Message ID 548 Four octet integer used to identify this message. 550 Label TLV 551 The label TLV contains the VCID value of the received VCID PROPOSE 552 message. Type of label TLV is VCID(0x0203). 554 VCID Message ID 555 This value is the same as that of received VCID PROPOSE message. 557 5.1.4 VCID NACK Message 559 An LSR send the VCID NACK message when the LSR does not accept the 560 VCID PROPOSE message. 562 0 1 2 3 563 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 |U| VCID NACK (0x0504) | Message Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Message ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Label TLV | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | VCID Message ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Optional Parameters | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Message ID 576 Four octet integer used to identify this message. 578 Label TLV 579 The label TLV contains the VCID value of the received VCID PROPOSE 580 message. Type of label TLV is VCID(0x0203). 582 VCID Message ID 583 This value is the same as that of received VCID PROPOSE message. 585 5.1.5 VPID Propose inband Message 587 This message is sent as a null encapsulation packet with LDP header 588 and label stack header through a VC to be used as an LSP. The label 589 value is 4. The downstream node must distinguish the VPID PROPOSE 590 message from other messages and ignore the VPID PROPOSE message when 591 the node already received the LDP Label Request message for the VC. 593 0 1 2 3 594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 |U|VPID Inband Propose (0x0505) | Message Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Message ID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | VPID TLV | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Optional Parameters | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Message Id 606 Four octet integer used to identify this message. 608 VPID TLV 609 VPID TLV contains VPID value. Type of label TLV is VPID(0x0703). 611 5.1.6 VPID ACK Message 613 An LSR send the VPID ACK message when the LSR accepts the VPID 614 PROPOSE message. 616 0 1 2 3 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |U| VPID ACK (0x0506) | Message Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Message ID | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | VPID TLV | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | VCID Message ID | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Optional Parameters | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Message ID 631 Four octet integer used to identify this message. 633 VPID TLV 634 The VPID TLV contains the VPID value of the received VPID PROPOSE 635 message. 637 VCID Message ID 638 This value is the same as that of received VCID PROPOSE message. 640 5.1.7 VPID NACK Message 642 An LSR send the VPID NACK message when the LSR accepts the VPID 643 PROPOSE message. 645 0 1 2 3 646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 |U| VPID NACK (0x0507) | Message Length | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Message ID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | VPID TLV | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | VCID Message ID | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Optional Parameters | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Message ID 660 Four octet integer used to identify this message. 662 VPID TLV 663 The VPID TLV contains the VPID value of the received VPID PROPOSE 664 message. 666 VCID Message ID 667 This value is the same as that of received VCID PROPOSE message. 669 5.2 Objects 670 5.2.1 VCID Label TLV 672 An LSR uses VCID Label TLV to encode labels for use on the link which 673 does not have the same data link label at both ends of a VC. 675 0 1 2 3 676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |U|F|VCID Label (0x0203) | Length | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | VCID | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 VCID 684 This is 4 byte VCID value. 686 5.2.2 VCID Message ID TLV 688 0 1 2 3 689 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |U|F|VCID Message ID(0x0701) | Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | VCID Message ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 VCID Message ID 697 This is 4 byte VCID Message ID 699 5.2.3 VCID Temporary ID TLV 701 An LSR uses the VCID temporary ID TLV for the VCID notification 702 procedure of the outband notification using a small-sized field. 704 0 1 2 3 705 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |U|F| VCID Temporary ID (0x0702)| Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Temporary ID | 710 +-+-+-+-+-+-+-+-+ 712 Temporary ID: 713 The value carried in the user specific field in the layer 3 714 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 716 5.2.4 VPID Label TLV 718 An LSR uses VPID TLV for the VPID notification procedure. 720 0 1 2 3 721 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 |U|F| VPID (0x0703) | Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | VPID | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 VPID 728 This is 2 byte VPID value. 730 Security Considerations 732 This document does not introduce new security issues other than those 733 present in the LDP and may use the same mechanisms proposed for this 734 technology. 736 Acknowledgments 738 The authors would like to acknowledge the valuable technical comments 739 of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, 740 George Swallow and members of the LAST-WG of the WIDE Project. 742 References 744 [LDP] L. Andersson, et al., "LDP Specification", 745 Work in Progress, June 1999 747 [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label 748 Switching", Work in Progress, June 1999 750 [GIT] M. Suzuki, "The Assignment of the Information Field and 751 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 752 User-to-user Signaling for the Internet Protocol", 753 Work in Progress, July 1999 755 [ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding", 756 Work in Progress, April 1999 758 Authors Information 760 Ken-ichi Nagami 761 Infomation & Communication Lab., Toshiba Corporation, 762 3-1-1 Asahigaoka, Hino, 763 Tokyo, 191-8555, Japan 764 Phone: +81-42-585-3299 765 Email: ken.nagami@toshiba.co.jp 767 Noritoshi Demizu 768 Graduate School of Information Science, 769 Nara Institute of Science and Technology 770 8916-5 Takayama, Ikoma, Nara 630-0101, Japan 771 Phone: +81-743-72-5348 772 Email: nori-d@is.aist-nara.ac.jp 774 Hiroshi Esaki 775 Computer Center, University of Tokyo, 776 2-11-16 Yayoi, Bunkyo-ku, 777 Tokyo, 113-8658, Japan 778 Phone: +81-3-3812-1111 779 Email: hiroshi@wide.ad.jp 781 Yasuhiro Katsube 782 Infomation & Communication Lab., Toshiba Corporation, 783 3-1-1 Asahigaoka, Hino, 784 Tokyo, 191-8555, Japan 785 Phone: +81-42-585-3299 786 Email: yasuhiro.katsube@toshiba.co.jp 788 Paul Doolan 789 Ennovate Networks 790 330 Codman Hill Road 791 Boxborough, MA 792 Phone: 978-263-2002 x103 793 Email: pdoolan@ennovatenetworks.com