idnits 2.17.1 draft-ietf-mpls-vcid-atm-02.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-04-25) 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 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 3 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 (June 1999) is 9081 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-02 == 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-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 Summary: 11 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 December 1998 7 Expires June 1999 9 VCID Notification over ATM link 10 12 Status of this memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 The ATM Label Switching Router (ATM-LSR) is one of the major 33 applications of label switching. Because the ATM layer labels (VPI 34 and VCI) associated with a VC rewritten with new value at every ATM 35 switch nodes, it is not possible to use them to identify a VC in 36 label mapping messages. The concept of Virtual Connection Identifier 37 (VCID) is introduced to solve this problem. VCID has the same value 38 at both ends of a VC. This document specifies the procedures for the 39 communication of VCID values between neighboring ATM-LSRs that must 40 occur in order to ensure this property. 42 1. Introduction 44 Several label switching schemes have been proposed to integrate Layer 45 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the 46 major applications of label switching. 48 In the case of ATM VCs, the VPI and VCI labels are, in the general 49 case, rewritten with new values at every switch node through which 50 the VC passes and cannot be used to provide end to end 51 identification of a VC. 53 In the context of MPLS 'stream', which are classes of packets that 54 have some common characteristic that may be deduced by examination 55 of the layer 3 header in the packets, are bound to layer 2 'labels'. 56 We speak of stream being 'bound' to labels. These bindings are 57 conveyed between peer LSRs by means of a Label Distribution Protocol 58 [LDP]. 60 In order to apply MPLS to ATM links, we need some way to identify ATM 61 VCs in LDP mapping messages. In [VCID], an identifier called a 62 Virtual Connection ID (VCID) is introduced. VCID has the same value 63 at both ends of a VC. This document specifies the procedures for 64 the communication of VCID values between neighboring ATM-LSRs that 65 must occur in order to ensure this property. 67 2. Overview of VCID Notification Procedures 69 2.1 VCID Notification procedures 71 The ATM has several types of VCs (transparent point-to-point 72 link/VP/PVC/SVC). A transparent point-to-point link is defined as one 73 that has the same VPI/VCI label at both ends of a VC. For example, 74 two nodes are directly connected (i.e., without intervening ATM 75 switches) or are connected through a VP with the same VPI value at 76 both ends of the VP. 78 There are two broad categories of VCID notification procedures; 79 inband and outband. The categorization refers to the connection 80 over which the messages of the VCID notification procedure are 81 forwarded. In the case of the inband procedures, those messages are 82 forwarded over the VC to which they refer. In contrast the out of 83 band procedures transmit the messages over some other connection 84 (than the VC to which they refer). 86 We list below the various types of link and briefly mention the VCID 87 notification procedures employed and the rational for that 88 choice. The procedures themselves are discussed in detail in later 89 sections. 91 Transparent point-to-point link : no VCID notification 92 VCID notification procedure is not necessary because the label 93 (i.e., VPI/VCI) is the same at each end of the VC. 95 VP : inband notification or no notification 96 - Inband notification 97 VCID notification is needed because the VPI at each end of the VC 98 may not be the same. Inband VCID notification [VCID] is used in 99 this case. 101 - No notification 102 If a node has only one VP to a neighboring node, VCID notification 103 procedure is not mandatory. The VCI can be used as the VCID. This 104 is because the VCI value is the same at each end of the VP. 106 PVC : inband notification 107 Inband VCID notification [VCID] is used in this case because the 108 labels at each end of the VC may not be the same. 110 SVC : there are three possibilities 111 - Outband notification 112 If a signaling message has a field which is large enough to carry 113 a VCID value (e.g., GIT [GIT]), then the VCID is carried directly 114 in it. 116 - Outband notification using a small-sized field 117 If a signaling message has a field which is not large enough to 118 carry a VCID value, this procedure is used. 120 - Inband notification 121 If a signaling message can not carry user information, this 122 procedure is used. 124 When an LSP is a point-to-multipoint VC and an ATM switch in an 125 LSR is not capable of VC merge, it may cause problems in 126 performance and quality of service. When the LSR wants to add a 127 new leaf to the LSP, it needs to split the active LSP temporarily 128 to send an inband notification message. 130 3. VCID Notification Procedures 132 3.1 Inband Notification Procedures 134 3.1.1 Inband Notification for Point-to-point VC 136 VCID notification is performed by transmitting a control message 137 through the VC newly established (by signalling or management) for 138 use as an label switched path (LSP) [FRAME]. The procedure for VCID 139 notification between two nodes A and B is detailed below. 141 0. The node A establishes a VC to the destination node B. (by signalling 142 or management) 144 1. The node A selects a VCID value. 146 2. The node A sends a VCID PROPOSE message which contains the VCID 147 value and a message ID through the newly established VC to the 148 node B. 150 3. The node A establishes an association between the outgoing label 151 (VPI/VCI) for the VC and the VCID value. 153 4. The node B receives the message from the VC and establishes an 154 association between the VCID in the message and the incoming 155 label(VPI/VCI) for the VC. Until the node B receives the LDP 156 Request message, the node B discards any packet received over the 157 VC other than the VCID PROPOSE message. 159 5. The node B sends an ACK message to the node A. This message 160 contains the same VCID and message ID as specified in the received 161 message. This message is sent through the VC for LDP. 163 6. When node A receives the ACK message, it checks whether the VCID 164 and the message ID in the message are the same as the registered 165 ones. If they are the same, node A regards that node B has 166 established the association between the VC and VCID. Otherwise, 167 the message is ignored. If the node A does not receive the ACK 168 message with the expected message ID and VCID during a given 169 period, the node A resends the VCID PROPOSE message to the node B. 171 7. After receiving the proposer ACK message, the node A sends an LDP 172 REQUEST message to the node B. It contains the message ID used for 173 VCID PROPOSE. When the node B receives the LDP REQUEST message, 174 it regards that the node A has received the ACK correctly. The 175 message exchange using VCID PROPOSE, VCID ACK, and LDP REQUEST 176 messages constitutes a 3-way handshake. The 3-way handshake 177 mechanism is required since the transmission of VCID PROPOSE 178 message is unreliable. Once the 3-way handshake completes, the 179 node B ignores all VCID PROPOSE messages received over the VC. The 180 node B sends an LDP Mapping message, which contains the VCID value 181 in the label TLV. 183 Node A Node B 184 | | 185 |--------------->| VCID PROPOSE 186 | | 187 |<---------------| VCID ACK 188 | | 189 |--------------->| LDP Label Request 190 | | 191 |<---------------| LDP Label Mapping 193 3.1.2 Inband notification for point-to-multipoint VC 195 Current LDP specification does not support multicast. But the VCID 196 notification procedure is defined for future use. VCID notification 197 is performed by sending a control message through the VC to be used 198 as an LSP. The upstream node assigns the VCID value. The procedure by 199 which it notifies the downstream node of that value is given 200 below. The procedure is used when a new VC is created or a new leaf 201 is added to the VC. 203 First, the procedure for establishing the first VC is described. 205 1. The upstream node assigns a VCID value for the VC. When the VCID 206 value is already assigned to a VC, it is used for VCID. 208 2. The upstream node sends a message which contains the VCID value 209 and a message ID through the VC used for an LSP. This message is 210 transferred to all leaf nodes. 212 3. The upstream node establishes an association between the outgoing 213 label for the VC and the VCID value. 215 4. When the downstream nodes receiving the message already received 216 the LDP REQUEST message for the VC, the received message is 217 discarded. Otherwise, the downstream nodes establish an 218 association between the VCID in the message and the VC from which 219 the message is received. 221 5. The downstream nodes send an ACK message to the upstream node. 223 6. After the upstream node receives the ACK messages, the upstream 224 node and the downstream nodes share the VCID. The upstream node 225 sends the LDP REQUEST message in order to make a 3-way handshake. 227 Upstream Downstream 1 Downstream 2 228 | | | 229 |-----------+--->| | VCID PROPOSE 230 | +------------------->| 231 | | | 232 |<---------------| | 233 | VCID ACK | | 234 |<-------------------------------| VCID ACK 236 Second, the procedure for adding a leaf to the existing 237 point-to-multipoint VC is described. 239 0. The upstream node adds the downstream node, using the ATM 240 signaling. 242 1. The VCID value which already assigned to the VC is used. 244 2. The upstream node sends a message which contains the VCID value 245 and a message ID through the VC used for an LSP. This message is 246 transferred to all leaf nodes. 248 3. When the downstream nodes receiving the message already received 249 the LDP REQUEST message for the VC, the received message is 250 discarded. Otherwise, the downstream nodes establish an 251 association between the VCID in the message and the VC from which 252 the message is received. 254 4. After the upstream node receives the ACK messages, the upstream 255 node and the downstream nodes share the VCID. The upstream node 256 sends the LDP REQUEST message in order to make a 3-way handshake. 258 3.2 Outband Notification using a small-sized field 260 This method can be applied when a VC is established using an ATM 261 signaling message and the message has a field which is not large 262 enough to carry a VCID value. 264 SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory 265 field for the user. This is a user specific field in the Layer 3 266 protocol field in the BLLI IE (Broadband Low Layer Information 267 Information Element). 269 The BLLI value is used as a temporary identifier for a VC during a 270 VCID notification procedure. This mechanism is defined as "Outband 271 Notification using a small-sized field" described in [VCID]. The BLLI 272 value of a new VC must not be assigned to other VCs during the 273 procedure to avoid identifier conflict. When the association among 274 the BLLI value, a VCID value, and the corresponding VC is 275 established, the BLLI value can be reused for a new VC. VCID values 276 can be assigned independently from BLLI values. 278 Node A Node B 279 | | 280 |--------------->| ATM Signaling with BLLI 281 |<---------------| 282 | | 283 |--------------->| VCID PROPOSE with BLLI 284 | | 285 |<---------------| VCID ACK 286 | | 287 |--------------->| LDP Label Request 288 | | 289 |<---------------| LDP Label Mapping 291 A point-to-multipoint VC can also be established using ADD_PARTY of 292 the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC 293 or an existing VC tree. In this procedure, the BLLI value of 294 ADD_PARTY has to be the same value as that used to establish the 295 first point-to-point VC of the tree. The same BLLI value can be used 296 in different VC trees only when these VC trees can not add a leaf at 297 the same time. As a result, the BLLI value used in the signaling must 298 be determined by the root node of the multicast tree. 300 [note] 301 BLLI value is unique at the sender node. But BLLI value is not 302 unique at the receiver node because multiple sender nodes may 303 allocate the same BLLI value. So, the receiver node must 304 recognize BLLI value and the sender address. ATM Signaling 305 messages(SETUP and ADD_PARTY) carry both the BLLI and the sender 306 ATM address. The receiver node can realize which node sends the 307 BLLI message. 309 3.2.1 Outband notification using a small-sized field for point-to-point VC 311 This subsection describes procedures for establishing a VC and for 312 notification of its VCID between neighboring LSRs for unicast 313 traffic. VC pool [VCPOOL] can be applied. 315 The procedure employed when the upstream LSR assigns a VCID is as 316 follows. 318 1. An upstream LSR establishes a VC to the downstream LSR using ATM 319 signaling and supplies a value in the BLLI field that it is not 320 currently using for any other (incomplete) VCID notification 321 transaction with this peer. 323 2. The upstream LSR sends the VCID PROPOSE message through the VC for 324 LDP to notify the downstream LSR of the association 325 between the BLLI and VCID values. 327 3. The downstream LSR establishes the association between the VC 328 with the BLLI value and the VCID and sends an ACK message to the 329 upstream LSR. 331 4. After the upstream LSR receives the ACK message, it establishes 332 the association between the VC and the VCID. The VC is ready to 333 be used. At this time the BLLI value employed in this transaction 334 is free for reuse. 336 5. After VCID notification, the upstream node sends the LDP REQUEST 337 message to the downstream node. The downstream node sends the LDP 338 mapping message, which contains the VCID value in the label TLV of LDP. 340 3.2.2 Outband notification using a small-sized field 341 for point-to-multipoint VC 343 This subsection describes procedures for establishing the first VC 344 for a multicast tree and for adding a new VC leaf to an existing VC 345 tree including the notification of its VCID for a multicast stream 346 using point-to-multipoint VCs. 348 In this procedure, an upstream LSR determines both the VCID and BLLI 349 value in the multicast case. The reason that the BLLI value is 350 determined by an upstream LSR is described above. 352 First, the procedure for establishing the first VC is described. 354 1. An upstream LSR establishes a VC by the ATM Forum Signaling between 355 the downstream LSR with a unique BLLI value at this time. 357 2. The upstream LSR notifies the downstream LSR of a paired BLLI 358 value and VCID using a message dedicated for this purpose. 360 3. The downstream LSR establishes the association between the VC with 361 the BLLI value and the VCID and sends an ACK message to the 362 upstream LSR. If the VCID is used by some other VC between the 363 upstream and downstream LSRs, the old VC is discarded. 365 4. After the upstream LSR receives the ACK message, the VC is ready 366 to be used and the BLLI value can be used for another VC. 368 Second, the procedure for adding a leaf to the existing 369 point-to-multipoint VC is described. 371 1. The upstream LSR establishes a VC by the ATM Forum Signaling between 372 its downstream LSR with the BLLI value that was used during the 373 first signaling procedure. If another VC is using the BLLI value 374 at the same time, the upstream waits for the completion of the 375 signaling procedure that is using this BLLI value. 377 2. Go to step 2 of the procedure for the first VC. 379 3.3 Outband notification 381 This method can be applied when a VC is established using a ATM 382 signaling message and the message has a field (e.g., GIT [GIT]) which 383 is large enough to carry a VCID value. Message format is described in 384 [GIT]. After the VCID notification, the node A sends the LDP request 385 message is sent to the node B. Then, the node B sends the LDP mapping 386 message to the node A. 388 Node A Node B 389 | | 390 |--------------->| ATM signaling with VCID 391 |<---------------| 392 | | 393 |--------------->| LDP Label Request 394 | | 395 |<---------------| LDP Label Mapping 397 4 VCID Message Format 398 4.1 VCID Messages 400 An LDP VCID message consists of the LDP [LDP] fixed header followed 401 by one or more VCID TLV. VCID PROPOSE inband message is sent as a 402 null encapsulation packet through a VC to be used as an LSP. There is 403 only the label stack header before the LDP VCID PDU. A label value in 404 the label stack entry [ENCAPS] for VCID PROPOSE inband message is 4. 405 Other messages are sent as TCP packets. This is the same as LDP. 407 The VCID message type field is as follows: 408 VCID Propose inband Message = 0x0501 409 VCID Propose Message = 0x0502 410 VCID ACK Message = 0x0503 411 VCID NACK Message = 0x0504 413 4.1.1 VCID Propose inband Message 415 This message is sent as a null encapsulation packet with LDP header 416 and label stack header through a VC to be used as an LSP. The label 417 value is 4. The reserved label value is required because the 418 downstream node may receive this message after receiving the LDP 419 Label Request message in the case of point-to-multipoint VC. The 420 downstream node must distinguish the VCID PROPOSE message from other 421 messages and ignore the VCID PROPOSE message when the node already 422 received the LDP Label Request message for the VC. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |U|VCID Inband Propose (0x0501) | Message Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Message ID | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Label TLV | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Optional Parameters | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Message Id 437 Four octet integer used to identify this message. 439 Label TLV 440 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 442 4.1.2 VCID Propose Message 444 An LSR uses the VCID PROPOSE message for the VCID notification 445 procedure of the outband notification using a small-sized field. 446 This message is sent through the VC for the LDP. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |U| VCID Propose (0x0502) | Message Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Message ID | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Label TLV | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Temporary ID TLV | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Optional Parameters | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Message Id 463 Four octet integer used to identify this message. 465 Label TLV 466 Label TLV contains VCID value. Type of label TLV is VCID(0x0203). 468 Temporary ID TLV 469 The value carried in the user specific field in the layer 3 470 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 471 Type of label TLV is VCID temporary ID(0x0902). 473 4.1.3 VCID ACK Message 475 An LSR send the VCID ACK message when the LSR accepts the VCID 476 PROPOSE message. 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 ACK (0x0503) | 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. This value is the 492 same as that of received VCID PROPOSE message. 494 Label TLV 495 The label TLV contains the VCID value of the received VCID PROPOSE 496 message. Type of label TLV is VCID(0x0203). 498 4.1.4 VCID NACK Message 500 An LSR send the VCID NACK message when the LSR does not accept the 501 VCID PROPOSE message. 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 NACK (0x0504) | Message Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Message ID | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Label TLV | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Optional Parameters | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Message Id 516 Four octet integer used to identify this message. This value is the 517 same as that of received VCID PROPOSE message. 519 Label TLV 520 The label TLV contains the VCID value of the received VCID PROPOSE 521 message. Type of label TLV is VCID(0x0203). 523 4.2 Objects 524 4.2.1 VCID Label TLV 526 An LSR uses VCID Label TLV to encode labels for use on the link which 527 does not have the same data link label at both ends of a VC. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 |U|F|VCID Label (0x0203) | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | VCID | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 VCID 538 This is 4 byte VCID value. 540 4.2.2 VCID Temporary ID TLV 542 An LSR uses the VCID temporary ID TLV for the VCID notification 543 procedure of the outband notification using a small-sized field. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |U|F| VCID Temporary ID (0x0601)| Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Temporary ID | 551 +-+-+-+-+-+-+-+-+ 553 Temporary ID: 554 The value carried in the user specific field in the layer 3 555 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 557 Security Considerations 559 Security issues are not discussed in this document. 561 Intellectual Property Considerations 563 Toshiba Corporation and Ennovate Networks may seek patent or other 564 intellectual property protection for some of the aspects of the 565 technology discussed in this document. If any standards arising from 566 this document are or become protected by one or more patents assigned 567 to Toshiba Corporation, Toshiba intends to license them on reasonable 568 and non- discriminatory terms. 570 Acknowledgments 571 The authors would like to acknowledge the valuable technical comments 572 of Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, George Swallow 573 and members of the LAST-WG of the WIDE Project. 575 References 577 [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", 578 draft-demizu-mpls-vcid-01.txt, Oct. 1997 580 [VCPOOL] N. Demizu, et al., "VC pool", 581 draft-demizu-mpls-vcpool-00.txt, Oct. 1997 583 [LDP] L. Andersson, et al., "LDP Specification", 584 draft-ietf-mpls-ldp-02.txt, Nov. 1998 586 [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label 587 Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 589 [GIT] M. Suzuki, "The Assignment of the Information Field and 590 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 591 User-to-user Signaling for the Internet Protocol", 592 draft-ietf-mpls-git-uus-01.txt, Dec. 1998 594 [ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding", 595 draft-ietf-mpls-label-encaps-03.txt, Sep. 1998 597 Authors Information 599 Ken-ichi Nagami 600 Infomation & Communication Lab., Toshiba Corporation, 601 3-1-1 Asahigaoka, Hino, 602 Tokyo, 191-8555, Japan 603 Phone: +81-42-585-3299 604 Email: ken.nagami@toshiba.co.jp 606 Noritoshi Demizu 607 Graduate School of Information Science, 608 Nara Institute of Science and Technology 609 8916-5 Takayama, Ikoma, Nara 630-0101, Japan 610 Phone: +81-743-72-5348 611 Email: nori-d@is.aist-nara.ac.jp 613 Hiroshi Esaki 614 Computer Center, University of Tokyo, 615 2-11-16 Yayoi, Bunkyo-ku, 616 Tokyo, 113-8658, Japan 617 Phone: +81-3-3812-1111 618 Email: hiroshi@wide.ad.jp 620 Yasuhiro Katsube 621 Infomation & Communication Lab., Toshiba Corporation, 622 3-1-1 Asahigaoka, Hino, 623 Tokyo, 191-8555, Japan 624 Phone: +81-42-585-3299 625 Email: yasuhiro.katsube@toshiba.co.jp 627 Paul Doolan 628 Ennovate Networks 629 330 Codman Hill Road 630 Boxborough, MA 631 Phone: 978-263-2002 x103 632 Email: pdoolan@ennovatenetworks.com