idnits 2.17.1 draft-ietf-mpls-lsp-query-04.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: ---------------------------------------------------------------------------- ** 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 17 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 485 has weird spacing: '...dresses are o...' == Line 535 has weird spacing: '...ical to the...' == Line 536 has weird spacing: '... except the ...' == Line 587 has weird spacing: '...e Query is u...' -- 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 (May 2002) is 8014 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 84 == 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: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Ashwood-Smih 2 Internet Draft A. Paraschiv 3 Expiration Date: November 2002 Nortel Networks 5 May 2002 7 Multi Protocol Label Switching Label Distribution Protocol Query Message Description 9 draft-ietf-mpls-lsp-query-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 26 Directory, see http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes the encoding and procedures for three new 31 Label Distribution Protocol (LDP) messages: Query Message, Query- 32 Reply Message and Partial Query-Reply Message (the last one is almost 33 identical to the Query-Reply message; therefore all references to the 34 Query-Reply messages imply the Partial Query-Reply messages as well, 35 unless otherwise specified). A Lable Edge Router (LER) sends a Query 36 message when it needs to find out information about a Label Switched 37 Path (LSP). The Query message is sent for an established LSP. The 38 Query message can be used for LDP LSPs as well as for Constraint- 39 Based Label Switched Paths (CR-LSPs). The queried data is encoded 40 into the Query-Reply messages. 42 Contents 44 1 Introduction ............................................. 3 45 2 Overview ................................................. 3 46 2.1 LDP Overview ............................................. 3 47 2.2 CR-LDP Overview .......................................... 4 48 3 LDP Message Structure Overview ........................... 4 49 4 Behavior of LSRs with constraints in handling the query messages 5 50 4.1 LSR does not support the query messages .................. 6 51 4.2 LSR cannot share any information ......................... 6 52 4.3 LSR cannot share some of the queried information ........ 6 53 4.4 LSR can share the queried information ................... 7 54 5 Query Message ............................................ 7 55 5.1 Query Message encoding ................................ 8 56 5.2 Query Message Procedures ................................. 9 57 6 Reply Messages .......................................... 10 58 6.1 Query-Reply Message encoding .......................... 11 59 6.2 Query-Reply Message Procedures ........................... 12 60 6.3 Partial Query-Reply Message encoding .................. 13 61 6.4 Partial Query-Reply Message Procedures ................... 13 62 7 Query TLVs ............................................... 14 63 7.1 Query Label TLV .......................................... 15 64 7.2 Query Merge Flags TLV .................................... 16 65 7.3 Status code summary ..................................... 17 66 8 Security Considerations .................................. 17 67 9 IANA Considerations ...................................... 17 68 10 Acknowledgments .......................................... 17 69 11 Normative References ..................................... 18 70 12 Author's Addresses ....................................... 18 71 Changes from previous version: 73 o Updated Security section. 74 o Updated IANA section. 75 o Updated Reference section. 76 o Updated Query Flags section. 77 o Expanded the acronyms in the title and in the abstract section. 79 [Editor's note: This section has to be removed prior to publication as an RFC.] 81 1. Introduction 83 The original Multiprotocol Label Switching (MPLS) architecture 84 [MPLS-ARCH] was been defined to support the forwarding of data based 85 on a label. The MPLS architecture does not assume a single label 86 distribution protocol. A number of different label distribution 87 protocols are being standardized. This memo describes the query 88 mechanism for an LSP or CR-LSP. It specifies procedures and encodings 89 for the new messages added for the query mechanism. 91 The new LDP messages are: Query Message, Query-Reply Message and 92 Partial Query-Reply Message. The following new TLVs are added to 93 accommodate the encodings for the new query messages: 94 - Query TLV 95 - Query Label TLV 96 - Query Merge Flags TLV 98 LDP uses the TCP transport for session, advertisement and 99 notification messages; i.e., for everything but the UDP-based 100 discovery mechanism. The messages which are added to support the 101 query mechanism are sent over TCP as well. 103 2. Overview 105 2.1. LDP Overview 107 Label Distribution Protocol (LDP) defined in [4] contains a set of 108 procedures and messages by which Label Switched Routers (LSR) 109 establish Label Switch Paths (LSP) through a network by mapping 110 network layer routing information directly to data-link layer 111 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 112 with each LSP it creates. The FEC associated with an LSP specifies 113 which packets are mapped to that LSP. 115 2.2. CR-LDP Overview 117 As described in CR-LDP [1], Constraint Base Routing offers the 118 opportunity to extend the information used to setup paths beyond what 119 is available from the routing protocol. For instance, an LSP can be 120 setup based on explicit route constraints, QoS constraints, and other 121 constraints. 123 3. LDP Message Structure Overview 125 The LDP message format is specified in the LDP Specification [4]. All 126 LDP messages have the following format: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |U| Message Type | Message Length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Message ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 + + 137 | Mandatory Parameters | 138 + + 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 + + 143 | Optional Parameters | 144 + + 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 U bit 149 Unknown message bit. Upon receipt of an unknown message, if U is 150 clear (=0), a notification is returned to the message originator; 151 if U is set (=1), the unknown message is silently ignored. 153 Message Type 154 Identifies the type of message 156 Message Length 157 Specifies the cumulative length in octets of the Message ID, 158 Mandatory Parameters, and Optional Parameters. 160 Message ID 161 32-bit value used to identify this message. It is used by the 162 sending LSR to facilitate identifying notification messages that 163 may apply to this message. An LSR sending a notification message 164 in response to this message should include this MessageId in the 165 Status TLV carried by the notification message; see Section 166 "Notification Message". 168 Mandatory Parameters 169 Variable length set of required message parameters. Some messages 170 have no required parameters. 172 For messages that have required parameters, the required parameters 173 must appear in the order specified by the individual message 174 specifications in the sections that follow. 176 Optional Parameters 177 Variable length set of optional message parameters. Many messages 178 have no optional parameters. 180 For messages that have optional parameters, the optional parameters 181 may appear in any order. 183 4. Behavior of LSRs with constraints in handling the query messages 185 Upon receiving a Query message, an LSR has to behave according to its 186 configuration constraints in handling the query messages and 187 returning the queried information. The following cases were 188 identified: 189 - the LSR does not support the code to handle the messages 190 for the query mechanism 191 - the LSR supports the code to handle the messages for the 192 query mechanism, but it is configured not to return any data 193 - the LSR supports the code to handle the messages for the 194 query mechanism, but it is configured not to return part of 195 the queried data 196 - the LSR supports the code to handle the messages for the 197 query mechanism, and it is configured to return all the data 198 which is queried. 200 This memo provides flexibility to handle each of the above cases. 202 4.1. LSR does not support the query messages 204 In this case, the LSR has to behave as if it received an unknown 205 message type. It therefore honors the U bit. 207 4.2. LSR cannot share any information 209 In this case, the LSR is able to decode and process the query 210 messages. However, it is configured to hide all the data. It should 211 propagate the message after it encodes a zero-length TLV for its hop 212 in the hop list in the Query message. When Query-Reply message is 213 received from downstream, the LSR is requested to propagate the reply 214 message upstream after it encodes the zero-length TLVs for the 215 queried data. When the ingress receives back the reply, it can 216 identify which TLVs are empty; it can therefore ignore the zero- 217 length TLVs and process the rest of the data. 219 Note: zero-length TLV encoding can be used for all types of queried 220 information except the merge information. The LSR is requested to 221 signal the fact that the merging information is private by encoding a 222 special value in the corresponding merge bits (for more information 223 on the merge flags values please refer to Section 7.2 of this memo - 224 Query Merge Flags TLV ). 226 4.3. LSR cannot share some of the queried information 228 In this case, the LSR is able to decode and process the query 229 messages. It has to propagate the query messages. It has to encode 230 values for the data types that it is willing to return and zero- 231 length TLVs for values for the data that is hidden. 233 Note: zero-length TLV encoding can be used for all types of queried 234 information except the merge information. The LSR is requested to 235 signal the fact that the merging information is private by encoding a 236 special value in the corresponding merge bits (for more information 237 on the merge flags values please refer to Section 7.2 of this memo - 238 Query Merge Flags TLV). 240 4.4. LSR can share the queried information 242 In this case, the LSR's behavior has to follow the query and replies 243 procedures described in the following sections of this memo. 245 In order to have consistency among data encoded in the query and 246 reply messages, each LSR which can propagate the messages has to 247 encode its information in the query and in the reply messages. 249 The decision that an LSR can share the queried information has to be 250 controlled through configuration flags. This way each node along the 251 path can protect its data if they consider it private. 253 Note: It would be more efficient to control/restrict the private data 254 per MPLS cloud (inter MPLS domain) and not per LSR node (inter and 255 intra MPLS domain). When there are different MPLS clouds which have 256 nodes belonging to different vendors, the control of the private 257 information could be restricted to the boundary nodes. Within an MPLS 258 domain, there should be no restrictions on the queried information. 259 It would be useful to have some knowledge on which are the nodes on 260 the boundaries and have only those hiding the queried data. Because 261 there is no mechanism to identify which are the boundary nodes, this 262 is subject for future study. 264 5. Query Message 266 This sections describes the Query message and its encodings and 267 procedures. This message is meant to be used to gather information 268 about an LSP. It can be sent at any time for an established LSP. 269 This memo currently describes the procedures for the cases when the 270 Query Message is initiated by the ingress LER. Additional procedures 271 may be added in the future for the query message when issued from an 272 LSR or from egress. 274 The Query Message can be used to gather information about: 275 - LSRs which form the LSP 276 - labels along the LSP 277 - information on what LSRs are merging points along the path 278 - unused bandwidth (as described in "Improving Topology Data 279 Base Accuracy with LSP Feedback" [2]) 280 - anything that is needed in the future and can be computed and 281 encoded in a TLV. 283 The queried information is encoded in the Query-Reply message which 284 is sent back upstream, as a response to the Query message. 286 5.1. Query Message encoding 288 The encoding for the Query message is: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |0| Query type TBD IANA | Message Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Message ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Query Label TLV | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Query TLV | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Hop Count TLV | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Optional Parameters | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Message ID 307 32-bit value used to identify this message. 309 Query Label TLV 310 The label associated to the LSP which is queried. This TLV is a 311 list of Generalized Label TLVs [3]. The Generalized Label TLV 312 provides a more generic encoding for different types of labels. 313 Most of the time the list has one element; this is the case when 314 the LSP is not tunneled. For tunneled LSPs, the Label TLV has 315 more that one element; it has to behave like a label stack (it 316 contains the previous label and the tunnel's label). See Section 317 7.1 of this memo - Query Label TLV - for more information on Label 318 TLV encoding. 320 Query TLV 321 What to query. See Section 7 of this memo - Query TLV - for 322 encoding. 324 Hop Count TLV 325 Specifies the number of LSR hops that can still be traversed 326 before the message is dropped due to loop detection. It is 327 initialized to the max default value of 255 (or the configured 328 value, if any). Every LSR that receives the Query Message has to 329 subtract 1 from the Hop Count value. The Query message should be 330 dropped if the hop count value becomes zero; a Notification 331 signaling Loop Detection should be sent in reply to the sender of 332 the message. See [4] for Hop Count TLV encoding. 334 Optional Parameters 335 This variable length field contains 0 or more parameters, each 336 encoded as a TLV. 338 Optional Parameter Length Value 340 ER TLV var See [1] 341 LSPID TLV var See [1] 342 FEC TLV var See [4] 344 The ER TLV is a list of hops. It is used when the Query flag Q3 is 345 set. Every LSR should add its IP address. The address to be added 346 should be the outgoing interface address. Addresses are organized as 347 a last-in-fist-out stack (the first address in TLV is considered the 348 top). By carrying this TLV in the Query Message and preserving this 349 order for the hops, we allow the possibility to interwork the Query 350 Message with the RSVP Path message. 352 FEC TLV is used when PHP is in use, for LDP. 354 LSPID TLV is used when PHP is in use, for CR-LDP. 356 For more details on the FEC or LSPID usage, please refer to the Query 357 Message Procedures below. 359 5.2. Query Message Procedures 361 The LER ingress initiates the Query message. It populates the Query 362 TLV Parameters according to what kind of information it wants to 363 gather. The query for an LSP is done by its label. The only data that 364 the Query Message could carry is the list of hops. This way, each 365 node along the path can have a complete route from source to 366 destination. This is useful for network management. Please note that 367 this parameter is optional. If the Query message does not contain the 368 ER TLV, it should be propagated by LSRs along the path without the ER 369 TLV. 371 Upon receiving a Query Message, an LSR decodes the label to identify 372 which LSP is queried. If it cannot find the LSP which is using the 373 label, it sends back a Notification message with "No LSP to query" 374 status. Otherwise, it checks which is the out label which is bound to 375 the queried in-label and which is the downstream LSR peer. It 376 replaces the in-label from Query Label TLV with the out-label used by 377 the LSP. It then passes the Query message to the downstream peer. 379 When the Query message gets to a tunnel, it has to be able to handle 380 both the previous label and the tunnel's label. The Query Label TLV 381 behaves like a label stack. The previous label is pushed and the 382 tunnel label is used. At the end of the tunnel, we need to pop the 383 stack and start substituting the lower level labels. 385 Upon receiving the Query message, the egress node has to reply with a 386 Query Reply Message. The Query-Reply Message contains the Query TLV 387 which was received in the Query Message. The Query TLV tells the LSRs 388 along the path which information is being queried and allows 389 intermediate LSRs to piggy back their own queried information on the 390 Query reply message. 392 The initiator of a Query reply might not receive a response back. In 393 this case, it is the initiator's responsibility to decide if and when 394 to retry. 396 If PHP is in use, the Query Message sent from the PHP to the 397 destination node needs to carry the FEC (for LDP) or LSPID (for CR- 398 LDP). This information is required because the label between the PHP 399 and the destination is a special label and the destination cannot 400 uniquely identify the queried LSP just by using the label value. If 401 the PHP does not encode the FEC or the LSPID, the destination node 402 should reply with a notification message with "Ambiguous label 403 value". 405 6. Reply Messages 407 These messages are propagated upstream. There are two types of reply 408 messages: 410 - Query-Reply message (final reply) 411 - Partial Query-Reply message. 413 The Reply messages carry the queried information upstream. A Query- 414 Reply message is sent in response to a Query message. The ingress 415 which initiated the Query message is interested to gather the 416 information from all the nodes along the queried LSP. However, there 417 are situations in which the Query message does not reach the end 418 point of the queried LSP. In these scenarios it would be useful if 419 the ingress LSR gathered at least some information about the LSRs 420 which are along the path, up to the one that failed. The Partial 421 Query-Reply message provides this mechanism. It is recommended to use 422 the Partial Query-Reply messages when a Query message fails. If the 423 Reply message is full, TCP will take care of it by segmenting and 424 re-assembling the message. 426 Both reply messages are described in the following sections. 428 6.1. Query-Reply Message encoding 430 This message is generated by the end point of the LSP. It is 431 propagated upstream, by each LSR along the path. 433 The encoding for the Query-Reply message is: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |0| Query-Reply Type TBD IANA | Message Length | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Message ID | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Query TLV | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | MessageId TLV | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Optional Parameters | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Message ID 450 32-bit value used to identify this message. 452 Query TLV 453 What is to be queried. See Section 7 of this memo - Query TLV - 454 for encoding. 456 MessageId TLV 457 The value of this parameter is the message id of the corresponding 458 Query message. 460 Optional Parameters 461 This variable length field contains 0 or more parameters, each 462 encoded as a TLV. The optional parameters are: 464 Optional Parameter Length Value 466 ER TLV var See [1] 467 Query Label TLV var See Query Label TLV section 468 IPV4/6 specified link feedback TLV See [2] 469 Query Merge Flags TLV var See Query Merge Flags TLV 470 section 471 The TLV types are defined in CR-LDP [1] and LDP [4]. They are: 473 - IPV4/6 specified link feedback TLV 474 - ER TLV 475 - Generalized Label TLV (used in the Query Label TLV encoding) 476 - Hop Count TLV. 478 The IPV4/6 specified link feedback TLV is used when the Q1 flag from 479 the Query TLV is set. It is used to encode the bandwidth information. 480 For more information on query flags, Q1, Q2, Q3 and Q4, refer to 481 Query TLV section. 483 The ER TLV is a list of hops. It is used when the Query flag Q3 is 484 set. Every LSR should add its IP address. The address to be added 485 should be the outgoing interface address. Addresses are organized as 486 a last-in-fist-out stack (the first address in TLV is considered the 487 top). 489 The Query Label TLV is a list of labels. It is used when the Query 490 flag Q2 is set. It is populated with the labels used for the path 491 which is queried. For tunneled LSPs, the Query Label TLV represents a 492 list of labels associated to the lowest level tunnel. 494 If Q3 and Q2 flags are set, the labels should be encoded in the same 495 order as the hops. 497 Query Merge Flags TLV is a list of pairs of bits. It has variable 498 length and every two bits in the mask will correspond to an LSR along 499 the path. Its length is rounded up to the next byte. If Q4 is set, 500 every LSP along the path will have to set its corresponding bits in 501 the mask. The bits have to be set in the same order as the labels and 502 hops. Usually, Q4 is set when Q2 set and/or Q3 set. 504 For more information for the TLV encodings of the TLVs which are 505 used, please see [1], [4] and [2]. 507 6.2. Query-Reply Message Procedures 509 A Query-Reply message is initiated by an egress node which receives a 510 Query message, if the egress is able to identify the queried LSP. If 511 not, the egress replies with a Notification message with "No LSP to 512 query" status. 514 Upon receiving the Query message, the egress node has to reply with a 515 Query Reply message. The egress node has to encode into the Query- 516 Reply message a MessageId TLV. The mapping between a Query and a 517 Query-Reply Message is done based on the message id. Besides the 518 MessageId TLV, the egress has to encode the information that was 519 queried (bandwidth, path, etc). 521 After the encoding is done, the query reply message is sent back, on 522 the reversed path, towards the ingress. Every LSR across the LSP has 523 to encode its information according to what query flags are set. 525 6.3. Partial Query-Reply Message encoding 527 The Partial Query-Reply message is initiated by LSRs along the 528 queried path. The message is generated only if the following rules 529 apply: 530 - if the Query message asked for partial 531 replies (the Query message signals this request 532 through Q8 bit) 533 - if the LSR is configured to provide partial replies. 535 The encoding for the Partial Query-Reply message is identical to the 536 Query-Reply, except the message type. For more details on the 537 encoding please refer to the Query-Reply encoding. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |0|Partial Query-Reply TBD IANA | Message Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Message ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Query TLV | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | MessageId TLV | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Optional Parameters | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 6.4. Partial Query-Reply Message Procedures 555 The procedures are similar to the Query-Reply's procedures. Upon 556 receiving a Query message, an LSR will check the flag from the Query 557 message (Q8) which signals if the partial replies are requested by 558 the ingress node. If the flag is set, the LSR has to check next if it 559 is configured to fulfill this request. If the LSR supports partial 560 replies, it has to create a Partial Query-Reply and encode the 561 queried data and send it upstream like any Query-Reply messages. It 562 has then to process the Query message according to the Query message 563 procedures. When an LSR receives a Partial Query-Reply from upstream, 564 it should encode its information according to what is queried and 565 propagate the message. It is recommended to use the Partial Query 566 mechanism when the Query message fails (when the ingress LER does not 567 receive a Query-Reply message in response to a Query message). 569 7. Query TLVs 571 The Query TLV is used to specify the information being queried. The 572 Query TLV travels in the Query message to the egress node, where it 573 is copied into a reverse flowing Query-Reply messages and used by the 574 egress and intermediate LSRs to know what information is being 575 queried. 577 The format for the Query TLV is: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |0|0| Query TLV Type TBD IANA | Length | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Query Flags | Reserved | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Query Flags can be set according to what the Query is used for. A 588 query flag is set when it is 1. 590 +--+--+--+--+--+--+--+--+ 591 |Q8|Reserved|Q4|Q3|Q2|Q1| 592 +--+--+--+--+--+--+--+--+ 594 They can be: 596 - Q1 : query the bandwidth; if set, the LSR that 597 receives the Query message has to encode the bandwidth 598 that is available on the link (unused bandwidth); 599 - Q2 : query the labels which are associated to each hop in the 600 path; 601 - Q3 : query the LSRs which form the LSP which is queried; 602 if set, the LSR that received the Query-Reply message 603 has to encode the current hop in the ER-TLV 604 - Q4 : query which LSPs along the path are merging points; if set, 605 the LSR that receives the Query message has to encode 606 if it is a merging point; the encoding is done in the 607 Query Merge flags TLV. 608 - Q8 : if set, the ingress requests partial query-replies; each LSR 609 along the path is signaled to send a Partial Query Reply. 611 The reserved bits need to be set to zero on transmission and must be 612 ignored on receipt. They might be used in the future to signal other 613 types of queried information. The Query Flags can only be defined by 614 updating this memo. 616 7.1. Query Label TLV 618 The Query Label TLV is used to encode the labels used along the path 619 which is queried. 621 Note: Query Label TLV is used in both Query and Query Reply. It is a 622 required parameter in the Query message and it is an optional 623 parameter in Query Reply message. When being used in the Query 624 message, it carries the label or stack of labels which are being 625 followed and queried. When being used in the Query Reply message, it 626 carries the list of labels which make up the queried path. 628 The format for the Query Label TLV is: 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |0|0| Query Label TLV TBD IANA | Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Generalized Label TLV 1 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 ~ ~ 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Generalized Label TLV n | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Generalized Label TLV is used to encode labels along the path. Please 642 refer to [3] for more information on the Generalized Label TLV 643 encoding. If the Q2 flag is set, every LSR has to encode the out- 644 label corresponding to the queried LSP. In the Query Label TLV, 645 labels are organized as a last-in-fist-out stack (the first label in 646 TLV is considered the top). They should be encoded in the same order 647 as the hops and the merge flags. 649 7.2. Query Merge Flags TLV 651 The Query Merge Flags TLV is used to encode the information about 652 which LSRs along the path the queried LSP is being merged into. 654 The format for the Query Merge Flags TLV is: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |0|0| Merge Flags TLV TBD IANA | Length | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Number of merge flags | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Merge flags ~ 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 ~ ~ 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 The Query Merge Flags TLV has 4 bytes field to store the number of 671 merge flags. This number is equal to the number of LSRs which are 672 traversed by the Query-Reply Message. The Merge flags field contains 673 the merge information. It is a variable length field which is rounded 674 up to the next byte. Each pair of bits in the Merge flags field 675 carries the merge information for one LSR. The valid values for the 676 merge bits for an LSR are: 678 01 - LSR does not do merge for the queried LSP 679 10 - LSR does merge for the queried LSP 680 00 - LSR cannot share the merge information. 682 Every LSR which is asked to encode the merging info has to update the 683 Number of merge flags and to set its corresponding bits accordingly. 685 7.3. Status code summary 687 Status Code E Status Data Section Title 689 No LSP to query 1 TBD IANA "Query Message Procedures..." 690 Ambiguous label value 1 TBD IANA "Query Message Procedures..." 692 8. Security Considerations 694 The Query mechanism inherits the same security mechanism described in 695 Section 4.0 of [4]. The Query mechanism provides an additional 696 security measure for cases when a node cannot share the queried 697 information. Such nodes have the option of hiding their information, 698 if their configuration requires it. Please refer to Section 4 of this 699 memo - "Behavior of LSRs with constraints in handling the query 700 messages" - for more details. 702 9. IANA Considerations 704 The Query mechanism does not require a new message type space, a TLV 705 type space or a Status code space. Extensions to the LDP spaces are 706 required, as follows: 708 - the message types for Query Message, Query-Reply Message and 709 Partial Query-Reply Message should be provided by extending 710 the LDP message type space. 711 - the TLV types for Query TLV, Query Label TLV and Query Merge 712 Flags TLV should be provided by extending the LDP TLV type space. 713 - the Status codes "No LSP to query" and "Ambiguous label value" should 714 be provided by extending the LDP Status code space. 716 10. Acknowledgments 718 The authors would like to acknowledge the careful review and comments 719 of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk, Gregory Wright and 720 Adrian Farrel. 722 11. Normative References 724 [1] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC 725 3212, January 2002 727 [2] Peter Ashwood-Smith et al., "Improving Topology Data Base 728 Accuracy with LSP Feedback", Work in Progress, draft-ietf-mpls-te-feed- 729 03.txt. 731 [3] Ashwood-Smith P., Berger L., "Generalized MPLS - Signaling 732 Functional Description", Work in Progress, draft-ietf-mpls-generalized- 733 signaling-07.txt. 735 [4] Andersson et al., "LDP Specification", RFC 3036, January 2001. 737 12. Author's Addresses 739 Peter Ashwood-Smith Antonela Paraschiv 740 Nortel Networks Corp. Nortel Networks Corp. 741 P.O. Box 3511 Station C, 600 Technology Park Drive 742 Ottawa, ON K1Y 4H7 Billerica, MA 01821 743 Canada USA 744 Phone: +1 613-763-4534 phone: +1 978-288-6136 745 petera@nortelnetworks.com antonela@nortelnetworks.com 747 Full Copyright Statement 749 Copyright (C) The Internet Society (date). All Rights Reserved. This 750 document and translations of it may be copied and furnished to 751 others, and derivative works that comment on or otherwise explain it 752 or assist in its implementation may be prepared, copied, published 753 and distributed, in whole or in part, without restriction of any 754 kind, provided that the above copyright notice and this paragraph 755 are included on all such copies and derivative works. However, this 756 document itself may not be modified in any way, such as by removing 757 the copyright notice or references to the Internet Society or other 758 Internet organizations, except as needed for the purpose of 759 developing Internet standards in which case the procedures for 760 copyrights defined in the Internet Standards process must be 761 followed, or as required to translate it into languages other than 762 English. 764 The limited permissions granted above are perpetual and will not be 765 revoked by the Internet Society or its successors or assigns.