idnits 2.17.1 draft-ietf-mpls-lsp-query-02.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 168: '... MUST appear in the order specified ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 120 has weird spacing: '...essages have ...' == Line 341 has weird spacing: '...dresses are o...' == Line 452 has weird spacing: '...dresses are o...' == Line 503 has weird spacing: '...ical to the...' == Line 504 has weird spacing: '... except the ...' -- 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 2001) is 8375 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: 'MPLS-ARCH' is mentioned on line 78, but not defined == Unused Reference: 'CR-LDP' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RSVP-RR' is defined on line 662, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-te-feed-01 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-07 == Outdated reference: A later version (-05) exists of draft-ietf-rsvp-refresh-reduct-04 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 2 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 2001 Nortel Networks 5 May 2001 7 MPLS LDP Query Message Description 9 draft-ietf-mpls-lsp-query-02.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 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the encoding and procedures for three new LDP 33 messages, the Query Message and Query-Reply Message and Partial 34 Query-Reply Message (the last one is almost identical to the Query- 35 Reply message; therefore all references to the Query-Reply messages 36 imply the Partial Query-Reply messages as well, unless otherwise 37 specified). An LER sends a Query message when it needs to find out 38 information about an LSP. The Query message is sent for an 39 established LSP. The Query message can be used for LDP LSPs as well 40 as for CR-LSPs. The queried data is encoded into the Query-Reply 41 messages. 43 Contents 45 1 Introduction ............................................. 3 46 2 Overview ................................................. 3 47 2.1 LDP Overview ............................................. 3 48 2.2 CR-LDP Overview .......................................... 4 49 3 LDP Message Structure Overview ........................... 4 50 4 Behavior of LSRs with constraints in handling the query messages 5 51 4.1 LSR does not support the query messages .................. 6 52 4.2 LSR cannot share any information ......................... 6 53 4.3 LSR cannot share some of the queried information ........ 6 54 4.4 LSR can share the queried information ................... 7 55 5 Query Message ............................................ 7 56 5.1 Query Message encoding ................................ 8 57 5.2 Query Message Procedures ................................. 9 58 6 Reply Messages .......................................... 10 59 6.1 Query-Reply Message encoding .......................... 10 60 6.2 Query-Reply Message Procedures ........................... 12 61 6.3 Partial Query-Reply Message encoding .................. 12 62 6.4 Partial Query-Reply Message Procedures ................... 13 63 7 Query TLVs ............................................... 13 64 7.1 Query Label TLV .......................................... 14 65 7.2 Query Merge Flags TLV .................................... 15 66 7.3 Status code summary ..................................... 16 67 8 Acknowledgments .......................................... 16 68 9 References ............................................... 16 69 10 Author's Addresses ....................................... 17 70 Changes from previous version: 72 o Added clarification on how to handle the optional parameter ER TLV in 73 the Query message. 75 1. Introduction 77 The original Multiprotocol Label Switching (MPLS) architecture 78 [MPLS-ARCH] was been defined to support the forwarding of data based 79 on a label. The MPLS architecture does not assume a single label 80 distribution protocol. A number of different label distribution 81 protocols are being standardized. This draft describes the query 82 mechanism for an LSP or CR-LSP. It specifies procedures and encodings 83 for the new messages added for the query mechanism. Extensions to 84 RSVP-TE to provide the same functionality are subject for future 85 study and will be covered in future draft versions. 87 The new LDP messages are: Query Message, Query-Reply Message and 88 Partial Query-Reply Message. The following new TLVs are added to 89 accommodate the encodings for the new query messages: 90 - Query TLV 91 - Query Label TLV 92 - Query Merge Flags TLV 94 LDP uses the TCP transport for session, advertisement and 95 notification messages; i.e., for everything but the UDP-based 96 discovery mechanism. The messages which are added to support the 97 query mechanism are sent over TCP as well. 99 2. Overview 101 2.1. LDP Overview 103 Label Distribution Protocol (LDP) defined in [LDP Specification] 104 contains a set of procedures and messages by which Label Switched 105 Routers (LSR) establish Label Switch Paths (LSP) through a network by 106 mapping network layer routing information directly to data-link layer 107 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 108 with each LSP it creates. The FEC associated with an LSP specifies 109 which packets are mapped to that LSP. 111 2.2. CR-LDP Overview 113 As described in [Constraint-Base LSP Setup using LDP], Constraint 114 Base Routing (CR-LDP) offers the opportunity to extend the 115 information used to setup paths beyond what is available for the 116 routing protocol. 118 3. LDP Message Structure Overview 120 As described in LDP Specification draft, all LDP messages have the 121 following format: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |U| Message Type | Message Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Message ID | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 + + 132 | Mandatory Parameters | 133 + + 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 + + 138 | Optional Parameters | 139 + + 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 U bit 144 Unknown message bit. Upon receipt of an unknown message, if U is 145 clear (=0), a notification is returned to the message originator; 146 if U is set (=1), the unknown message is silently ignored. 148 Message Type 149 Identifies the type of message 151 Message Length 152 Specifies the cumulative length in octets of the Message ID, 153 Mandatory Parameters, and Optional Parameters. 155 Message ID 156 32-bit value used to identify this message. Used by the sending 157 LSR to facilitate identifying notification messages that may apply 158 to this message. An LSR sending a notification message in 159 response to this message should include this Message Id in the 160 Status TLV carried by the notification message; see Section 161 "Notification Message". 163 Mandatory Parameters 164 Variable length set of required message parameters. Some messages 165 have no required parameters. 167 For messages that have required parameters, the required parameters 168 MUST appear in the order specified by the individual message 169 specifications in the sections that follow. 171 Optional Parameters 172 Variable length set of optional message parameters. Many messages 173 have no optional parameters. 175 For messages that have optional parameters, the optional parameters 176 may appear in any order. 178 4. Behavior of LSRs with constraints in handling the query messages 180 Upon receiving a Query message, an LSR has to behave according to its 181 configuration constraints in handling the query messages and 182 returning the queried information. The following cases were 183 identified: 184 - the LSR does not support the code to handle the messages 185 for the query mechanism 186 - the LSR supports the code to handle the messages for the 187 query mechanism, but it is configured not to return any data 188 - the LSR supports the code to handle the messages for the 189 query mechanism, but it is configured not to return part of 190 the queried data 191 - the LSR supports the code to handle the messages for the 192 query mechanism, and it is configured to return all the data 193 which is queried. 195 The draft provides flexibility to handle each of the above cases. 197 4.1. LSR does not support the query messages 199 In this case, the LSR has to behave as if it received an unknown 200 message type. It has therefore to honor the U bit. 202 4.2. LSR cannot share any information 204 In this case, the LSR is able to decode and process the query 205 messages. However, it is configured to hide all the data. It should 206 propagate the message after it encodes a zero-length TLV for its hop 207 in the hop list in the Query message. When Query-Reply message is 208 received from downstream, the LSR is requested to propagate the reply 209 message upstream after it encodes the zero-length tlvs for the 210 queried data. When the ingress receives back the reply, it can 211 identify which TLVs are empty; it can therefore ignore the zero- 212 length TLVs and process the rest of the data. 214 Note: zero-length TLV encoding can be used for all types of queried 215 information except the merge information. The LSR is requested to 216 signal the fact that the merging information is private by encoding a 217 special value in the corresponding merge bits (for more information 218 on the merge flags values please refer to Query Merge Flags TLV 219 section). 221 4.3. LSR cannot share some of the queried information 223 In this case, the LSR is able to decode and process the query 224 messages. It has to propagate the query messages. It has to encode 225 values for the data types that it is willing to return and zero- 226 length TLVs for values for the data that is hidden. 228 Note: zero-length TLV encoding can be used for all types of queried 229 information except the merge information. The LSR is requested to 230 signal the fact that the merging information is private by encoding a 231 special value in the corresponding merge bits (for more information 232 on the merge flags values please refer to Query Merge Flags TLV 233 section). 235 4.4. LSR can share the queried information 237 This is the normal case for an LSR. In this case, the LSR's behavior 238 has to follow the query and replies procedures described in the 239 following sections of the draft. 241 In order to have consistency among data encoded in the query and 242 reply messages, each LSR which can propagate the messages has to 243 encode its information in the query and in the reply messages. 245 The decision that an LSR can share the queried information has to be 246 controlled through configuration flags. This way each node along the 247 path can protect its data if they consider it private. 249 Note: It would be more efficient to control/restrict the private data 250 per MPLS cloud (inter MPLS domain) and not per LSR node (inter and 251 intra MPLS domain). When there are different MPLS clouds which have 252 nodes belonging to different vendors, the control of the private 253 information could be restricted to the boundary nodes. Within an MPLS 254 domain, there should be no restrictions on the queried information. 255 It would be useful to have some knowledge on which are the nodes on 256 the boundaries and have only those hiding the queried data. Because 257 there is no mechanism to identify which are the boundary nodes, this 258 is subject for future study. 260 5. Query Message 262 This sections describes the Query message and its encodings and 263 procedures. This message is meant to be used to gather information 264 about an LSP. It can be sent at any time for an established LSP. 265 The draft currently describes the procedures for the cases when the 266 Query Message is initiated by the ingress LER. Future versions of 267 the draft may add the procedures for the query message when issued 268 from a core LSR or from egress. 270 The Query Message can be used to gather information about: 271 - LSRs which form the LSP 272 - labels along the LSP 273 - information on what LSRs are merging points along the path 274 - unused bandwidth (as described in "Improving Topology Data 275 Base Accuracy with LSP Feedback") 276 - congestion status 277 - round trip delay 278 - anything that is needed in the future and can be computed and 279 encoded in a TLV. 281 The queried information is encoded in the Query-Reply message which 282 is sent back upstream, as a response to the Query message. 284 5.1. Query Message encoding 286 The encoding for the Query message is: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |0| Query (0x0409) | Message Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Message ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Query Label TLV | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Query TLV | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Hop Count TLV | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Optional Parameters | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Message ID 305 32-bit value used to identify this message. 307 Query Label TLV 308 The label associated to the LSP which is queried. This TLV is a 309 list of Generalized Label TLVs [OPTICAL reference]. The 310 Generalized Label TLV provides a more generic encoding for 311 different types of labels. Most of the time the list has one 312 element; this is the case when the LSP is not tunneled. For 313 tunneled LSPs, the Label TLV has more that one element; it has to 314 behave like a label stack (it contains the previous label and the 315 tunnel's label). See Section Query Label TLV for more information 316 on Label TLV encoding. 318 Query TLV 319 What to query. See Section Query TLV for encoding. 321 Hop Count TLV 322 Specifies the number of LSR hops that can still be traversed 323 before the message is dropped due to loop detection. It is 324 initialized to the max value of 255 (or the configured value, if 325 any). Every LSR that receives the Query Message has to subtract 1 326 from the Hop Count value. The Query message should be dropped if 327 the hop count value becomes zero; a Notification signaling Loop 328 Detection should be sent in reply to the sender of the message. 329 See [LDP Specification] for Hop Count TLV encoding. 331 Optional Parameters 332 This variable length field contains 0 or more parameters, each 333 encoded as a TLV. 335 Optional Parameter Length Value 337 ER TLV var See CR-LDP 339 The ER TLV is a list of hops. It is used when the Query flag Q3 is 340 set. Every LSR should add its IP address. The address to be added 341 should be the outgoing interface address. Addresses are organized as 342 a last-in-fist-out stack (the first address in TLV is considered the 343 top). By carrying this TLV in the Query Message and preserving this 344 order for the hops, we allow the possibility to interwork the Query 345 Message with the RSVP Path message. 347 5.2. Query Message Procedures 349 The LER ingress initiates the Query message. It populates the Query 350 TLV Parameters according to what kind of information it wants to 351 gather. The query for an LSP is done by its label. The only data that 352 the Query Message could carry is the list of hops. This way, each 353 node along the path can have a complete route from source to 354 destination. This is useful for network management. Please note that 355 this parameter is optional. If the Query message does not contain the 356 ER TLV, it should be probagated by LSRs along the path without the ER 357 TLV. 359 Upon receiving a Query Message, an LSR decodes the label to identify 360 which LSP is queried. If it cannot find the LSP which is using the 361 label, it sends back a Notification message with "No Lsp to query" 362 status. Otherwise, it checks which is the out label which is bound to 363 the queried in-label and which is the downstream LSR peer. It 364 replaces the in-label from Query Label TLV with the out-label used by 365 the LSP. It then passes the Query message to the downstream peer. 366 When the Query message gets to a tunnel, it has to be able to handle 367 both the previous label and the tunnel's label. The Query Label TLV 368 behaves like a label stack. The previous label is pushed and the 369 tunnel label is used. At the end of the tunnel, we need to pop the 370 stack and start substituting the lower level labels. 372 Upon receiving the Query message, the egress node has to reply with a 373 Query Reply Message. The Query-Reply Message contains the Query TLV 374 which was received in the Query Message. The Query TLV tells the LSRs 375 along the path which information is being queried and allows 376 intermediate LSRs to piggy back their own queried information on the 377 Query reply message. 379 6. Reply Messages 381 These messages are propagated upstream. There are situations in 382 which the Query message does not reach the end point of the queried 383 LSP. In these scenarios it would be useful if the ingress LSR 384 gathered at least some information about the LSRs which are along the 385 path, up to the one that failed. The Partial Query-Reply message 386 provides this mechanism. It is recommended to use the Partial Query- 387 Reply messages when a Query message fails. There are two types of 388 reply messages: 390 - Query-Reply message (final reply) 391 - Partial Query-Reply message. 393 Both of the reply messages are described in the following sections. 395 6.1. Query-Reply Message encoding 397 This message is generated by the end point of the LSP. It is 398 propagated upstream, by each LSR along the path. 400 The encoding for the Query-Reply message is: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |0| Query-Reply (0x0410) | Message Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Message ID | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Query TLV | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | MessageId TLV | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Optional Parameters | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Message ID 416 32-bit value used to identify this message. 418 Query TLV 419 What is to be queried. See Section Query TLV for encoding. 421 Message Id TLV 422 The value of this parameter is the message id of the corresponding 423 Query message. 425 Optional Parameters 426 This variable length field contains 0 or more parameters, each 427 encoded as a TLV. The optional parameters are: 429 Optional Parameter Length Value 431 ER TLV var See CR-LDP 432 Query Label TLV var See Query Label TLV section 433 IPV4/6 specified link feedback TLV See Improving Topology ... 434 Query Merge Flags TLV var See Query Merge Flags TLV 435 section 437 For simplicity we reuse here TLV types defined for CR-LDP and LDP. 438 They are: 440 - IPV4/6 specified link feedback TLV 441 - ER TLV 442 - Generalized Label TLV (used in the Query Label TLV encoding) 443 - Hop Count TLV. 445 The IPV4/6 specified link feedback TLV is used when the Q1 flag from 446 the Query TLV is set. It is used to encode the bandwidth information. 447 For more information on query flags, Q1, ... Q6, refer to Query TLV 448 section. 450 The ER TLV is a list of hops. It is used when the Query flag Q3 is 451 set. Every LSR should add its IP address. The address to be added 452 should be the outgoing interface address. Addresses are organized as 453 a last-in-fist-out stack (the first address in TLV is considered the 454 top). 456 The Query Label TLV is a list of labels. It is used when the Query 457 flag Q2 is set. It is populated with the labels used for the path 458 which is queried. For tunneled LSPs, the Query Label TLV represents a 459 list of labels associated to the lowest level tunnel. 461 If Q3 and Q2 flags are set, the labels should be encoded in the same 462 order as the hops. 464 Query Merge Flags TLV is a list of pairs of bits. It has variable 465 length and every two bits in the mask will correspond to an LSR along 466 the path. Its length is rounded up to the next byte. If Q6 is set, 467 every LSP along the path will have to set its corresponding bits in 468 the mask. The bits have to be set in the same order as the labels and 469 hops. Usually, Q6 is set when Q2 set and/or Q3 set. 471 For more information for the TLV encodings of the TLVs which are 472 reused, please see CR-LDP draft, LDP draft and IMPROVING TOPOLOGY 473 DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR_LDP draft. 475 6.2. Query-Reply Message Procedures 477 A Query-Reply message is initiated by an egress node which receives a 478 Query message, if the egress is able to identify the queried LSP. If 479 not, the egress replies with a Notification message with "No Lsp to 480 query" status. 482 Upon receiving the Query message, the egress node has to reply with a 483 Query Reply message. The egress node has to encode into the Query- 484 Reply message a MessageId Tlv. The mapping between a Query and a 485 Query-Reply Message is done based on the message id. Besides the 486 MessageId Tlv, the egress has to encode the information that was 487 queried (bandwidth, path, etc). 489 After the encoding is done, the query reply message is sent back, on 490 the reversed path, towards the ingress. Every LSR across the LSP has 491 to encode its information according to what query flags are set. 493 6.3. Partial Query-Reply Message encoding 495 The Partial Query-Reply message is initiated by tandem LSRs along the 496 queried path. The message is generated only if the following rules 497 apply: 498 - if the Query message asked for partial 499 replies (the Query message signals this request 500 through Q8 bit) 501 - if the tandem LSR is configured to provide partial replies. 503 The encoding for the Partial Query-Reply message is identical to the 504 Query-Reply, except the message type. For more details on the 505 encoding please refer to the Query-Reply encoding. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |0|Partial Query-Reply (0x0411) | Message Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Message ID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Query TLV | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | MessageId TLV | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Optional Parameters | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 6.4. Partial Query-Reply Message Procedures 523 The procedures are similar to the Query-Reply's procedures. Upon 524 receiving a Query message, a tandem LSR will check the flag from the 525 Query message (Q8) which signals if the partial replies are requested 526 by the ingress node. If the flag is set, the LSR has to check next if 527 it is configured to fulfill this request. If the LSR supports partial 528 replies, it has to create a Partial Query-Reply and encode the 529 queried data and send it upstream like any Query-Reply messages. It 530 has then to process the Query message according to the Query message 531 procedures. When an LSR receives a Partial Query-Reply from upstream, 532 it should encode its information according to what is queried and 533 propagate the message. It is recommended to use the Partial Query 534 mechanism when the Query message fails (when the ingress LER does not 535 receive a Query-Reply message in response to a Query message). 537 7. Query TLVs 539 The Query TLV is used to specify the information being queried. The 540 Query TLV travels in the Query message to the egress node, where it 541 is copied into a reverse flowing Query-Reply messages and used by the 542 egress and intermediate LSRs to know what information is being 543 queried. 545 The format for the Query TLV is: 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |0|0| Query TLV (0x0840) | Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Query Flags | Reserved | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Query Flags can be set according to what the Query is used for. 557 +--+--+--+--+--+--+--+--+ 558 |Q8|Re|Q6|Q5|Q4|Q3|Q2|Q1| 559 +--+--+--+--+--+--+--+--+ 561 They can be: 562 - Q1 : query the bandwidth; if set, the LSR that 563 receives the Query message has to encode the bandwidth 564 that is available on the link (unused bandwidth); 565 - Q2 : query the labels which are associated to each hop in the 566 path; 567 - Q3 : query the LSRs which form the LSP which is queried; 568 if set, the LSR that received the Query-Reply message 569 has to encode the current hop in the ER-TLV 570 - Q4 : reserved for congestion status; < format - TBD > 571 - Q5 : query the round trip delay; if set, the LSR should fill in 572 the link delay information if available; < format - TBD > 573 - Q6 : query which LSPs along the path are merging points; if set, 574 the LSR that receives the Query message has to encode 575 if it is a merging point; the encoding is done in the 576 Query Merge flags TLV. 578 - Q8 : if set, the ingress requests partial query-replies; 580 7.1. Query Label TLV 582 The Query Label TLV is used to encode the labels used along the path 583 which is queried. Note: Query Label TLV is used in both Query and 584 Query Reply. It is a required parameter in the Query message and it 585 is an optional parameter in Query Reply message. When being used in 586 the Query message, it carries the label or stack of labels which are 587 being followed and queried. When being used in the Query Reply 588 message, it carries the list of labels which make up the queried 589 path. 591 The format for the Query Label TLV is: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 |0|0| Query Label TLV (0x0841)| Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Generalized Label TLV 1 | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 ~ ~ 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Generalized Label TLV n | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Generalized Label TLV is used to encode labels along the path. Please 606 refer to [OPTICAL reference] for more information on the Generalized 607 Label TLV encoding. If the Q2 flag is set, every LSR has to encode 608 the out-label corresponding to the queried LSP. In the Query Label 609 TLV, labels are organized as a last-in-fist-out stack (the first 610 label in TLV is considered the top). They should be encoded in the 611 same order as the hops and the merge flags. 613 7.2. Query Merge Flags TLV 615 The Query Merge Flags TLV is used to encode the information about 616 which LSRs along the path the queried LSP is being merged into. 618 The format for the Query Merge Flags TLV is: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |0|0| Merge Flags TLV (0x0842) | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Number of merge flags | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Merge flags | | | ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 ~ ~ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 The Query Merge Flags TLV has 4 bytes field to store the number of 635 merge flags. This number is equal to the number of LSRs which are 636 traversed by the Query-Reply Message. Each 2 bits in the Merge flags 637 field represent the merge information for an LSR. The bits are set to 638 01 if the LSR does not do merge for the queried LSP and are set to 10 639 otherwise. If the LSR want to hide the merging information, it has to 640 set the merging flags to 00. The length of the encoding is rounded 641 up to the next byte. Every LSR which is asked to encode the merging 642 info into this TLV has to update the Number of merge flags and to set 643 its corresponding bits accordingly. 645 7.3. Status code summary 647 Status Code E Status Data Section Title 649 No Lsp to query 1 0x0000001a "Query Message Procedures..." 651 8. Acknowledgments 653 The authors would like to acknowledge the careful review and comments 654 of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk and Gregory Wright. 656 9. References 658 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 659 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-07.txt, 660 May 2000. 662 [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini 663 S., "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp- 664 refresh-reduct-04.txt. 666 [CR-LDP] Peter Ashwood-Smith et al., "Improving Topology Data Base 667 Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt 669 Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional 670 Description" draft-ashwood-generalized-mpls-signaling-00.txt 671 10. Author's Addresses 673 Peter Ashwood-Smith Antonela Paraschiv 674 Nortel Networks Corp. Nortel Networks Corp. 675 P.O. Box 3511 Station C, 600 Technology Park Drive 676 Ottawa, ON K1Y 4H7 Billerica, MA 01821 677 Canada USA 678 Phone: +1 613-763-4534 phone: +1 978-288-6136 679 petera@nortelnetworks.com antonela@nortelnetworks.com 681 Full Copyright Statement 683 Copyright (C) The Internet Society (date). All Rights Reserved. This 684 document and translations of it may be copied and furnished to 685 others, and derivative works that comment on or otherwise explain it 686 or assist in its implementation may be prepared, copied, published 687 and distributed, in whole or in part, without restriction of any 688 kind, provided that the above copyright notice and this paragraph 689 are included on all such copies and derivative works. However, this 690 document itself may not be modified in any way, such as by removing 691 the copyright notice or references to the Internet Society or other 692 Internet organizations, except as needed for the purpose of 693 developing Internet standards in which case the procedures for 694 copyrights defined in the Internet Standards process must be 695 followed, or as required to translate it into languages other than 696 English. 698 The limited permissions granted above are perpetual and will not be 699 revoked by the Internet Society or its successors or assigns.