idnits 2.17.1 draft-ietf-mpls-lsp-query-03.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 : ---------------------------------------------------------------------------- ** 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 16 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 167: '... MUST appear in the order specified ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 119 has weird spacing: '...essages have ...' == Line 340 has weird spacing: '...dresses are o...' == Line 479 has weird spacing: '...dresses are o...' == Line 530 has weird spacing: '...ical to the...' == Line 531 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 (August 2001) is 8262 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 77, but not defined == Unused Reference: 'CR-LDP' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RSVP-RR' is defined on line 687, 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: 9 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: February 2002 Nortel Networks 5 August 2001 7 MPLS LDP Query Message Description 9 draft-ietf-mpls-lsp-query-03.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 LDP 31 messages, the Query Message and Query-Reply Message and Partial 32 Query-Reply Message (the last one is almost identical to the Query- 33 Reply message; therefore all references to the Query-Reply messages 34 imply the Partial Query-Reply messages as well, unless otherwise 35 specified). An LER sends a Query message when it needs to find out 36 information about an LSP. The Query message is sent for an 37 established LSP. The Query message can be used for LDP LSPs as well 38 as for CR-LSPs. The queried data is encoded into the Query-Reply 39 messages. 41 Contents 43 1 Introduction ............................................. 3 44 2 Overview ................................................. 3 45 2.1 LDP Overview ............................................. 3 46 2.2 CR-LDP Overview .......................................... 4 47 3 LDP Message Structure Overview ........................... 4 48 4 Behavior of LSRs with constraints in handling the query messages 5 49 4.1 LSR does not support the query messages .................. 6 50 4.2 LSR cannot share any information ......................... 6 51 4.3 LSR cannot share some of the queried information ........ 6 52 4.4 LSR can share the queried information ................... 7 53 5 Query Message ............................................ 7 54 5.1 Query Message encoding ................................ 8 55 5.2 Query Message Procedures ................................. 9 56 6 Reply Messages .......................................... 10 57 6.1 Query-Reply Message encoding .......................... 11 58 6.2 Query-Reply Message Procedures ........................... 13 59 6.3 Partial Query-Reply Message encoding .................. 13 60 6.4 Partial Query-Reply Message Procedures ................... 14 61 7 Query TLVs ............................................... 14 62 7.1 Query Label TLV .......................................... 15 63 7.2 Query Merge Flags TLV .................................... 16 64 7.3 Status code summary ..................................... 16 65 8 Acknowledgments .......................................... 17 66 9 References ............................................... 17 67 10 Author's Addresses ....................................... 18 68 Changes from previous version: 70 o Added clarification on Reply message usage. 71 o Added clarification on query flags. 72 o Added clarification on how to handle the Query Message Procedures when PHP in use. 74 1. Introduction 76 The original Multiprotocol Label Switching (MPLS) architecture 77 [MPLS-ARCH] was been defined to support the forwarding of data based 78 on a label. The MPLS architecture does not assume a single label 79 distribution protocol. A number of different label distribution 80 protocols are being standardized. This draft describes the query 81 mechanism for an LSP or CR-LSP. It specifies procedures and encodings 82 for the new messages added for the query mechanism. Extensions to 83 RSVP-TE to provide the same functionality are subject for future 84 study and will be covered in future draft versions. 86 The new LDP messages are: Query Message, Query-Reply Message and 87 Partial Query-Reply Message. The following new TLVs are added to 88 accommodate the encodings for the new query messages: 89 - Query TLV 90 - Query Label TLV 91 - Query Merge Flags TLV 93 LDP uses the TCP transport for session, advertisement and 94 notification messages; i.e., for everything but the UDP-based 95 discovery mechanism. The messages which are added to support the 96 query mechanism are sent over TCP as well. 98 2. Overview 100 2.1. LDP Overview 102 Label Distribution Protocol (LDP) defined in [LDP Specification] 103 contains a set of procedures and messages by which Label Switched 104 Routers (LSR) establish Label Switch Paths (LSP) through a network by 105 mapping network layer routing information directly to data-link layer 106 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 107 with each LSP it creates. The FEC associated with an LSP specifies 108 which packets are mapped to that LSP. 110 2.2. CR-LDP Overview 112 As described in [Constraint-Base LSP Setup using LDP], Constraint 113 Base Routing (CR-LDP) offers the opportunity to extend the 114 information used to setup paths beyond what is available for the 115 routing protocol. 117 3. LDP Message Structure Overview 119 As described in LDP Specification draft, all LDP messages have the 120 following format: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 |U| Message Type | Message Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Message ID | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 + + 131 | Mandatory Parameters | 132 + + 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 + + 137 | Optional Parameters | 138 + + 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 U bit 143 Unknown message bit. Upon receipt of an unknown message, if U is 144 clear (=0), a notification is returned to the message originator; 145 if U is set (=1), the unknown message is silently ignored. 147 Message Type 148 Identifies the type of message 150 Message Length 151 Specifies the cumulative length in octets of the Message ID, 152 Mandatory Parameters, and Optional Parameters. 154 Message ID 155 32-bit value used to identify this message. Used by the sending 156 LSR to facilitate identifying notification messages that may apply 157 to this message. An LSR sending a notification message in 158 response to this message should include this Message Id in the 159 Status TLV carried by the notification message; see Section 160 "Notification Message". 162 Mandatory Parameters 163 Variable length set of required message parameters. Some messages 164 have no required parameters. 166 For messages that have required parameters, the required parameters 167 MUST appear in the order specified by the individual message 168 specifications in the sections that follow. 170 Optional Parameters 171 Variable length set of optional message parameters. Many messages 172 have no optional parameters. 174 For messages that have optional parameters, the optional parameters 175 may appear in any order. 177 4. Behavior of LSRs with constraints in handling the query messages 179 Upon receiving a Query message, an LSR has to behave according to its 180 configuration constraints in handling the query messages and 181 returning the queried information. The following cases were 182 identified: 183 - the LSR does not support the code to handle the messages 184 for the query mechanism 185 - the LSR supports the code to handle the messages for the 186 query mechanism, but it is configured not to return any data 187 - the LSR supports the code to handle the messages for the 188 query mechanism, but it is configured not to return part of 189 the queried data 190 - the LSR supports the code to handle the messages for the 191 query mechanism, and it is configured to return all the data 192 which is queried. 194 The draft provides flexibility to handle each of the above cases. 196 4.1. LSR does not support the query messages 198 In this case, the LSR has to behave as if it received an unknown 199 message type. It has therefore to honor the U bit. 201 4.2. LSR cannot share any information 203 In this case, the LSR is able to decode and process the query 204 messages. However, it is configured to hide all the data. It should 205 propagate the message after it encodes a zero-length TLV for its hop 206 in the hop list in the Query message. When Query-Reply message is 207 received from downstream, the LSR is requested to propagate the reply 208 message upstream after it encodes the zero-length tlvs for the 209 queried data. When the ingress receives back the reply, it can 210 identify which TLVs are empty; it can therefore ignore the zero- 211 length TLVs and process the rest of the data. 213 Note: zero-length TLV encoding can be used for all types of queried 214 information except the merge information. The LSR is requested to 215 signal the fact that the merging information is private by encoding a 216 special value in the corresponding merge bits (for more information 217 on the merge flags values please refer to Query Merge Flags TLV 218 section). 220 4.3. LSR cannot share some of the queried information 222 In this case, the LSR is able to decode and process the query 223 messages. It has to propagate the query messages. It has to encode 224 values for the data types that it is willing to return and zero- 225 length TLVs for values for the data that is hidden. 227 Note: zero-length TLV encoding can be used for all types of queried 228 information except the merge information. The LSR is requested to 229 signal the fact that the merging information is private by encoding a 230 special value in the corresponding merge bits (for more information 231 on the merge flags values please refer to Query Merge Flags TLV 232 section). 234 4.4. LSR can share the queried information 236 This is the normal case for an LSR. In this case, the LSR's behavior 237 has to follow the query and replies procedures described in the 238 following sections of the draft. 240 In order to have consistency among data encoded in the query and 241 reply messages, each LSR which can propagate the messages has to 242 encode its information in the query and in the reply messages. 244 The decision that an LSR can share the queried information has to be 245 controlled through configuration flags. This way each node along the 246 path can protect its data if they consider it private. 248 Note: It would be more efficient to control/restrict the private data 249 per MPLS cloud (inter MPLS domain) and not per LSR node (inter and 250 intra MPLS domain). When there are different MPLS clouds which have 251 nodes belonging to different vendors, the control of the private 252 information could be restricted to the boundary nodes. Within an MPLS 253 domain, there should be no restrictions on the queried information. 254 It would be useful to have some knowledge on which are the nodes on 255 the boundaries and have only those hiding the queried data. Because 256 there is no mechanism to identify which are the boundary nodes, this 257 is subject for future study. 259 5. Query Message 261 This sections describes the Query message and its encodings and 262 procedures. This message is meant to be used to gather information 263 about an LSP. It can be sent at any time for an established LSP. 264 The draft currently describes the procedures for the cases when the 265 Query Message is initiated by the ingress LER. Future versions of 266 the draft may add the procedures for the query message when issued 267 from a core LSR or from egress. 269 The Query Message can be used to gather information about: 270 - LSRs which form the LSP 271 - labels along the LSP 272 - information on what LSRs are merging points along the path 273 - unused bandwidth (as described in "Improving Topology Data 274 Base Accuracy with LSP Feedback") 275 - anything that is needed in the future and can be computed and 276 encoded in a TLV. 278 The queried information is encoded in the Query-Reply message which 279 is sent back upstream, as a response to the Query message. 281 5.1. Query Message encoding 283 The encoding for the Query message is: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |0| Query (0x0409) | Message Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Message ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Query Label TLV | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Query TLV | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Hop Count TLV | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Optional Parameters | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Message ID 302 32-bit value used to identify this message. 304 Query Label TLV 305 The label associated to the LSP which is queried. This TLV is a 306 list of Generalized Label TLVs [OPTICAL reference]. The 307 Generalized Label TLV provides a more generic encoding for 308 different types of labels. Most of the time the list has one 309 element; this is the case when the LSP is not tunneled. For 310 tunneled LSPs, the Label TLV has more that one element; it has to 311 behave like a label stack (it contains the previous label and the 312 tunnel's label). See Section Query Label TLV for more information 313 on Label TLV encoding. 315 Query TLV 316 What to query. See Section Query TLV for encoding. 318 Hop Count TLV 319 Specifies the number of LSR hops that can still be traversed 320 before the message is dropped due to loop detection. It is 321 initialized to the max value of 255 (or the configured value, if 322 any). Every LSR that receives the Query Message has to subtract 1 323 from the Hop Count value. The Query message should be dropped if 324 the hop count value becomes zero; a Notification signaling Loop 325 Detection should be sent in reply to the sender of the message. 326 See [LDP Specification] for Hop Count TLV encoding. 328 Optional Parameters 329 This variable length field contains 0 or more parameters, each 330 encoded as a TLV. 332 Optional Parameter Length Value 334 ER TLV var See CR-LDP 335 LSPID TLV var See CR-LDP 336 FEC TLV var See LDP 338 The ER TLV is a list of hops. It is used when the Query flag Q3 is 339 set. Every LSR should add its IP address. The address to be added 340 should be the outgoing interface address. Addresses are organized as 341 a last-in-fist-out stack (the first address in TLV is considered the 342 top). By carrying this TLV in the Query Message and preserving this 343 order for the hops, we allow the possibility to interwork the Query 344 Message with the RSVP Path message. 346 FEC TLV is used when PHP is in use, for LDP. 348 LSPID TLV is used when PHP is in use, for CR-LDP. 350 For more details on the FEC or LSPID usage, please refer to the Query 351 Message Procedures below. 353 5.2. Query Message Procedures 355 The LER ingress initiates the Query message. It populates the Query 356 TLV Parameters according to what kind of information it wants to 357 gather. The query for an LSP is done by its label. The only data that 358 the Query Message could carry is the list of hops. This way, each 359 node along the path can have a complete route from source to 360 destination. This is useful for network management. Please note that 361 this parameter is optional. If the Query message does not contain the 362 ER TLV, it should be propagated by LSRs along the path without the ER 363 TLV. 365 Upon receiving a Query Message, an LSR decodes the label to identify 366 which LSP is queried. If it cannot find the LSP which is using the 367 label, it sends back a Notification message with "No Lsp to query" 368 status. Otherwise, it checks which is the out label which is bound to 369 the queried in-label and which is the downstream LSR peer. It 370 replaces the in-label from Query Label TLV with the out-label used by 371 the LSP. It then passes the Query message to the downstream peer. 373 When the Query message gets to a tunnel, it has to be able to handle 374 both the previous label and the tunnel's label. The Query Label TLV 375 behaves like a label stack. The previous label is pushed and the 376 tunnel label is used. At the end of the tunnel, we need to pop the 377 stack and start substituting the lower level labels. 379 Upon receiving the Query message, the egress node has to reply with a 380 Query Reply Message. The Query-Reply Message contains the Query TLV 381 which was received in the Query Message. The Query TLV tells the LSRs 382 along the path which information is being queried and allows 383 intermediate LSRs to piggy back their own queried information on the 384 Query reply message. 386 The initiator of a Query reply might nor receive a response back. In 387 this case, it is the initiator's responsibility to decide if and when 388 to retry. 390 If PHP is in use, the Query Message sent from the PHP to the 391 destination node needs to carry the FEC (for LDP) or LSPID (for CR- 392 LDP). This information is required because the label between the PHP 393 and the destination is a special label and the destination cannot 394 uniquely identify the queried LSP just by using the label value. If 395 the PHP does not encode the FEC or the LSPID, the destination node 396 should reply with a notification message with "Ambiguous label 397 value". 399 6. Reply Messages 401 These messages are propagated upstream. There are two types of reply 402 messages: 404 - Query-Reply message (final reply) 405 - Partial Query-Reply message. 407 The Reply messages carry the queried information upstream. They are 408 sent in response to a Query message. The ingress which initiated the 409 Query message is interested to gather the information from all the 410 nodes along the queried LSP. However, there are situations in which 411 the Query message does not reach the end point of the queried LSP. In 412 these scenarios it would be useful if the ingress LSR gathered at 413 least some information about the LSRs which are along the path, up to 414 the one that failed. The Partial Query-Reply message provides this 415 mechanism. It is recommended to use the Partial Query-Reply messages 416 when a Query message fails. If the Reply message is full, TCP will 417 take care of it by segmenting and re-assembling the message. 419 Both reply messages are described in the following sections. 421 6.1. Query-Reply Message encoding 423 This message is generated by the end point of the LSP. It is 424 propagated upstream, by each LSR along the path. 426 The encoding for the Query-Reply message is: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |0| Query-Reply (0x0410) | Message Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Message ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Query TLV | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | MessageId TLV | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Optional Parameters | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Message ID 443 32-bit value used to identify this message. 445 Query TLV 446 What is to be queried. See Section Query TLV for encoding. 448 Message Id TLV 449 The value of this parameter is the message id of the corresponding 450 Query message. 452 Optional Parameters 453 This variable length field contains 0 or more parameters, each 454 encoded as a TLV. The optional parameters are: 456 Optional Parameter Length Value 458 ER TLV var See CR-LDP 459 Query Label TLV var See Query Label TLV section 460 IPV4/6 specified link feedback TLV See Improving Topology ... 461 Query Merge Flags TLV var See Query Merge Flags TLV 462 section 464 For simplicity we reuse here TLV types defined for CR-LDP and LDP. 465 They are: 467 - IPV4/6 specified link feedback TLV 468 - ER TLV 469 - Generalized Label TLV (used in the Query Label TLV encoding) 470 - Hop Count TLV. 472 The IPV4/6 specified link feedback TLV is used when the Q1 flag from 473 the Query TLV is set. It is used to encode the bandwidth information. 474 For more information on query flags, Q1, Q2, Q3 and Q6, refer to 475 Query TLV section. 477 The ER TLV is a list of hops. It is used when the Query flag Q3 is 478 set. Every LSR should add its IP address. The address to be added 479 should be the outgoing interface address. Addresses are organized as 480 a last-in-fist-out stack (the first address in TLV is considered the 481 top). 483 The Query Label TLV is a list of labels. It is used when the Query 484 flag Q2 is set. It is populated with the labels used for the path 485 which is queried. For tunneled LSPs, the Query Label TLV represents a 486 list of labels associated to the lowest level tunnel. 488 If Q3 and Q2 flags are set, the labels should be encoded in the same 489 order as the hops. 491 Query Merge Flags TLV is a list of pairs of bits. It has variable 492 length and every two bits in the mask will correspond to an LSR along 493 the path. Its length is rounded up to the next byte. If Q6 is set, 494 every LSP along the path will have to set its corresponding bits in 495 the mask. The bits have to be set in the same order as the labels and 496 hops. Usually, Q6 is set when Q2 set and/or Q3 set. 498 For more information for the TLV encodings of the TLVs which are 499 reused, please see CR-LDP draft, LDP draft and IMPROVING TOPOLOGY 500 DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR_LDP draft. 502 6.2. Query-Reply Message Procedures 504 A Query-Reply message is initiated by an egress node which receives a 505 Query message, if the egress is able to identify the queried LSP. If 506 not, the egress replies with a Notification message with "No Lsp to 507 query" status. 509 Upon receiving the Query message, the egress node has to reply with a 510 Query Reply message. The egress node has to encode into the Query- 511 Reply message a MessageId Tlv. The mapping between a Query and a 512 Query-Reply Message is done based on the message id. Besides the 513 MessageId Tlv, the egress has to encode the information that was 514 queried (bandwidth, path, etc). 516 After the encoding is done, the query reply message is sent back, on 517 the reversed path, towards the ingress. Every LSR across the LSP has 518 to encode its information according to what query flags are set. 520 6.3. Partial Query-Reply Message encoding 522 The Partial Query-Reply message is initiated by LSRs along the 523 queried path. The message is generated only if the following rules 524 apply: 525 - if the Query message asked for partial 526 replies (the Query message signals this request 527 through Q8 bit) 528 - if the LSR is configured to provide partial replies. 530 The encoding for the Partial Query-Reply message is identical to the 531 Query-Reply, except the message type. For more details on the 532 encoding please refer to the Query-Reply encoding. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |0|Partial Query-Reply (0x0411) | Message Length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Message ID | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Query TLV | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | MessageId TLV | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Optional Parameters | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 6.4. Partial Query-Reply Message Procedures 549 The procedures are similar to the Query-Reply's procedures. Upon 550 receiving a Query message, an LSR will check the flag from the Query 551 message (Q8) which signals if the partial replies are requested by 552 the ingress node. If the flag is set, the LSR has to check next if it 553 is configured to fulfill this request. If the LSR supports partial 554 replies, it has to create a Partial Query-Reply and encode the 555 queried data and send it upstream like any Query-Reply messages. It 556 has then to process the Query message according to the Query message 557 procedures. When an LSR receives a Partial Query-Reply from upstream, 558 it should encode its information according to what is queried and 559 propagate the message. It is recommended to use the Partial Query 560 mechanism when the Query message fails (when the ingress LER does not 561 receive a Query-Reply message in response to a Query message). 563 7. Query TLVs 565 The Query TLV is used to specify the information being queried. The 566 Query TLV travels in the Query message to the egress node, where it 567 is copied into a reverse flowing Query-Reply messages and used by the 568 egress and intermediate LSRs to know what information is being 569 queried. 571 The format for the Query TLV is: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |0|0| Query TLV (0x0840) | Length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Query Flags | Reserved | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Query Flags can be set according to what the Query is used for. 583 +--+--+--+--+--+--+--+--+ 584 |Q8|Re|Q6|Re|Re|Q3|Q2|Q1| 585 +--+--+--+--+--+--+--+--+ 587 They can be: 589 - Q1 : query the bandwidth; if set, the LSR that 590 receives the Query message has to encode the bandwidth 591 that is available on the link (unused bandwidth); 592 - Q2 : query the labels which are associated to each hop in the 593 path; 594 - Q3 : query the LSRs which form the LSP which is queried; 595 if set, the LSR that received the Query-Reply message 596 has to encode the current hop in the ER-TLV 597 - Q6 : query which LSPs along the path are merging points; if set, 598 the LSR that receives the Query message has to encode 599 if it is a merging point; the encoding is done in the 600 Query Merge flags TLV. 601 - Q8 : if set, the ingress requests partial query-replies; 602 each LSR along the path is signaled to send a Partial Query Reply. 604 7.1. Query Label TLV 606 The Query Label TLV is used to encode the labels used along the path 607 which is queried. Note: Query Label TLV is used in both Query and 608 Query Reply. It is a required parameter in the Query message and it 609 is an optional parameter in Query Reply message. When being used in 610 the Query message, it carries the label or stack of labels which are 611 being followed and queried. When being used in the Query Reply 612 message, it carries the list of labels which make up the queried 613 path. 615 The format for the Query Label TLV is: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |0|0| Query Label TLV (0x0841)| Length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Generalized Label TLV 1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 ~ ~ 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Generalized Label TLV n | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Generalized Label TLV is used to encode labels along the path. Please 630 refer to [OPTICAL reference] for more information on the Generalized 631 Label TLV encoding. If the Q2 flag is set, every LSR has to encode 632 the out-label corresponding to the queried LSP. In the Query Label 633 TLV, labels are organized as a last-in-fist-out stack (the first 634 label in TLV is considered the top). They should be encoded in the 635 same order as the hops and the merge flags. 637 7.2. Query Merge Flags TLV 639 The Query Merge Flags TLV is used to encode the information about 640 which LSRs along the path the queried LSP is being merged into. 642 The format for the Query Merge Flags TLV is: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |0|0| Merge Flags TLV (0x0842) | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Number of merge flags | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Merge flags | | | ~ 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 ~ ~ 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 The Query Merge Flags TLV has 4 bytes field to store the number of 659 merge flags. This number is equal to the number of LSRs which are 660 traversed by the Query-Reply Message. Each 2 bits in the Merge flags 661 field represent the merge information for an LSR. The bits are set to 662 01 if the LSR does not do merge for the queried LSP and are set to 10 663 otherwise. If the LSR want to hide the merging information, it has to 664 set the merging flags to 00. The length of the encoding is rounded 665 up to the next byte. Every LSR which is asked to encode the merging 666 info into this TLV has to update the Number of merge flags and to set 667 its corresponding bits accordingly. 669 7.3. Status code summary 671 Status Code E Status Data Section Title 673 No Lsp to query 1 0x0000001a "Query Message Procedures..." 674 Ambiguous label value 1 0x0000001b "Query Message Procedures..." 675 8. Acknowledgments 677 The authors would like to acknowledge the careful review and comments 678 of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk, Gregory Wright and 679 Adrian Farrel. 681 9. References 683 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 684 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-07.txt, 685 May 2000. 687 [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini 688 S., "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp- 689 refresh-reduct-04.txt. 691 [CR-LDP] Peter Ashwood-Smith et al., "Improving Topology Data Base 692 Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt 694 Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional 695 Description" draft-ashwood-generalized-mpls-signaling-00.txt 696 10. Author's Addresses 698 Peter Ashwood-Smith Antonela Paraschiv 699 Nortel Networks Corp. Nortel Networks Corp. 700 P.O. Box 3511 Station C, 600 Technology Park Drive 701 Ottawa, ON K1Y 4H7 Billerica, MA 01821 702 Canada USA 703 Phone: +1 613-763-4534 phone: +1 978-288-6136 704 petera@nortelnetworks.com antonela@nortelnetworks.com 706 Full Copyright Statement 708 Copyright (C) The Internet Society (date). All Rights Reserved. This 709 document and translations of it may be copied and furnished to 710 others, and derivative works that comment on or otherwise explain it 711 or assist in its implementation may be prepared, copied, published 712 and distributed, in whole or in part, without restriction of any 713 kind, provided that the above copyright notice and this paragraph 714 are included on all such copies and derivative works. However, this 715 document itself may not be modified in any way, such as by removing 716 the copyright notice or references to the Internet Society or other 717 Internet organizations, except as needed for the purpose of 718 developing Internet standards in which case the procedures for 719 copyrights defined in the Internet Standards process must be 720 followed, or as required to translate it into languages other than 721 English. 723 The limited permissions granted above are perpetual and will not be 724 revoked by the Internet Society or its successors or assigns.