idnits 2.17.1 draft-feldman-ldp-spec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-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 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 31 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 19 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([ARCH], [FRAMEWORK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 410: '... withdrawn label MAY NOT be reused unt...' RFC 2119 keyword, line 755: '...live Interval. The receiving LSR MUST...' RFC 2119 keyword, line 756: '... MUST calculate the value of the ...' RFC 2119 keyword, line 784: '... A receiving LSR MUST calculate the in...' RFC 2119 keyword, line 1128: '...ving this object MUST append its own u...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 274 has weird spacing: '...rotocol messa...' == Line 388 has weird spacing: '.... The next ...' == Line 593 has weird spacing: '... mined on st...' == Line 869 has weird spacing: '...ro bits to ca...' == Line 913 has weird spacing: '...ro bits to ca...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that a withdrawn label MAY NOT be reused until the upstream peer has acknowledged the withdraw via a Release message. -- 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 (November 1997) is 9659 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 section? 'FRAMEWORK' on line 1278 looks like a reference -- Missing reference section? 'ARCH' on line 1281 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Nancy Feldman 3 Expiration Date: May 1998 IBM Corp. 5 Paul Doolan 6 Ennovate Networks 8 Andre Fredette 9 Bay Networks Inc 11 Loa Andersson 12 Ericsson 14 November 1997 16 LDP Specification 18 20 Status of This Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 An overview of Multi Protocol Label Switching (MPLS) is provided in 41 [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental 42 concept in MPLS is that two Label Switching Routers (LSRs) must agree 43 on the meaning of the labels used to forward traffic between and 44 through them. This common understanding is achieved by using the 45 Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and 46 [ARCH]. This document defines the LDP protocol. 48 Table of Contents 50 1. Protocol Overview ........................ 4 51 2. Local and Egress Control ................. 5 52 3. Selecting Streams ........................ 6 53 4. LDP Messaging ............................ 8 54 4.1. Hello Message ............................ 8 55 4.2. Protocol Message Overview ................ 8 56 4.2.1. Adjacency Class Messages ................. 8 57 4.2.2. Advertisement Class Messages ............. 8 58 4.3. Advertisement Message .................... 9 59 4.3.1. Local Control ............................ 9 60 4.3.2. Egress Control ........................... 10 61 4.3.3. Label Use ................................ 10 62 4.4. Request Message .......................... 10 63 4.5. Withdraw Message ......................... 11 64 4.6. Release Message .......................... 11 65 4.7. Acknowledge Message ...................... 12 66 4.8. Query Message ............................ 12 67 5. Loop Detection ........................... 12 68 6. Loop Prevention via Diffusion ............ 12 69 7. Merging .................................. 14 70 8. Specification ............................ 14 71 8.1. LDP Hello mechanism ...................... 14 72 8.2. Common Header ............................ 15 73 8.3. Object Header ............................ 16 74 8.4. Adjacency Class Messages ................. 17 75 8.5. Advertisement Class ...................... 17 76 8.6. LDP Object definitions ................... 18 77 8.6.1. MsgType Object ........................... 18 78 8.6.2. LSR Object ............................... 19 79 8.6.3. LabelRange Object ........................ 20 80 8.6.4. Stream Member Descriptor (SMD) Object .... 21 81 8.6.5. Label Object ............................. 26 82 8.6.6. Class-of-Service Object .................. 26 83 8.6.7. LSR Path Vector Object ................... 27 84 8.6.8. Hop Count Object ......................... 28 85 8.6.9. MTU Object ............................... 28 86 8.6.10. Stack Object ............................. 29 87 8.6.11. Error Object ............................. 30 88 9. Intellectual Property Considerations ..... 31 89 10. Acknowledgments .......................... 31 90 11. References ............................... 31 91 12. Author Information ....................... 32 93 1. Protocol Overview 95 LDP is the set of procedures and messages by which one LSR informs 96 another of the mappings between labels and Streams that it has made. 97 Two LSRs which use an LDP to exchange label/Stream mapping 98 information are known as "LDP Peers" with respect to that information 99 and we speak of there being an "LDP Adjacency" between them. A single 100 LDP adjacency allows each peer to learn the other's label mappings ie 101 the protocol is bidirectional. 103 LDP provides a mechanism whereby LSRs continually indicate their 104 presence in a network using advertisements which are sent as UDP 105 packets to the LDP port at the 'all routers' group multicast address. 106 When, perhaps in response to hearing an advertisement, one LSR 107 decides to establish an adjacency with another it uses the 108 initialization procedure of LDP. On succesful completion of this 109 initialization procedure the two LSRs are LDP peers and may exchange 110 label mappings. 112 Note that this document is written with respect to unicast routing 113 only. Multicast will be addressed in a future revision. 115 LDP messages are broken into two classes: those required to establish 116 and maintain neighbor adjacencies, and those which deal with the 117 advertisement of label mappings. 119 Correct operation of the label forwarding paradigm requires that 120 forwarding peers agree on the 'meaning' of labels. This imposes 121 certain requirements on the LDP including reliable and in order 122 delivery of mappings (although there are circumstances when this 123 second requirement could be relaxed). To satisfy these requirements 124 LDP uses the TCP transport. 126 The convention used in this document is the same as that used in the 127 documentation of the internet protocols [rfc1700] ie to express 128 numbers in decimal and to picture data in "big-endian" order. Fields 129 are described left to right, with the most significant octet on the 130 left and the least significant octet on the right. 132 The order of transmission of the header and data described in this 133 document is resolved to the octet level. Whenever a diagram shows a 134 group of octets, the order of transmission of those octets is the 135 normal order in which they are read in English. For example, in the 136 following diagram the octets are transmitted in the order they are 137 numbered. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | 1 | 2 | 3 | 4 | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | 5 | 6 | 7 | 8 | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | 9 | 10 | 11 | 12 | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Transmission Order of Bytes 151 Whenever an octet represents a numeric quantity the left most bit in the 152 diagram is the high order or most significant bit. That is, the bit 153 labeled 0 is the most significant bit. 154 Similarly, whenever a multi-octet field represents a numeric quantity 155 the left most bit of the whole field is the most significant bit. When 156 a multi-octet quantity is transmitted the most significant octet is 157 transmitted first. 159 2. Local and Egress Control 161 Each LSR must be configured for local or egress control, to determine 162 the behavior for the initial setup of LSPs. 164 When LSP control is done locally, each node may at any time pass 165 label mappings to its neighbors for each stream recognized by that 166 node. When the neighboring nodes recognize the same streams, they 167 map incoming labels to received outgoing labels. 169 When LSP control is done via egress control, then only the egress 170 node may initiate the transmission of label mappings. Non-egress 171 nodes wait until they get a label from downstream for a recognized 172 stream before mapping the stream and passing a corresponding label 173 for the stream to upstream peers. 175 An LSR behaves as an egress (that is, initiating mappings) on a per 176 stream basis. Thus, an LSR may be considered an egress for a 177 particular set of streams, and a non-egress for others. An LSR is an 178 egress LSR, with respect to a particular stream, under any of the 179 following conditions: 181 1. The stream refers to the LSR itself (including one of its 182 directly 184 attached interfaces). 186 2. The stream is reachable via a next hop router that is out- 187 side the LSR switching infrastructure. 189 3. The stream is reachable by crossing a routing domain boun- 190 dary, such as another area for OSPF summary net-works, or 191 another autonomous system for OSPF AS externals and BGP 192 routes [rfc1583] [rfc1771]. 194 3. Selecting Streams 196 A stream is an aggregate of one or more flows, treated as one for the 197 purpose of forwarding; that is, all aggregate flows use a single 198 label. 200 Following are the currently defined streams. New streams types may be 201 added as needed: 203 a) IPv4 address 204 This stream is a single a IP prefix. This identifier is 205 used for host or CIDR prefixes [rfc1519]. This type 206 results in each IP destination prefix sustaining its own 207 LSP tree. It is recommended in environments where no 208 aggregation information is provided by the routing proto- 209 cols (such as RIP), or in networks where the number of des- 210 tination prefixes is limited. 212 b) BGP Next Hop 213 This stream is the value in the BGP NEXT_HOP attribute. It 214 may be the IP address of a BGP border router (enabling one 215 LSP tree for all destinations reachable through the same 216 egress point), or the address of an external BGP peer (ena- 217 bling one LSP tree for all routes destinated to the same 218 external peer). This identifier provides the maximum 219 obtainable aggregation. 221 c) OSPF Router ID 222 This stream is the OSPF Router ID of the router that ini- 223 tiated the link state advertisement. This type allows 224 aggregation of traffic on behalf of multiple datagram 225 protocols routed by OSPF. 227 d) OSPF Area Border Router 228 This stream is the OSPF Router ID of the border router. 229 This identifier is used in OSPF external link advertisement 230 with a non-zero forwarding address. 232 e) Explicit Path 233 This stream is an explicitly defined source-routed path. 234 This information may be provided via configuration, or may 235 be computed via a Dijkstra calculation for a certain metric 236 (e.g. QoS, Tos), and may be used for point-to-point, 237 point-to-multipoint, or multipoint-to-point LSPs. This 238 type of stream may be initiated by an ingress or egress 239 LSR. 241 f) Aggregate group 242 This stream is a list of prefixes that are to share a com- 243 mon egress point. This type is configured, and may be used 244 when additional aggregation not provided by the routing 245 protocols is required. 247 g) Flow 248 This stream contains information pertaining to a constant 249 set of datagram information, such as port, dest-addr, src- 250 addr, etc. This feature provides the user with the ability 251 to use MPLS with no aggregation. This type of stream may 252 be initiated by an ingress or egress LSR. 254 h) Multicast (S,G) 255 This stream is a unique (Source, Group) multicast pair. It 256 creates one LSP tree per (S,G) pair. It is used by DVMRP 257 and PIM-DM. 259 i) Multicast (G) 260 This stream is a unique multicast group on a multicast 261 tree. It creates one switched path tree per group. It is 262 used by PIM-SM. 264 4. LDP Messaging 266 4.1. Hello Message 268 The hello message is periodically transmitted to autodiscover LSR 269 peers. The are transmitted as UDP packets to the LDP port at the 270 'all routers' group multicast address. 272 4.2. Protocol Message Overview 274 The protocol messages are constructed from a common header followed 275 by one or more message 'objects'. The message object structure is of 276 the form Type, Length, Value. 278 4.2.1. Adjacency Class Messages 280 Initialization 281 Transmitted after neighbor discovery, to exchange LSR characteris- 282 tics, and establish a neighbor adjacency. 284 KeepAlive 285 Periodically transmitted to maintain a neighbor adjacency. It need 286 be sent only when no other MPLS messages are transmitted within 287 the KeepAlive timer interval. 289 Shutdown 290 Transmitted to ACTIVE neighbors, to terminate a neighbor adja- 291 cency. 293 4.2.2. Advertisement Class Messages 295 Mapping 296 Transmitted to establish an LSP by transmitting a mapping between 297 a stream and a label, with associated characteristics. 299 Request 300 Transmitted to request a label mapping for a stream. 302 Withdraw 303 Transmitted to withdraw a previously allocated label. 305 Release 306 Transmitted to indicate a previously received label is no longer 307 in use. 309 Query 310 Transmitted when diffusion is in use, to verify that a new routed 311 path to the stream is loop free. 313 Acknowledge 314 An error transmitted on the receipt of an Advertisement Class mes- 315 sage, or as a response to a query message 317 4.3. Advertisement Message 319 The Advertisement message is used by a downstream LSR distribute a 320 label mapping for a stream to its LDP peers. If an LSR must distri- 321 bute a mapping for a stream to multiple MPLS peers, it is a local 322 matter whether it maps a single label to the stream, and distributes 323 that mapping to all its peers, or whether it uses a different mapping 324 for each of its peers. 326 It is the responsibility of the downstream LSR to keep track of the 327 mappings which it has distributed, and to ensure that the upstream 328 peer always has these mappings. 330 4.3.1. Local Control 332 If an LSR is configured for local control, an advertisement is 333 transmitted by an LSR to upstream peers upon any of the following 334 conditions: 336 1. The LSR recognizes a new stream via the forwarding table. 338 2. The LSR receives a Request Advertisement from an upstream peer 339 for a stream present in the LSR's forwarding table. 341 3. The next hop for a stream changes. 343 4. The next hop for a stream changes to another LDP peer. 345 5. The receipt of a mapping from the downstream next hop. 347 4.3.2. Egress Control 349 If an LSR is configured for egress control, an advertisement is 350 transmitted by downstream LSRs upon any of the following conditions: 352 1. The LSR recognizes a new stream via the forwarding table, and 353 is the egress for the stream. 355 2. The LSR receives a Request Advertisement from an upstream peer 356 for a stream present in the LSR's forwarding table, and the 357 LSR is the egress for that stream OR has a downstream mapping 358 for that stream. 360 3. The next hop for a stream changes to another LDP peer. 362 4. The attributes of a mapping change. 364 5. The receipt of a mapping from the downstream next hop. 366 4.3.3. Label Use 368 An upstream LSR uses a mapping received from the downstream peer if 369 that peer is the next hop for the stream, and a routed path loop is 370 not detected via the LSR-path-vector object (see section 8.6.7). If 371 diffusion is configured, a diffusion algorith may need to be per- 372 formed before the label is used (see section 6). If, at the time the 373 mapping is received, the downstream peer is NOT the LSR's Next Hop 374 for the stream, or an object is determined to be in a loop, the LSR 375 will not use of the mapping at that time. 377 4.4. Request Message 379 The Request message is used by the upstream LSR to explicitly request 380 that the downstream LSR map and advertise a label for a stream. 382 An LSR transmits a Request message under any of the following condi- 383 tions: 385 1. The LSR recognizes a new stream via the forwarding table, and 386 the next hop is an ACTIVE MPLS peer. 388 2. The next hop to the stream changes, and one doesn't already 389 have a mapping from that next hop for the given stream. 391 If a request cannot be satisfied by the downstream LSR, the request- 392 ing LSR may optionally choose to request again at a later time, or 393 may wait for the mapping, assuming that the the downstream LSR will 394 provide the mapping automatically when it is available. 396 4.5. Withdraw Message 398 A downstream LSR distributes a Withdraw message to upstream peers 399 when it decides to break the mapping between a stream and a label. 400 Note that if a downstream LSR peer becomes non-ACTIVE, all labels 401 received from that peer are to be considered withdrawn. 403 An LSR transmits a Withdraw message under the following condition: 405 1. The LSR no longer recognizes a previously known stream. 407 2. Optionally, the LSR has unspliced an upstream label from the 408 downstream label. 410 Note that a withdrawn label MAY NOT be reused until the upstream peer 411 has acknowledged the withdraw via a Release message. 413 4.6. Release Message 415 An LSR transmits a Release message to a downstream peer when it is 416 not using a label previously received from that peer. 418 An LSR transmits a Release message under any of the following condi- 419 tions: 421 1. The downstream LSR which sent the label mapping is not the 422 next hop for the mapped stream. 424 2. The downstream LSR which sent the label has ceased to be the 425 next hop for a stream. 427 3. The LSR has received a Withdraw message for a previously 428 received label. 430 Note that if an LSR is configured for "liberal mode", a release mes- 431 sage will never be transmitted. In this case, the upstream LSR keeps 432 each unused label, so that it can immediately be used later if the 433 downstream peer becomes the next hop for the stream. 435 4.7. Acknowledge Message 437 An LSR transmits an acknowledge message if it cannot process a 438 received Advertisement message, or in response to the receipt of a 439 diffusion query message. 441 4.8. Query Message 443 The Query message is used with the diffusion algorithm to verify that 444 new paths are loop-free before creating an LSP on the new path. See 445 diffusion section ??? 447 5. Loop Detection 449 All LSRs perform loop detection via the LSR-path-vector object con- 450 tained within each label advertisement. Upon receiving such a mes- 451 sage, the LSR performs loop detection by verifying that its unique 452 router-id is not already present in the list. If a loop is detected, 453 the LSR must transmit a NAK message to the sending node, and not 454 install the mapping or propagate the message any further. In addi- 455 tion, if there is an upstream label spliced to the downstream label 456 for the stream, the LSR must unsplice the labels. On those messages 457 in which no loop is detected, the LSR must concatenate itself to the 458 LSR-path-vector before propagating. 460 6. Loop Prevention via Diffusion 462 LSR diffusion support is a configurable option, which permits an LSR 463 to verify that a new routed path is loop free before installing an 464 LSP on that path. An LSR which supports diffusion does not splice an 465 upstream label a new downstream label until it ensures that concate- 466 nation of the upstream path with the new downstream path will be loop 467 free. 469 A LSR which detects a new nexthop for a stream transmits a query mes- 470 sage containing its unique router id to each of its upstream peers. 471 A node that receives such a query processes the query as follows: 473 o If the sending LSR not the correct next hop for the given 474 stream, the receiving LSR responds with a positive acknowledge 475 message, indicating that the sending LSR may change to the new 476 path. 478 o If the sending LSR is the correct next hop for the given 479 stream, the receiving LSR performs loop detection via the 480 LSR-path-vector. 482 o If a loop is detected, the receiving LSR responds with a nega- 483 tive "prune" acknowledgment, and unsplices all connections to 484 the sending node, thereby pruning itself off of the tree. 486 o If a loop is not detected, the receiving node concatenates its 487 unique router-id to the LSR-path-vector, and propagates the 488 query message to its upstream neighbors. 490 o Each LSR which receives a query acknowledgement from its 491 upstream neighbor in turn forwards the acknowledgement to the 492 downstream LSR which sent the query advertisement. 494 o If an LSR doesn't receive an acknowledgment within a "reason- 495 able" period of time, it "unsplices" its unsplice the upstream 496 neighbor that has not responded, and responds with a negative 497 "prune" acknowledgement. 499 o An LSR which receives a new query advertisement for a stream 500 before it has received responses from all of its upstream 501 neighbors for a previous query advertisement must concaten- 502 tated the old and the new LSR-path-vector within the new query 503 advertisement before propagating. 505 o The diffusion computation continues until each upstream path 506 responds with an acknowledgment. An LSR that does not have 507 any upstream MPLS neighbors must acknowledge the query adver- 508 tisement. 510 The LSR which began the diffusion may splice its upstream label to 511 the new downstream label only after receiving an acknowledge message 512 from the upstream peer. 514 As LSR diffusion support is a configurable option, an LSRs which do 515 not support diffusion will never originate a query advertisement. 516 However, these LSRs must still recognize and process the query mes- 517 sage, as described above. 519 7. Merging 521 VC/VP merging, non-merging, and interoperability will be addressed in 522 a future revision. 524 8. Specification 526 The hello mechanism is described first. Following that we define the 527 structure of the common header and of the objects. We then provide 528 definitions of the adjacency and advertisement messages and follow 529 that with definitions for the objects that constitute those messages. 531 8.1. LDP Hello mechanism 533 Hello message 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Version | Reserved | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | IP Address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Version: 544 This one octet unsigned integer contains the version number of 545 the protocol. This version of the specification specifies 546 protocol Version = 0x01. 548 Reserved 549 This field is reserved. It must be set to zero on transmission and 550 must be ignored on receipt. 552 Length: 553 This two octet integer specifies the total length of this 554 PDU in bytes. 556 Network Address 557 This 4 octet integer contains the address of the 558 LSR which originated the discovery message. 560 8.2. Common Header 562 All LDP PDUs, with the exception of the hello message, must begin 563 with the following common header: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Version | Reserved | Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | MPLS Identifier | 571 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | Reserved | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Version: 576 One octet unsigned integer containing the version number of 577 the protocol. This version of the specification specifies 578 protocol Version = 0x01. 580 Length: 581 Two octet integer specifying the total length of this 582 PDU in bytes, including the common header. 584 MsgClass 585 One octet integer defining the class of the MPLS message. 586 This version of the specification defines: 587 Adjacency Class = 1 588 Advertisement Class = 2 590 MPLS Identifier: 591 Six octet unsigned integer containing a unique identifier for the 592 LSR that generated the PDU. The value of this Identifier is deter- 593 mined on startup. The first four octets encode an IP address 594 assigned to the LSR. The last two octets represent the 'instance' 595 of MPLS on the LSR. A LSR with only one active MPLS session would 596 supply the value zero in this field. 598 Res: 599 This field is reserved. It must be set to zero on transmission and 600 must be ignored on receipt. 602 8.3. Object Header 604 All objects in an MPLS message must begin with the following object 605 header. Objects must be placed back-to-back within the message, and 606 must be padded to a word boundary. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Obj Type | Sub Type | Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Object Type 615 This one octet field specifies the type of the object following. 617 This version of the specification defines the following 618 objects for adjacency class messages: 620 MSGTYPE_OBJECT = 1 621 LSR_OBJECT = 2 622 LABELRANGE_OBJECT = 3 624 This version of the specification defines the following 625 objects for advertisement class messages: 627 MSGTYPE_OBJECT = 1 628 SMD_OBJECT = 2 629 LABEL_OBJECT = 3 630 COS_OBJECT = 4 631 LSR_PATH_VECTOR_OBJECT = 5 632 HOPCOUNT_OBJECT = 6 633 MTU_OBJECT = 7 634 STACK_OBJECT = 8 635 ERROR_OBJECT = 9 637 Sub Type 638 This one octet field specifies the subtype of this object. 639 See each of the object definitions for a definition of the subtypes. 641 Length 642 This two octet unsigned integer specifies the length of the object, 643 including this object header. 645 8.4. Adjacency Class Messages 647 The following notations show the objects that are valid with each 648 Advertisement Class Message. Only one message may be contained 649 within a single Adjacency Class PDU. 651 Initialization Message: 652 653 654 655 657 KeepAlive Message: 658 659 661 Shutdown Message: 662 663 665 8.5. Advertisement Class 667 All Advertisement Class PDUs begin with a common header: 668 670 The following notations show the objects that are valid with each 671 Advertisement Class Message. Multiple messages may be contained 672 within a single Advertisement Class PDU. 674 Mapping Message: 675 676 677 [ ] ... 679 :=