idnits 2.17.1 draft-ietf-mpls-vcid-atm-01.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-26) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 705 lines 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 26 instances of too long lines in the document, the longest one being 3 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 (February 1999) is 9202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LDP' is mentioned on line 396, but not defined == Missing Reference: 'RFC1700' is mentioned on line 580, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Normative reference to a draft: ref. 'VCID' -- Possible downref: Normative reference to a draft: ref. 'VCPOOL' == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. 'FRAME' -- No information found for draft-ietf-mpls-git-uus-assignment - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GIT' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-02 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Ken-ichi Nagami (Toshiba Corp.) 2 INTERNET DRAFT Noritoshi Demizu (NAIST) 3 Hiroshi Esaki (Toshiba Corp.) 4 Paul Doolan (Ennovate Networks) 5 August 1998 6 Expires February 1999 8 VCID Notification over ATM link 9 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 The ATM Label Switching Router (ATM-LSR) is one of the major 32 applications of label switching. Because the ATM layer labels (VPI 33 and VCI) associated with a VC may change on each VC of that VC, it is 34 not possible to use them to identify a VC in label binding 35 messages. The concept of Virtual Connection Identifier (VCID) is 36 introduced to solve this problem. VCID has the same value at both 37 ends of a VC. This document specifies the procedures for the 38 communication of VCID values between neighboring ATM-LSRs that must 39 occur in order to ensure this property. 41 1. Introduction 43 Several label switching schemes have been proposed to integrate Layer 44 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the 45 major applications of label switching. 47 In the case of ATM VCs, the VPI and VCI labels are, in the general 48 case, rewritten with new values at every switch node through which 49 the VC passes and cannot be used to provide end to end 50 identification of a VC. 52 In the context of MPLS 'stream', which are classes of packets that 53 have some common charachteristic that may be deduced by examination 54 of the layer 3 header in the packets, are bound to layer 2 'labels'. 55 We speak of stream being 'bound' to labels. These bindings are 56 conveyed between peer LSRs by means of a Label Distribution Protocol 57 [LDP]. 59 In order to apply MPLS to ATM links, we need some way to identify ATM 60 VCs in LDP binding messages. In [VCID], an identifier called a 61 Virtual Connection ID (VCID) is introduced. VCID has the same value 62 at both ends of a VC. This document specifies the procedures for 63 the communication of VCID values between neighboring ATM-LSRs that 64 must occur in order to ensure this property. 66 2. Overview of VCID Notification Procedures 68 2.1 VCID Notification procedures 70 The ATM has several types of VCs (transparent point-to-point 71 link/VP/PVC/SVC). A transparent point-to-point link is defined as one 72 that has the same VPI/VCI label at both ends of a VC. For example, 73 two nodes are directly connected (i.e., without intervening ATM 74 switches) or are connected through a VP with the same VPI value at 75 both ends of the VP. 77 There are two broad categories of VCID notification procedures; 78 inband and out of band. The categorisation refers to the connection 79 over which the messages of the VCID notification procedure are 80 forwarded. In the case of the inband procedures, those messages are 81 forwarded over the VC to which they refer. In contrast the out of 82 band procedures transmit the messages over some other connection 83 (than the VC to which they refer). 85 We list below the various types of link and briefly mention the VCID 86 notification procedures employed and the rational for that 87 choice. The procedures themselves are discussed in detail in later 88 sections. 90 Transparent point-to-point link : no VCID notification 91 VCID notification procedure is not necessary because the label 92 (i.e., VPI/VCI) is the same at each end of the VC. 94 VP : inband notification (as a default mechanism) 95 - Inband notification 96 VCID notification is needed because the VPI at each end of the VC 97 may not be the same. Inband VCID notification [VCID] is used in 98 this case. 100 - No notification 101 If a node has only one VP to a neighboring node, VCID notification 102 procedure is not mandatory. The VCI can be used as the VCID. This 103 is because the VCI value is the same at each end of the VP. 105 PVC : inband notification 106 Inband VCID notification [VCID] is used in this case because the 107 labels at each end of the VC may not be the same. 109 SVC : there are three possibilities 110 - Out of band notification 111 If a signaling message has a field which is large enough to carry 112 a VCID value (e.g., GIT [GIT]), then the VCID is carried directly 113 in it. 115 - Outband notification using a small-sized field 116 If a signaling message has a field which is not large enough to 117 carry a VCID value, this procedure is used. 119 - Inband notification 120 If a signaling message can not carry user information, this 121 procedure is used. 123 When an LSP is a point-to-multipoint VC and an ATM switch in an 124 LSR is not capable of VC merge, it may cause problems in 125 performance and quality of service. When the LSR wants to add a 126 new leaf to the LSP, it needs to split the active LSP temporarily 127 to send an inband notification message. 129 2.2 VCID Assignment 131 A VCID value is assigned by either an upstream node or a downstream 132 node depending on the type of VC. For a point-to-point VC, either 133 the upstream node or the downstream node could assign a VCID 134 value. For a point-to-multipoint VC, only an upstream (root) node can 135 assign a VCID value. 137 3. VCID Notification Procedures 139 3.1 Inband Notification Procedures 141 3.1.1 Inband Notification for Point-to-point VC 143 VCID notification is performed by transmitting a control message 144 through the VC newly established (by signalling or management) for 145 use as an label switched path (LSP) [FRAME], The procedure for VCID 146 notification between two nodes A and B is detailed below. 148 0. Node A establishes a VC to the destination LSR B. (by signalling 149 or management) 151 1. Node A selects a VCID value. 153 2. Node A sends a message which contains the VCID value through the 154 newly established VC to Node B. 156 3. Node A establishes an association between the outgoing label 157 (VPI/VCI) for the VC and the VCID value. 159 4. Node B receives the message from the VC and establishes an 160 association between the VCID in the message and the incomming 161 label(VPI/VCI) for the VC. 163 5. Node B sends an ACK message to node A. 165 6. After Node A receives the ACK message, node A and node B both 166 associate the VCID with the same VC. 168 Node A Node B 169 | | 170 |--------------->| 171 | VCID | 172 | | 173 |<---------------| 174 | ACK | 176 3.1.2 Inband notification for point-to-multipoint VC 178 VCID notification is performed by sending a control message through 179 the VC to be used as an LSP. The upstream node must assign the VCID 180 value. The procedure by which it notifies the downstream node of that 181 value is given below. The procedure is used when a new VC is created 182 or a new leaf is added to the VC. 184 First, the procedure for establishing the first VC is described. 186 1. The upstream node assigns a VCID value for the VC. When the VCID 187 value is already assigned to a VC, it is used for VCID. 189 2. The upstream node sends a message which contains the VCID value 190 and the address of the upstream node through the VC used for a 191 label switched path. This message is transferred to all leaf 192 nodes. 194 3. The upstream node establishes an association between the outgoing 195 label for the VC and the VCID value. 197 4. The downstream nodes receiving the message check the address of 198 the upstream node. If the address is not the same network prefix 199 as its address, the message is discarded. Otherwise, the 200 downstream nodes establish an association between the VCID in the 201 message and the VC from which the message is received. 203 5. The downstream nodes send an ACK message to the upstream node. 205 6. After the upstream node receives the ACK messages, the upstream 206 node and the downstream nodes share the VCID. 208 Upstream Downstream 1 Downstream 2 209 | | | 210 |-----------+--->| | 211 | VCID +------------------->| 212 | | | 213 |<---------------| | 214 | ACK | | 215 |<-------------------------------| 216 | ACK | 218 Second, the procedure for adding a leaf to the existing 219 point-to-multipoint VC is described. 221 0. The upstream node adds the downstream node, using the ATM 222 signaling. 224 1. The VCID value which already assigned to the VC is used. 226 2. The upstream node sends a message which contains the VCID value 227 and the address of the upstream node through the VC used for a 228 label switched path. This message is transferred to all leaf 229 nodes. 231 3. The downstream nodes receiving the message check the address of 232 the upstream node. If the address is not the same network prefix 233 as its address, the message is discarded. Otherwise, the 234 downstream nodes establish an association between the VCID in the 235 message and the VC from which the message is received. 237 4. After the upstream node receives the ACK messages, the upstream 238 node and the downstream nodes share the VCID. 240 3.2 Outband Notification using a small-sized field 242 This method can be applied when a VC is established using an ATM 243 signaling message and the message has a field which is not large 244 enough to carry a VCID value. 246 SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory 247 field for the user. This is a user specific field in the Layer 3 248 protocol field in the BLLI IE (Broadband Low Layer Information 249 Information Element). 251 The BLLI value is used as a temporary identifier for a VC during a 252 VCID notification procedure. This mechanism is defined as "Outband 253 Notification using a small-sized field" described in [VCID]. The BLLI 254 value of a new VC must not be assigned to other VCs during the 255 procedure to avoid identifier conflict. When the association among 256 the BLLI value, a VCID value, and the corresponding VC is 257 established, the BLLI value can be reused for a new VC. VCID values 258 can be assigned independently from BLLI values. 260 Node A Node B 261 | | 262 |<-------------->| 263 | ATM Signaling | 264 | with BLLI | 265 | | 266 |--------------->| 267 | BLLI & VCID | 268 | | 269 |<---------------| 270 | ACK | 272 A point-to-multipoint VC can also be established using ADD_PARTY of 273 the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC 274 or an existing VC tree. In this procedure, the BLLI value of 275 ADD_PARTY has to be the same value as that used to establish the 276 first point-to-point VC of the tree. The same BLLI value can be used 277 in different VC trees only when these VC trees can not add a leaf at 278 the same time. As a result, the BLLI value used in the signaling must 279 be determined by the root node of the multicast tree. 281 [note] 282 BLLI value is unique at the sender node. But BLLI value is not 283 unique at the reciever node because multiple sender nodes may 284 allocate the same BLLI value. So, the receiver node must 285 recognize BLLI value and the sender address. ATM Signaling 286 messages(SETUP and ADD_PARTY) carry both the BLLI and the sender 287 ATM address. The receiver node can realize which node sends the 288 BLLI message. 290 3.2.1 Outband notification using a small-sized field for point-to-point VC 292 This subsection describes procedures for establishing a VC and for 293 notification of its VCID between neighboring LSRs for unicast 294 traffic. VC pool [VCPOOL] can be applied. 296 For point-to-point VC, either an upstream LSR or a downstream LSR can 297 allocate a VCID for a new VC. 299 The procedure employed when the upstream LSR assigns a VCID is as 300 follows. 302 1. An upstream LSR establishes a VC to the downstream LSR using ATM 303 signaling and supplies a value in the BLLI field that it is not 304 currently using for any other (incomplete) VCID notification 305 transaction with this peer. 307 2. The upstream LSR notifies the downstream LSR of the association 308 between the BLLI and VCID values. 310 3. The downstream LSR establishes the association between the VC 311 with the BLLI value and the VCID and sends an ACK message to the 312 upstream LSR. If the VCID is associated with some other VC 313 between the upstream and downstream LSRs, that old VC is removed 314 from service. 316 4. After the upstream LSR receives the ACK message, it establishes 317 the association between the VC and the VCID. The VC is ready to 318 be used. At this time the BLLI value employed in this transaction 319 is free for reuse. 321 The procedure employed when a downstream LSR assigns a VCID is 322 as follows: 324 1. An upstream LSR establishes a VC by ATM signaling between the 325 downstream LSR with a unique BLLI value at this time. 327 2. The downstream LSR notifies the upstream LSR of a paired BLLI 328 value and VCID using a message dedicated for this purpose. 330 3. The upstream LSR establishes the association between the VC with 331 the BLLI value and the VCID and sends an ACK message to the 332 downstream LSR. If the VCID is associated with some other VC 333 between the upstream and downstream LSRs, that old VC is removed 334 from service. 336 4. After the downstream LSR receives the ACK message, it establishes 337 the association between the VC and the VCID. The VC is ready to 338 be used.At this time the BLLI value employed in this transaction 339 is free for reuse. 341 3.2.2 Outband notification using a small-sized field 342 for point-to-multipoint VC 344 This subsection describes procedures for establishing the first VC 345 for a multicast tree and for adding a new VC leaf to an existing VC 346 tree including the notification of its VCID for a multicast stream 347 using point-to-multipoint VCs. 349 In this procedure, an upstream LSR determines both the VCID and BLLI 350 value in the multicast case. The reason that the BLLI value is 351 determined by an upstream LSR is described above. 353 First, the procedure for establishing the first VC is described. 355 1. An upstream LSR establishes a VC by the ATM Forum Signaling between 356 the downstream LSR with a unique BLLI value at this time. 358 2. The upstream LSR notifies the downstream LSR of a paired BLLI 359 value and VCID using a message dedicated for this purpose. 361 3. The downstream LSR establishes the association between the VC with 362 the BLLI value and the VCID and sends an ACK message to the 363 upstream LSR. If the VCID is used by some other VC between the 364 upstream and downstream LSRs, the old VC is discarded. 366 4. After the upstream LSR receives the ACK message, the VC is ready 367 to be used and the BLLI value can be used for another VC. 369 Second, the procedure for adding a leaf to the existing 370 point-to-multipoint VC is described. 372 1. The upstream LSR establishes a VC by the ATM Forum Signaling between 373 its downstream LSR with the BLLI value that was used during the 374 first signaling procedure. If another VC is using the BLLI value 375 at the same time, the upstream waits for the completion of the 376 signaling procedure that is using this BLLI value. 378 2. Go to step 2 of the procedure for the first VC. 380 3.3 Outband notification 382 This method can be applied when a VC is established using a ATM 383 signaling message and the message has a field (e.g., GIT [GIT]) which 384 is large enough to carry a VCID value. Message format is described in 385 [GIT]. 387 Node A Node B 388 | | 389 |<-------------->| 390 | ATM Signaling | 391 | with VCID | 393 4 VCID Message Format 394 4.1 VCID Class Messages 396 VCID class messages are added to the LDP specification [LDP]. An LDP 397 VCID PDU consists of an LDP common header followed by one or more 398 objects. VCID PROPOSE inband message is sent as a null encapsulation 399 packet through a VC to be used as an LSP. A label value in the label 400 stack entry for VCID PROPOSE inband message is 4, that should be 401 added as a reserved label value to the section 2.1 of [ENCAPS]. 402 Other messages are sent as TCP packets. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Version | Msg Class | PDU Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | LDP Identifier | 410 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | Reserved | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Msg Type | Reserved | Msg Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Mandatory Objects | 416 | (Variable Length) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Optional Objects | 419 | (Variable Length) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Version 423 One octet unsigned integer containing the version number of the 424 protocol. This version of the specification specifies protocol 425 Version = 0x01. 427 Msg Class 428 One octet integer defining the class of the LDP message. 429 VCID Class = 0x04 431 PDU Length 432 Two octet integer specifying the total length of this PDU in 433 bytes, excluding the common header. 435 LDP Identifier 436 Six octet field that uniquely identifiers the label space for 437 which this PDU applies. The first four octets encode an IP 438 address assigned to the LSR. This address should be the router- 439 id, also used in LSR-path-vector loop detection/prevention 440 objects. The last two octets identify a label space within the 441 LSR. For a platform-wide label space, these should both be 442 zero. 444 Reserved 445 This field is reserved. It must be set to zero on transmission 446 and must be ignored on receipt. 448 Msg Type 449 The MsgType field identifies the type of message. The following 450 discovery messages are supported: 451 VCID Propose inband Message = 0x01 452 VCID Propose Message = 0x02 453 VCID ACK Message = 0x02 454 VCID NACK Message = 0x03 456 Msg Length 457 Two octet integer specifying the total length of all objects 458 associated with the message type. 460 4.1.1 VCID Propose inband Message 462 This message is sent as a null encapsulation packet with a label 463 value 4 through a VC to be used as an LSP. 465 Mandatory Objects 466 At least one of each mandatory object with associated object headers. 468 +-----------------------+----------+ 469 | MANDATORY OBJECT | Type | 470 +-----------------------+----------+ 471 | VCID | 0x01 | 472 +-----------------------+----------+ 473 | Address | 0x03 | 474 +-----------------------+----------+ 476 4.1.2 VCID Propose Message 478 Mandatory Objects 479 At least one of each mandatory object with associated object headers. 481 +-----------------------+----------+ 482 | MANDATORY OBJECT | Type | 483 +-----------------------+----------+ 484 | VCID | 0x01 | 485 +-----------------------+----------+ 486 | Temporary ID | 0x02 | 487 +-----------------------+----------+ 489 4.1.3 VCID ACK Message 491 Mandatory Objects 492 At least one of each mandatory object with associated object headers. 494 +-----------------------+----------+ 495 | MANDATORY OBJECT | Type | 496 +-----------------------+----------+ 497 | VCID | 0x01 | 498 +-----------------------+----------+ 500 4.1.4 VCID NACK Message 502 Mandatory Objects 503 At least one of each mandatory object with associated object headers. 505 +-----------------------+----------+ 506 | MANDATORY OBJECT | Type | 507 +-----------------------+----------+ 508 | VCID | 0x01 | 509 +-----------------------+----------+ 511 4.2 VCID Class Objects 512 4.2.1 Object Header 514 All objects in a VCID message must begin with the following object 515 header. This header is the same as LDP specification. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Obj Type | Sub Type | Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Object Type 524 VCID_OBJECT = 0x01 525 TEMPORARY_ID_OBJECT = 0x02 526 ADDRESS_OBJECT = 0x03 528 4.2.2 VCID Object 530 +-----------------------+-------+--------------------------+----------+ 531 | OBJECT | Type | Subtype(s) | Length | 532 +-----------------------+-------+--------------------------+----------+ 533 | VCID | 0x01 | 0x01 Default | 4 | 534 +-------------------------------+--------------------------+----------+ 536 Subtype = 0x01 Default 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | VCID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 4.2.3 Temporary ID Object 546 +-----------------------+-------+--------------------------+----------+ 547 | OBJECT | Type | Subtype(s) | Length | 548 +-----------------------+-------+--------------------------+----------+ 549 | Temporary ID | 0x02 | 0x01 BLLI | 1 | 550 +-------------------------------+--------------------------+----------+ 552 Subtype = 0x01 Default 554 0 555 0 1 2 3 4 5 6 7 8 556 +-+-+-+-+-+-+-+-+-+ 557 | BLLI | 558 +-+-+-+-+-+-+-+-+-+ 560 4.2.4 Address Object 562 +-----------------------+-------+--------------------------+----------+ 563 | OBJECT | Type | Subtype(s) | Length | 564 +-----------------------+-------+--------------------------+----------+ 565 | Address | 0x02 | 0x01 Default | variable | 566 +-------------------------------+--------------------------+----------+ 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Address List Family |Source Address (variable length) 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 . . . . | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Destination Address (variable length) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Address Family 579 This 16 bit quantity contains a value from ADDRESS FAMILY NUM- 580 BERS in Assigned Numbers [RFC1700] that encodes the address family 581 that the network layer addresses in the Addresses field are from. 583 Addresses 584 Two addresses encoded according to the Address Family Field, 585 padded to a 16-bit boundary. First address is a source address of 586 this object. Second address is a destination address of this 587 object. 589 4.3 Mapping messages 590 4.3.1 Label Object 592 An VCID subtype is added to label object of an advertisment class 593 message in the LDP specification. This object is used for a label 594 mapping between SMD and VCID. 596 +-----------------------+-------+--------------------------+----------+ 597 | OBJECT | Type | Subtype(s) | Length | 598 +-----------------------+-------+--------------------------+----------+ 599 | Label | 0x03 | 0x03 VCID | 4 | 600 +-------------------------------+--------------------------+----------+ 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | VCID | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Security Considerations 610 Security issues are not discussed in this document. 612 Intellectual Property Considerations 614 Toshiba Corporation and Ennovate Networks may seek patent or other 615 intellectual property protection for some of the aspects of the 616 technology discussed in this document. If any standards arising from 617 this document are or become protected by one or more patents assigned 618 to Toshiba Corporation, Toshiba intends to license them on reasonable 619 and non- discriminatory terms. 621 Acknowledgments 623 The authors would like to acknowledge the valuable technical comments 624 of Shigeo Matsuzawa, Akiyoshi Mogi, Yasuhiro Katsube, Muneyoshi 625 Suzuki, George Swallow and members of the LAST-WG of the WIDE Project. 627 References 629 [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", 630 draft-demizu-mpls-vcid-01.txt, Oct. 1997 632 [VCPOOL] N. Demizu, et al., "VC pool", 633 draft-demizu-mpls-vcpool-00.txt, Oct. 1997 635 [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label 636 Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 638 [GIT] M. Suzuki, "The Assignment of the Information Field and 639 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 640 User-to-user Signaling for the Internet Protocol", 641 draft-ietf-mpls-git-uus-assignment-00.txt, June 1998 643 [ENCAPS] E. Rossen, et al., "MPLS Label Stack Encoding", 644 draft-ietf-mpls-label-encaps-02.txt, July 1998 646 [rfc1700] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, ISI, 647 October 1994 649 Authors Information 651 Ken-ichi Nagami 652 R&D Center, Toshiba Corporation, 653 1 Komukai-Toshiba-cho, Saiwai-ku, 654 Kawasaki, 210, Japan 655 Phone: +81-44-549-2231 656 Email: nagami@isl.rdc.toshiba.co.jp 658 Noritoshi Demizu 659 Graduate School of Information Science, 660 Nara Institute of Science and Technology 661 8916-5 Takayama, Ikoma, Nara 630-0101, Japan 662 Phone: +81-743-72-5348 663 E-mail: nori-d@is.aist-nara.ac.jp 665 Hiroshi Esaki 666 Computer and Network Division, 667 Toshiba Corporation, 668 1-1-1 Shibaura, 669 Minato-ku, 105-01, Japan 670 Email: hiroshi@isl.rdc.toshiba.co.jp 672 Paul Doolan 673 Ennovate Networks 674 330 Codman Hill Road 675 Boxborough, MA 676 Phone: 978-263-2002 x103 677 Email: pdoolan@ennovatenetworks.com