idnits 2.17.1 draft-ietf-mpls-vcid-atm-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack 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 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. 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 (October 1999) is 8958 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: Normative reference to a draft: ref. 'VCID' -- Possible downref: Normative reference to a draft: ref. 'VCPOOL' == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-03 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. 'FRAME' == Outdated reference: A later version (-04) exists of draft-ietf-mpls-git-uus-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 April 1999 7 Expires October 1999 9 VCID Notification over ATM link 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. In [VCID], an identifier called a 65 Virtual Connection ID (VCID) is introduced. VCID has the same value 66 at both ends of a VC. 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 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" described in [VCID]. The BLLI 294 value of a new VC must not be assigned to other VCs during the 295 procedure to avoid identifier conflict. When the association among 296 the BLLI value, a VCID value, and the corresponding VC is 297 established, the BLLI value can be reused for a new VC. VCID values 298 can be assigned independently 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. VC pool [VCPOOL] can be applied. 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 LDP. 362 3.2.2 Outband notification using a small-sized field 363 for point-to-multipoint VC 365 This subsection describes procedures for establishing the first VC 366 for a multicast tree and for adding a new VC leaf to an existing VC 367 tree including the notification of its VCID for a multicast stream 368 using point-to-multipoint VCs. 370 In this procedure, an upstream LSR determines both the VCID and BLLI 371 value in the multicast case. The reason that the BLLI value is 372 determined by an upstream LSR is described above. 374 First, the procedure for establishing the first VC is described. 376 1. An upstream LSR establishes a VC by the ATM Forum Signaling between 377 the downstream LSR with a unique BLLI value at this time. 379 2. The upstream LSR notifies the downstream LSR of a paired BLLI 380 value and VCID using a message dedicated for this purpose. 382 3. The downstream LSR establishes the association between the VC with 383 the BLLI value and the VCID and sends an ACK message to the 384 upstream LSR. If the VCID is used by some other VC between the 385 upstream and downstream LSRs, the old VC is discarded. 387 4. After the upstream LSR receives the ACK message, the VC is ready 388 to be used and the BLLI value can be used for another VC. 390 Second, the procedure for adding a leaf to the existing 391 point-to-multipoint VC is described. 393 1. The upstream LSR establishes a VC by the ATM Forum Signaling between 394 its downstream LSR with the BLLI value that was used during the 395 first signaling procedure. If another VC is using the BLLI value 396 at the same time, the upstream waits for the completion of the 397 signaling procedure that is using this BLLI value. 399 2. Go to step 2 of the procedure for the first VC. 401 3.3 Outband notification 403 This method can be applied when a VC is established using a ATM 404 signaling message and the message has a field (e.g., GIT [GIT]) which 405 is large enough to carry a VCID value. Message format is described in 406 [GIT]. After the VCID notification, the node A sends the LDP request 407 message is sent to the node B. Then, the node B sends the LDP mapping 408 message to the node A. 410 Node A Node B 411 | | 412 |--------------->| ATM signaling with VCID 413 |<---------------| 414 | | 415 |--------------->| LDP Label Request 416 | | 417 |<---------------| LDP Label Mapping 419 4 VPID Notification Procedure 421 The approach that is used for the VCID notification procedure is also 422 applicable to share the same identifier between both ends for a VP. 423 VPID notification procedure is defined for this purpose. 425 A distinct VPID notification procedure is performed for each 426 direction of each VP. 428 After the VPID notification is finished for a VP, a VCID of a VC in 429 the VP is constructed with the VPID(MSB) and VCI(LSB) of the VC. The 430 VCID can be used by LDP without performing VCID notification 431 procedure. The message sequence is given below. 433 1. An upstream node sends the VPID PROPOSE message. 434 In the case of bidirectional label switched VC, both the upstream 435 and downstream nodes use VCI=33. In the case of unidirectional 436 label switched VC, the node which has larger LDP Identifier uses 437 VCI=33 and the other node uses VCI=34. Note that VCI=32, which is 438 used for unlabeled packet transfer, is not used for VPID 439 notification procedure so that the same encapsulation method can 440 be applied for both VPID procedure and inband VCID procedure. 442 2. The downstream node sends the VPID ACK message. 444 3. The upstream node sends the LDP Label Request message. 446 4. The downstream node sends the LDP Label Mapping message. 448 5 VCID Message Format 449 5.1 VCID Messages 451 An LDP VCID message consists of the LDP [LDP] fixed header followed 452 by one or more TLV. A VCID PROPOSE inband message and a VPID PROPOSE 453 message are sent as a null encapsulation packet through a VC to be 454 used as an LSP. There is only the label stack header before the LDP 455 VCID PDU. A label value in the label stack entry [ENCAPS] for the 456 VCID PROPOSE inband message and the VPID PROPOSE message are 4. 457 Other messages are sent as TCP packets. This is the same as LDP. 459 The VCID message type field is as follows: 460 VCID Propose inband Message = 0x0501 461 VCID Propose Message = 0x0502 462 VCID ACK Message = 0x0503 463 VCID NACK Message = 0x0504 464 VPID Propose inband Message = 0x0505 465 VPID ACK Message = 0x0506 466 VPID NACK Message = 0x0507 468 5.1.1 VCID Propose inband Message 469 This message is sent as a null encapsulation packet with LDP header 470 and label stack header through a VC to be used as an LSP. The label 471 value is 4. The reserved label value is required because the 472 downstream node may receive this message after receiving the LDP 473 Label Request message in the case of point-to-multipoint VC. The 474 downstream node must distinguish the VCID PROPOSE message from other 475 messages and ignore the VCID PROPOSE message when the node already 476 received the LDP Label Request message for the VC. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |U|VCID Inband Propose (0x0501) | Message Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Message ID | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Label TLV | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Optional Parameters | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Message Id 491 Four octet integer used to identify this message. 493 Label TLV 494 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 496 5.1.2 VCID Propose Message 498 An LSR uses the VCID PROPOSE message for the VCID notification 499 procedure of the outband notification using a small-sized field. 500 This message is sent through the VC for the LDP. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |U| VCID Propose (0x0502) | Message Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Message ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Label TLV | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Temporary ID TLV | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Optional Parameters | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Message ID 517 Four octet integer used to identify this message. 519 Label TLV 520 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 522 Temporary ID TLV 523 The value carried in the user specific field in the layer 3 524 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 525 Type of label TLV is VCID temporary ID(0x0702). 527 5.1.3 VCID ACK Message 529 An LSR send the VCID ACK message when the LSR accepts the VCID 530 PROPOSE message. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |U| VCID ACK (0x0503) | Message Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Message ID | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Label TLV | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | VCID Message ID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Optional Parameters | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Message ID 547 Four octet integer used to identify this message. 549 Label TLV 550 The label TLV contains the VCID value of the received VCID PROPOSE 551 message. Type of label TLV is VCID(0x0203). 553 VCID Message ID 554 This value is the same as that of received VCID PROPOSE message. 556 5.1.4 VCID NACK Message 558 An LSR send the VCID NACK message when the LSR does not accept the 559 VCID PROPOSE message. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 |U| VCID NACK (0x0504) | Message Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Message ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Label TLV | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | VCID Message ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Optional Parameters | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Message ID 575 Four octet integer used to identify this message. 577 Label TLV 578 The label TLV contains the VCID value of the received VCID PROPOSE 579 message. Type of label TLV is VCID(0x0203). 581 VCID Message ID 582 This value is the same as that of received VCID PROPOSE message. 584 5.1.5 VPID Propose inband Message 586 This message is sent as a null encapsulation packet with LDP header 587 and label stack header through a VC to be used as an LSP. The label 588 value is 4. The downstream node must distinguish the VPID PROPOSE 589 message from other messages and ignore the VPID PROPOSE message when 590 the node already received the LDP Label Request message for the VC. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |U|VPID Inband Propose (0x0505) | Message Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Message ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | VPID TLV | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Optional Parameters | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Message Id 605 Four octet integer used to identify this message. 607 VPID TLV 608 VPID TLV contains VPID value. Type of label TLV is VPID(0x0703). 610 5.1.6 VPID ACK Message 612 An LSR send the VPID ACK message when the LSR accepts the VPID 613 PROPOSE message. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |U| VPID ACK (0x0506) | Message Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Message ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | VPID TLV | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | VCID Message ID | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Optional Parameters | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Message ID 630 Four octet integer used to identify this message. 632 VPID TLV 633 The VPID TLV contains the VPID value of the received VPID PROPOSE 634 message. 636 VCID Message ID 637 This value is the same as that of received VCID PROPOSE message. 639 5.1.7 VPID NACK Message 641 An LSR send the VPID NACK message when the LSR accepts the VPID 642 PROPOSE message. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |U| VPID NACK (0x0507) | Message Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Message ID | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | VPID TLV | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | VCID Message ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Optional Parameters | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Message ID 659 Four octet integer used to identify this message. 661 VPID TLV 662 The VPID TLV contains the VPID value of the received VPID PROPOSE 663 message. 665 VCID Message ID 666 This value is the same as that of received VCID PROPOSE message. 668 5.2 Objects 669 5.2.1 VCID Label TLV 671 An LSR uses VCID Label TLV to encode labels for use on the link which 672 does not have the same data link label at both ends of a VC. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 |U|F|VCID Label (0x0203) | Length | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | VCID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 VCID 683 This is 4 byte VCID value. 685 5.2.2 VCID Message ID TLV 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 |U|F|VCID Message ID(0x0701) | Length | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | VCID Message ID | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 VCID Message ID 696 This is 4 byte VCID Message ID 698 5.2.3 VCID Temporary ID TLV 700 An LSR uses the VCID temporary ID TLV for the VCID notification 701 procedure of the outband notification using a small-sized field. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |U|F| VCID Temporary ID (0x0702)| Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Temporary ID | 709 +-+-+-+-+-+-+-+-+ 711 Temporary ID: 712 The value carried in the user specific field in the layer 3 713 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 715 5.2.4 VPID Label TLV 717 An LSR uses VPID TLV for the VPID notification procedure. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |U|F| VPID (0x0703) | Length | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | VPID | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 VPID 727 This is 2 byte VPID value. 729 Security Considerations 731 Security issues are not discussed in this document. 733 Acknowledgments 735 The authors would like to acknowledge the valuable technical comments 736 of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, 737 George Swallow and members of the LAST-WG of the WIDE Project. 739 References 741 [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", 742 draft-demizu-mpls-vcid-01.txt, Oct. 1997 744 [VCPOOL] N. Demizu, et al., "VC pool", 745 draft-demizu-mpls-vcpool-00.txt, Oct. 1997 747 [LDP] L. Andersson, et al., "LDP Specification", 748 draft-ietf-mpls-ldp-03.txt, Jan. 1999 750 [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label 751 Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 753 [GIT] M. Suzuki, "The Assignment of the Information Field and 754 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 755 User-to-user Signaling for the Internet Protocol", 756 draft-ietf-mpls-git-uus-02.txt, March 1999 758 [ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding", 759 draft-ietf-mpls-label-encaps-03.txt, Sep. 1998 761 Authors Information 763 Ken-ichi Nagami 764 Infomation & Communication Lab., Toshiba Corporation, 765 3-1-1 Asahigaoka, Hino, 766 Tokyo, 191-8555, Japan 767 Phone: +81-42-585-3299 768 Email: ken.nagami@toshiba.co.jp 770 Noritoshi Demizu 771 Graduate School of Information Science, 772 Nara Institute of Science and Technology 773 8916-5 Takayama, Ikoma, Nara 630-0101, Japan 774 Phone: +81-743-72-5348 775 Email: nori-d@is.aist-nara.ac.jp 776 Hiroshi Esaki 777 Computer Center, University of Tokyo, 778 2-11-16 Yayoi, Bunkyo-ku, 779 Tokyo, 113-8658, Japan 780 Phone: +81-3-3812-1111 781 Email: hiroshi@wide.ad.jp 783 Yasuhiro Katsube 784 Infomation & Communication Lab., Toshiba Corporation, 785 3-1-1 Asahigaoka, Hino, 786 Tokyo, 191-8555, Japan 787 Phone: +81-42-585-3299 788 Email: yasuhiro.katsube@toshiba.co.jp 790 Paul Doolan 791 Ennovate Networks 792 330 Codman Hill Road 793 Boxborough, MA 794 Phone: 978-263-2002 x103 795 Email: pdoolan@ennovatenetworks.com