idnits 2.17.1 draft-ietf-mpls-lsp-query-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 536 has weird spacing: '... the top...' == Line 637 has weird spacing: '...e Query is u...' == Line 699 has weird spacing: '... order as ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2003) is 7620 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) -- Looks like a reference, but probably isn't: 'MPLS-ARCH' on line 90 -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-te-feed-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-07 ** Obsolete normative reference: RFC 3036 (ref. '4') (Obsoleted by RFC 5036) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Ashwood-Smith 2 Internet Draft A. Paraschiv 3 Expiration Date: January 2004 D. Allan 4 Nortel Networks 6 June 2003 8 Multi Protocol Label Switching Label Distribution Protocol 9 Query Message Description 11 draft-ietf-mpls-lsp-query-09.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes the encoding and procedures for three new 36 Label Distribution Protocol (LDP) messages: Query Message, Query- 37 Reply Message and Partial Query-Reply Message. A Label Edge Router 38 (LER) sends a Query message when it needs to find out information 39 about an established Label Switched Path (LSP). The Query message 40 can be used for LDP LSPs as well as for Constraint-Based Label 41 Switched Paths (CR-LSPs). The queried data is encoded into the 42 Query-Reply messages. 44 Contents 46 1. Introduction..................................................3 47 2. Specification.................................................3 48 3. Overview......................................................3 49 3.1 LDP Overview.................................................3 50 3.2 CR-LDP Overview..............................................4 51 4. LDP Message Structure Overview................................4 52 5. LSRs with constraints in handling the query messages..........5 53 5.1 LSR does not support the query messages......................6 54 5.2 LSR cannot share any information.............................6 55 5.3 LSR cannot share some of the queried information.............6 56 5.4 LSR can share the queried information........................6 57 6. Query Message.................................................7 58 6.1 Query Message encoding.......................................7 59 6.2 Query Message Procedures.....................................9 60 7. Reply Messages...............................................10 61 7.1 Query-Reply Message encoding................................11 62 7.2 Query-Reply Message Procedures..............................12 63 7.3 Partial Query-Reply Message encoding........................13 64 7.4 Partial Query-Reply Message Procedures......................13 65 8. Query TLVs...................................................13 66 8.1 Query Label TLV.............................................14 67 8.2 Query Merge Flags TLV.......................................15 68 8.3 Query Payload TLV...........................................16 69 8.4 Status code summary.........................................16 70 9. Security Considerations......................................17 71 10. IANA Considerations..........................................17 72 10.1 Message Type Space Extension..............................17 73 10.2 TLV Type Name Space Extension.............................17 74 10.3 Status Code Space Extension...............................18 75 11. Acknowledgments..............................................18 76 12. Normative References.........................................18 77 13. Author's Addresses...........................................18 78 Changes from previous version: 80 o Additions to support ECMP 81 o Editorial changes 82 o Elaboration on security considerations 83 o Clarification to message fragmenting issues. 85 [Editor's note: This section has to be removed prior to publication] 87 1. Introduction 89 The original Multiprotocol Label Switching (MPLS) architecture 90 [MPLS-ARCH] was been defined to support the forwarding of data based 91 on a label. The MPLS architecture does not assume a single label 92 distribution protocol. A number of different label distribution 93 protocols are being standardized. This memo describes the query 94 mechanism for a Label Switched Path (LSP) or Constraint Based LSP 95 (CR-LSP). It specifies procedures and encodings for the new messages 96 added for the query mechanism. 98 The new LDP messages are: Query Message, Query-Reply Message and 99 Partial Query-Reply Message. The Partial Query Reply is almost 100 Identical to the Query Reply message; therefore all references to 101 the Query Reply message imply the Partial Query Reply Message as 102 well unless explicitly noted. 104 The following new TLVs are added to accommodate the encodings for 105 the new query messages: 106 - Query TLV 107 - Query Label TLV 108 - Query Merge Flags TLV 109 - Query Payload TLV 111 LDP uses the TCP transport for session, advertisement and 112 notification messages; i.e., for everything but the UDP-based 113 discovery mechanism. The messages which are added to support the 114 query mechanism are sent over TCP as well. 116 2. Specification 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Overview 124 3.1 LDP Overview 125 Label Distribution Protocol (LDP) defined in [4] contains a set of 126 procedures and messages by which Label Switched Routers (LSR) 127 establish Label Switch Paths (LSP) through a network by mapping 128 network layer routing information directly to data-link layer 129 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 130 with each LSP it creates. The FEC associated with an LSP specifies 131 which packets are mapped to that LSP. 133 3.2 CR-LDP Overview 135 As described in CR-LDP [1], Constraint Base Routing offers the 136 opportunity to extend the information used to setup paths beyond 137 what is available from the routing protocol. For instance, an LSP 138 can be setup based on explicit route constraints, QoS constraints, 139 and other constraints. 141 4. LDP Message Structure Overview 143 The LDP message format is specified in the LDP Specification [4]. 144 All LDP messages have the following format: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |U| Message Type | Message Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Message ID | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 + + 155 | Mandatory Parameters | 156 + + 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | 160 + + 161 | Optional Parameters | 162 + + 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 U bit 167 Unknown message bit. Upon receipt of an unknown message, if U 168 is clear (=0), a notification is returned to the message 169 originator; if U is set (=1), the unknown message is silently 170 ignored. 172 Message Type 173 Identifies the type of message 175 Message Length 176 Specifies the cumulative length in octets of the Message ID, 177 Mandatory Parameters, and Optional Parameters. 179 Message ID 180 32-bit value used to identify this message. It is used by the 181 sending LSR to facilitate identifying notification messages 182 that may apply to this message. An LSR sending a notification 183 message in response to this message should include this 184 MessageId in the Status TLV carried by the notification 185 message. 187 Mandatory Parameters 188 Variable length set of required message parameters. Some 189 messages have no required parameters. 191 For messages that have required parameters, the required parameters 192 must appear in the order specified by the individual message 193 specifications in the sections that follow. 195 Optional Parameters 196 Variable length set of optional message parameters. Many messages 197 have no optional parameters. 199 For messages that have optional parameters, the optional parameters 200 may appear in any order. 202 5. LSRs with constraints in handling the query messages 204 Upon receiving a Query message, an LSR has to behave according to 205 its configuration constraints in handling the query messages and 206 returning the queried information. The following cases were 207 identified: 208 - The LSR does not support the code to handle the messages 209 for the query mechanism 210 - The LSR supports the code to handle the messages for the 211 query mechanism, but it is configured not to return any 212 data 213 - The LSR supports the code to handle the messages for the 214 query mechanism, but it is configured not to return part of 215 the queried data 216 - The LSR supports the code to handle the messages for the 217 query mechanism, and it is configured to return all the 218 data which is queried. 220 This memo provides flexibility to handle each of the above cases. 222 5.1 LSR does not support the query messages 224 In this case, the LSR has to behave as if it received an unknown 225 message type. It therefore honors the U bit. Where this is in 226 response to query with Query flag Q8 clear, the originating LSR may 227 then repeat the request with Q8 set (partial repliers requested) to 228 obtain LSP information up to the non-implementing LSR along the LSP 229 path. 231 5.2 LSR cannot share any information 233 In this case, the LSR is able to decode and process the query 234 messages. However, it is configured to hide all the data. It should 235 propagate the message after it encodes a zero-length TLV for its hop 236 in the hop list in the Query message. When Query-Reply message is 237 received from downstream, the LSR is requested to propagate the 238 reply message upstream after it encodes the zero-length TLVs for the 239 queried data. When the ingress receives back the reply, it can 240 identify which TLVs are empty; it can therefore ignore the zero- 241 length TLVs and process the rest of the data. 243 Note: zero-length TLV encoding can be used for all types of queried 244 information except the merge information. The LSR is requested to 245 signal the fact that the merging information is private by encoding 246 a special value in the corresponding merge bits (for more 247 information on the merge flags values please refer to Section 7.2 of 248 this memo - Query Merge Flags TLV). 250 5.3 LSR cannot share some of the queried information 252 In this case, the LSR is able to decode and process the query 253 messages. It has to propagate the query messages. It has to encode 254 values for the data types that it is willing to return and zero- 255 length TLVs for values for the data that is hidden. 257 Note: zero-length TLV encoding can be used for all types of queried 258 information except the merge information. The LSR is requested to 259 signal the fact that the merging information is private by encoding 260 a special value in the corresponding merge bits (for more 261 information on the merge flags values please refer to Section 7.2 of 262 this memo - Query Merge Flags TLV). 264 5.4 LSR can share the queried information 266 In this case, the LSR's behavior has to follow the query and replies 267 procedures described in the following sections of this memo. 269 In order to have consistency among data encoded in the query and 270 reply messages, each LSR which can propagate the messages has to 271 encode its information in the query and in the reply messages. 273 The decision that an LSR can share the queried information has to be 274 controlled through configuration flags. This way each node along the 275 path can protect its data if they consider it private. 277 Note: It would be more efficient to control/restrict the private 278 data per MPLS cloud (inter MPLS domain) and not per LSR node (inter 279 and intra MPLS domain). When there are different MPLS clouds which 280 have nodes belonging to different vendors, the control of the 281 private information could be restricted to the boundary nodes. 282 Within an MPLS domain, there should be no restrictions on the 283 queried information. It would be useful to have some knowledge on 284 which are the nodes on the boundaries and have only those hiding the 285 queried data. Because there is no mechanism to identify which are 286 the boundary nodes, this is subject for future study. 288 6. Query Message 290 This section describes the Query message and its encodings and 291 procedures. This message is meant to be used to gather information 292 about an LSP. It can be sent at any time for an established LSP. 293 This memo currently describes the procedures for the cases when the 294 Query Message is initiated by the ingress LER. Additional procedures 295 may be added in the future for the query message when issued from an 296 LSR or from egress. 298 The Query Message can be used to gather information about: 299 - LSRs which form the LSP 300 - Labels along the LSP 301 - Information on what LSRs are merging points along the path 302 - Unused bandwidth (as described in "Improving Topology Data 303 Base Accuracy with LSP Feedback" [2]) 304 - What path any specific payload may follow in the presence 305 of load spreading mechanisms such as ECMP 306 - Anything that is needed in the future and can be computed 307 and encoded in a TLV. 309 It should be noted that useful information can still be extracted 310 from partial responses due constraints on handling messages placed 311 on some LSRs along the LSP. In the fault diagnosis scenario 312 (particularly in the presence of ECMP), those LSRs that at a minimum 313 return their own LSR ID facilitate diagnosis when combined with data 314 plane tracing tools as those LSRs can act as segmentation boundaries 315 for fault isolation. 317 The queried information is encoded in the Query-Reply message which 318 is sent back upstream, as a response to the Query message. 320 6.1 Query Message encoding 321 The encoding for the Query message is: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |0| Query type TBD IANA | Message Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Message ID | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Query Label TLV | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Query TLV | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Hop Count TLV | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Optional Parameters | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Message ID 340 32-bit value used to identify this message. 342 Query Label TLV 343 The label associated to the LSP which is queried. This TLV is a 344 list of Generalized Label TLVs [3]. The Generalized Label TLV 345 provides a more generic encoding for different types of labels. 346 Most of the time the list has one element; this is the case when 347 the LSP is not tunneled. For tunneled LSPs, the Label TLV has 348 more that one element; it has to behave like a label stack (it 349 contains the previous label and the tunnel's label). See Section 350 8.1 of this memo - Query Label TLV - for more information on 351 Label TLV encoding. 353 Query TLV 354 What to query. See Section 8 of this memo - Query TLV - for 355 encoding. 357 Hop Count TLV 358 Specifies the number of LSR hops that can still be traversed 359 before the message is dropped due to loop detection. It is 360 initialized to the max default value of 255 (or the configured 361 value, if any). Every LSR that receives the Query Message has to 362 subtract 1 from the Hop Count value. The Query message should 363 be dropped if the hop count value becomes zero; a Notification 364 signaling Loop Detection should be sent in reply to the sender 365 of the message. See [4] for Hop Count TLV encoding. 367 Optional Parameters 368 This variable length field contains 0 or more parameters, each 369 encoded as a TLV. 371 Optional Parameter Length Value 372 ER TLV var See [1] 373 LSPID TLV var See [1] 374 FEC TLV var See [4] 375 Query Payload TLV var See below 377 The ER TLV is a list of hops. It is used when the Query flag Q3 is 378 set. Every LSR should add its IP address. The address to be added 379 should be the outgoing interface address. Addresses are organized as 380 a last-in-first-out stack (the first address in TLV is considered 381 the top). By carrying this TLV in the Query Message and preserving 382 this order for the hops, we allow the possibility to interwork the 383 Query Message with the RSVP Path message. 385 FEC TLV is used when penultimate hop popping (PHP) is in use, for 386 LDP. 388 LSPID TLV is used when PHP is in use, for CR-LDP. 390 Query Payload TLV is used where ECMP is deployed in order to qualify 391 the specific LSP hops chosen by intermediate LSRs. 393 For more details on the FEC, LSPID, or Query Payload TLVs usage, 394 please refer to the Query Message Procedures below. 396 6.2 Query Message Procedures 398 The LER ingress initiates the Query message. It populates the Query 399 TLV Parameters according to what kind of information it wants to 400 gather. The query for an LSP is done by its label. The only data 401 that the Query Message could carry is the list of hops. This way, 402 each node along the path can have a complete route from source to 403 destination. This is useful for network management. Please note 404 that this parameter is optional. If the Query message does not 405 contain the ER TLV, it should be propagated by LSRs along the path 406 without the ER TLV. 408 Upon receiving a Query Message, an LSR decodes the label to identify 409 which LSP is queried. If it cannot find the LSP which is using the 410 label, it sends back a Notification message with "No LSP to query" 411 status. Otherwise, it checks which is the out label which is bound 412 to the queried in-label and which is the downstream LSR peer. It 413 replaces the in-label from Query Label TLV with the out-label used 414 by the LSP. It then passes the Query message to the downstream peer. 416 Where there is more than one valid downstream peer, AND the Payload 417 Query TLV is present, the LSR may use the Payload Query TLV to 418 select the appropriate downstream LSP peer using the same algorithms 419 that it would use if the payload was carried in the LSP data plane. 420 If the Payload Query TLV is not present but the ECMP implementation 421 requires the payload information for downstream path selection, it 422 sends back a Notification message with "Payload Query TLV Required" 423 status. 425 When the Query message gets to a tunnel, it has to be able to handle 426 both the previous label and the tunnel's label. The Query Label TLV 427 behaves like a label stack. The previous label is pushed and the 428 tunnel label is used. At the end of the tunnel, we need to pop the 429 stack and start substituting the lower level labels. 431 Upon receiving the Query message, the egress node has to reply with 432 a Query Reply Message. The Query-Reply Message contains the Query 433 TLV which was received in the Query Message. The Query TLV tells the 434 LSRs along the path which information is being queried and allows 435 intermediate LSRs to piggy back their own queried information on the 436 Query reply message. 438 The initiator of a Query reply might not receive a response back. In 439 this case, it is the initiator's responsibility to decide if and 440 when to retry. 442 If PHP is in use, the Query Message sent from the PHP to the 443 destination node needs to carry the FEC (for LDP) or LSPID (for CR- 444 LDP). This information is required because the label between the PHP 445 and the destination is a special label and the destination cannot 446 uniquely identify the queried LSP just by using the label value. If 447 the PHP does not encode the FEC or the LSPID, the destination node 448 should reply with a notification message with "Ambiguous label 449 value". 451 7. Reply Messages 453 These messages are propagated upstream. There are two types of 454 reply messages: 456 - Query-Reply message (final reply) 457 - Partial Query-Reply message. 459 The Reply messages carry the queried information upstream. A Query- 460 Reply message is sent in response to a Query message. The ingress 461 which initiated the Query message is interested to gather the 462 information from all the nodes along the queried LSP. However, 463 there are situations in which the Query message does not reach the 464 end point of the queried LSP. In these scenarios it would be useful 465 if the ingress LSR gathered at least some information about the LSRs 466 which are along the path, up to the one that failed. The Partial 467 Query-Reply message provides this mechanism. It is recommended to 468 use the Partial Query-Reply messages when a Query message fails. 470 Both reply messages are described in the following sections. 472 7.1 Query-Reply Message encoding 474 This message is generated by the end point of the LSP. It is 475 propagated upstream, by each LSR along the path. 477 The encoding for the Query-Reply message is: 479 0 1 2 3 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0| Query-Reply Type TBD IANA | Message Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Message ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Query TLV | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | MessageId TLV | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Optional Parameters | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Message ID 494 32-bit value used to identify this message. 496 Query TLV 497 What is to be queried. See Section 7 of this memo - Query TLV - 498 for encoding. 500 MessageId TLV 501 The value of this parameter is the message id of the 502 corresponding Query message. 504 Optional Parameters 505 This variable length field contains 0 or more parameters, each 506 encoded as a TLV. The optional parameters are: 508 Optional Parameter Length Value 509 ------------------ ------ ----- 510 ER TLV var See [1] 512 Query Label TLV var See Query Label TLV 513 section 514 IPV4/6 specified link feedback TLV var See [2] 516 Query Merge Flags TLV var See Query Merge Flags 517 TLV section 519 The TLV types are defined in CR-LDP [1] and LDP [4]. They are: 521 - IPV4/6 specified link feedback TLV 522 - ER TLV 523 - Generalized Label TLV (used in the Query Label TLV 524 encoding) 525 - Hop Count TLV. 527 The IPV4/6 specified link feedback TLV is used when the Q1 flag from 528 the Query TLV is set. It is used to encode the bandwidth 529 information. For more information on query flags, Q1, Q2, Q3 and Q4, 530 refer to Query TLV section. 532 The ER TLV is a list of hops. It is used when the Query flag Q3 is 533 set. Every LSR should add its IP address. The address to be added 534 should be the outgoing interface address. Addresses are organized as 535 a last-in-first-out stack (the first address in TLV is considered 536 the top). 538 The Query Label TLV is a list of labels. It is used when the Query 539 flag Q2 is set. It is populated with the labels used for the path 540 which is queried. For tunneled LSPs, the Query Label TLV represents 541 a list of labels associated to the lowest level tunnel. 543 If Q3 and Q2 flags are set, the labels should be encoded in the same 544 order as the hops. 546 Query Merge Flags TLV is a list of pairs of bits. It has variable 547 length and every two bits in the mask will correspond to an LSR 548 along the path. Its length is rounded up to the next byte. If Q4 is 549 set, every LSP along the path will have to set its corresponding 550 bits in the mask. The bits have to be set in the same order as the 551 labels and hops. Usually, Q4 is set when Q2 set and/or Q3 set. 553 For more information for the TLV encodings of the TLVs which are 554 used, please see [1], [4] and [2]. 556 7.2 Query-Reply Message Procedures 558 A Query-Reply message is initiated by an egress node which receives 559 a Query message, if the egress is able to identify the queried LSP. 560 If not, the egress replies with a Notification message with "No LSP 561 to query" status. 563 Upon receiving the Query message, the egress node has to reply with 564 a Query Reply message. The egress node has to encode into the Query- 565 Reply message a MessageId TLV. The mapping between a Query and a 566 Query-Reply Message is done based on the message id. Besides the 567 MessageId TLV, the egress has to encode the information that was 568 queried (bandwidth, path, etc). 570 After the encoding is done, the query reply message is sent back, on 571 the reversed path, towards the ingress. Every LSR across the LSP has 572 to encode its information according to what query flags are set. 574 7.3 Partial Query-Reply Message encoding 576 The Partial Query-Reply message is initiated by LSRs along the 577 queried path. The message is generated only if the following rules 578 apply: 579 - if the Query message asked for partial 580 replies (the Query message signals this request 581 through Q8 bit) 582 - if the LSR is configured to provide partial replies. 584 The encoding for the Partial Query-Reply message is identical to the 585 Query-Reply, except the message type. For more details on the 586 encoding please refer to the Query-Reply encoding. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |0|Partial Query-Reply TBD IANA | Message Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Message ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Query TLV | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | MessageId TLV | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Optional Parameters | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 7.4 Partial Query-Reply Message Procedures 604 The procedures are similar to the Query-Reply's procedures. Upon 605 receiving a Query message, an LSR will check the flag from the Query 606 message (Q8) which signals if the partial replies are requested by 607 the ingress node. If the flag is set, the LSR has to check next if 608 it is configured to fulfill this request. If the LSR supports 609 partial replies, it has to create a Partial Query-Reply and encode 610 the queried data and send it upstream like any Query-Reply messages. 611 It has then to process the Query message according to the Query 612 message procedures. When an LSR receives a Partial Query-Reply from 613 upstream, it should encode its information according to what is 614 queried and propagate the message. It is recommended to use the 615 Partial Query mechanism when the Query message fails (when the 616 ingress LER does not receive a Query-Reply message in response to a 617 Query message). 619 8. Query TLVs 621 The Query TLV is used to specify the information being queried. The 622 Query TLV travels in the Query message to the egress node, where it 623 is copied into a reverse flowing Query-Reply messages and used by 624 the egress and intermediate LSRs to know what information is being 625 queried. 627 The format for the Query TLV is: 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |0|0| Query TLV Type TBD IANA | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Query Flags | Reserved | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Query Flags can be set according to what the Query is used for. 638 A query flag is set when it is 1. 640 +--+--+--+--+--+--+--+--+ 641 |Q8|Reserved|Q4|Q3|Q2|Q1| 642 +--+--+--+--+--+--+--+--+ 644 They can be: 646 - Q1 : query the bandwidth; if set, the LSR that 647 receives the Query message has to encode the bandwidth 648 that is available on the link (unused bandwidth); 649 - Q2 : query the labels which are associated to each hop in the 650 path; 651 - Q3 : query the LSRs which form the LSP which is queried; 652 if set, the LSR that received the Query-Reply message 653 has to encode the current hop in the ER-TLV 654 - Q4 : query which LSPs along the path are merging points; 655 if set, the LSR that receives the Query message has 656 to encode if it is a merging point; the encoding is 657 done in the Query Merge flags TLV. 658 - Q8 : if set, the ingress requests partial query-replies; 659 each LSR along the path is signaled to send a Partial 660 Query Reply. 662 The reserved bits need to be set to zero on transmission and must be 663 ignored on receipt. They might be used in the future to signal other 664 types of queried information. The Query Flags can only be defined by 665 updating this memo. 667 8.1 Query Label TLV 669 The Query Label TLV is used to encode the labels used along the path 670 which is queried. 672 Note: Query Label TLV is used in both Query and Query Reply. It is a 673 required parameter in the Query message and it is an optional 674 parameter in Query Reply message. When being used in the Query 675 message, it carries the label or stack of labels which are being 676 followed and queried. When being used in the Query Reply message, it 677 carries the list of labels which make up the queried path. 679 The format for the Query Label TLV is: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 |0|0| Query Label TLV TBD IANA | Length | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Generalized Label TLV 1 | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 ~ ~ 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Generalized Label TLV n | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Generalized Label TLV is used to encode labels along the path. 694 Please refer to [3] for more information on the Generalized Label 695 TLV encoding. If the Q2 flag is set, every LSR has to encode the 696 out-label corresponding to the queried LSP. In the Query Label TLV, 697 labels are organized as a last-in-first-out stack (the first label 698 in TLV is considered the top). They should be encoded in the same 699 order as the hops and the merge flags. 701 8.2 Query Merge Flags TLV 703 The Query Merge Flags TLV is used to encode the information about 704 which LSRs along the path the queried LSP is being merged into. 706 The format for the Query Merge Flags TLV is: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |0|0| Merge Flags TLV TBD IANA | Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Number of merge flags | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Merge flags ~ 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 ~ ~ 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 The Query Merge Flags TLV has 4 bytes field to store the number of 723 merge flags. This number is equal to the number of LSRs which are 724 traversed by the Query-Reply Message. The Merge flags field 725 contains the merge information. It is a variable length field which 726 is rounded up to the next byte. Each pair of bits in the Merge flags 727 field carries the merge information for one LSR. The valid values 728 for the merge bits for an LSR are: 730 01 - LSR does not do merge for the queried LSP 731 10 - LSR does merge for the queried LSP 732 00 - LSR cannot share the merge information. 734 Every LSR which is asked to encode the merging info has to update 735 the number of merge flags and to set its corresponding bits 736 accordingly. 738 8.3 Query Payload TLV 740 The Query Payload TLV is used to encode the payload that LSRs 741 implementing ECMP or similar load spreading should use when 742 selecting a downstream peer. 744 The format for the Query Payload TLV is: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |0|0| Query Payload TLV TBD IANA| Length | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Payload Identifier | Reserved (=0) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 | Example payload ~ 755 ~ | 756 | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 The Query Payload TLV carries an example of the payload of the LSP 760 that is of interest for tracing purposes. The payload example may 761 be: 762 - an MPLS label stack, 763 - an MPLS label stack followed by an IPv4 or IPv6 packet header or 764 - an IPv4 or IPv6 packet header. 766 The contents of the Query Payload TLV are identified via use of the 767 payload identifier (currently used as a bitmap) 768 0x01 - label stack present 769 0x02 - IP packet present 771 When the IP packet present flag is set, the IP version is determined 772 by examining the version number field of the packet header in the 773 example payload. 775 8.4 Status code summary 777 Status Code E Status Data Section Title 778 No LSP to query 1 TBD IANA "Query Message Procedures..." 779 Ambiguous label value 1 TBD IANA "Query Message Procedures..." 780 Payload Query TLV 1 TBD IANA "Query Message Procedures..." 781 Required 782 Message space 1 TBD IANA "Query Message Procedures..." 783 exhausted 785 9. Security Considerations 787 The Query mechanism inherits the same security mechanism described 788 in Section 5.0 of [4]. The Query mechanism provides an additional 789 security measure for cases when a node cannot share the queried 790 information. Such nodes have the option of hiding their information, 791 if their configuration requires it. Please refer to Section 4 of 792 this memo - "Behavior of LSRs with constraints in handling the query 793 messages" - for more details. 795 The Query mechanism focuses on the ability to trace the control 796 plane, the outcome of which may then be compared against the output 797 of data plane tracing tools to ensure system consistency. If the 798 control plane maintains a chain of trust from LSP ingress to egress 799 using mechanisms to secure individual adjacencies against known or 800 yet to be developed attacks, then LSP Query will produce useful 801 information. Where the chain of trust is incomplete, the partial- 802 query reply mechanism may be used to trace the control plane up to 803 the point of the boundary between trusted and untrusted network 804 elements on the LSP path. 806 10. IANA Considerations 808 RFC 3036 [4] defines several name spaces including the Message Type 809 Name Space, the TLV Type Name Space, and the Status Code Name Space. 810 This document makes the following assignments within those spaces. 812 10.1 Message Type Space Extension 814 The message types for Query Message, Query-Reply Message and Partial 815 Query-Reply Message are as follows: 817 Message Type 818 -------------------------------------- ---------- 819 Query Message TBD IANA 820 Query Reply Message TBD IANA 821 Partial Query Reply Message TBD IANA 823 10.2 TLV Type Name Space Extension 825 The TLV types for Query TLV, Query Label TLV and Query Merge Flags 826 TLV are as follows: 828 TLV Type 829 -------------------------------------- ---------- 830 Query TLV TBD IANA 831 Query Label TLV TBD IANA 832 Query Merge Flags TLV TBD IANA 833 Query Payload TLV TBD IANA 835 10.3 Status Code Space Extension 837 The Status codes are as follows: 839 Status Code Type 840 -------------------------------------- ---------- 841 No LSP to query TBD IANA 842 Ambiguous label value TBD IANA 843 Payload Query TLV Required TBD IANA 844 Message space exhausted TBD IANA 846 11. Acknowledgments 848 The authors would like to acknowledge the careful review and 849 comments of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk, Gregory 850 Wright and Adrian Farrel. 852 12. Normative References 854 [1] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC 855 3212, January 2002 857 [2] Peter Ashwood-Smith et al., "Improving Topology Data Base 858 Accuracy with LSP Feedback", Work in Progress, draft-ietf-mpls-te- 859 feed-03.txt. 861 [3] Ashwood-Smith P., Berger L., "Generalized MPLS - Signaling 862 Functional Description", Work in Progress, draft-ietf-mpls- 863 generalized-signaling-07.txt. 865 [4] Andersson et al., "LDP Specification", RFC 3036, January 2001. 867 13. Author's Addresses 869 Peter Ashwood-Smith Antonela Paraschiv 870 Nortel Networks Corp. Nortel Networks Corp. 871 P.O. Box 3511 Station C, 600 Technology Park Drive 872 Ottawa, ON K1Y 4H7 Billerica, MA 01821 873 Canada USA 874 Phone: +1 613-763-4534 phone: +1 978-288-6136 875 petera@nortelnetworks.com antonela@nortelnetworks.com 877 Dave Allan 878 Nortel Networks Corp. 879 P.O. Box 3511 Station C, 880 Ottawa, ON K1Y 4H7 881 Canada 882 Phone: +1 613-763-6362 883 dallan@nortelnetworks.com 885 Full Copyright Statement 887 Copyright (C) The Internet Society (2002). All Rights Reserved. This 888 document and translations of it may be copied and furnished to 889 others, and derivative works that comment on or otherwise explain it 890 or assist in its implementation may be prepared, copied, published 891 and distributed, in whole or in part, without restriction of any 892 kind, provided that the above copyright notice and this paragraph 893 are included on all such copies and derivative works. However, this 894 document itself may not be modified in any way, such as by removing 895 the copyright notice or references to the Internet Society or other 896 Internet organizations, except as needed for the purpose of 897 developing Internet standards in which case the procedures for 898 copyrights defined in the Internet Standards process must be 899 followed, or as required to translate it into languages other than 900 English. 902 The limited permissions granted above are perpetual and will not be 903 revoked by the Internet Society or its successors or assigns.