idnits 2.17.1 draft-ietf-mpls-lsp-query-06.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 18 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 491 has weird spacing: '...dresses are o...' == Line 541 has weird spacing: '...ical to the...' == Line 542 has weird spacing: '... except the ...' == Line 593 has weird spacing: '...e Query is u...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7739 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 -- Looks like a reference, but probably isn't: 'RFC2119' on line 108 == 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 (~~), 10 warnings (==), 4 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: August 2003 Nortel Networks 5 February 2003 7 Multi Protocol Label Switching Label Distribution Protocol Query Message Description 9 draft-ietf-mpls-lsp-query-06.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 Specification ............................................ 3 46 3 Overview ................................................. 3 47 3.1 LDP Overview ............................................. 3 48 3.2 CR-LDP Overview .......................................... 4 49 4 LDP Message Structure Overview ........................... 4 50 5 LSRs with constraints in handling the query messages ..... 5 51 5.1 LSR does not support the query messages .................. 6 52 5.2 LSR cannot share any information ......................... 6 53 5.3 LSR cannot share some of the queried information ........ 6 54 5.4 LSR can share the queried information ................... 7 55 6 Query Message ............................................ 7 56 6.1 Query Message encoding ................................ 8 57 6.2 Query Message Procedures ................................. 9 58 7 Reply Messages .......................................... 10 59 7.1 Query-Reply Message encoding .......................... 11 60 7.2 Query-Reply Message Procedures ........................... 12 61 7.3 Partial Query-Reply Message encoding .................. 13 62 7.4 Partial Query-Reply Message Procedures ................... 13 63 8 Query TLVs ............................................... 14 64 8.1 Query Label TLV .......................................... 15 65 8.2 Query Merge Flags TLV .................................... 16 66 8.3 Status code summary ..................................... 17 67 9 Security Considerations .................................. 17 68 10 IANA Considerations ...................................... 17 69 10.1 Message Type Space Extension ............................. 17 70 10.2 TLV Type Name Space Extension ............................ 17 71 10.3 Status Code Space Extension .............................. 18 72 11 Acknowledgments .......................................... 18 73 12 Normative References ..................................... 18 74 13 Author's Addresses ....................................... 19 75 Changes from previous version: 77 o Updated IANA 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. Specification 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Overview 111 3.1. LDP Overview 113 Label Distribution Protocol (LDP) defined in [4] contains a set of 114 procedures and messages by which Label Switched Routers (LSR) 115 establish Label Switch Paths (LSP) through a network by mapping 116 network layer routing information directly to data-link layer 117 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 118 with each LSP it creates. The FEC associated with an LSP specifies 119 which packets are mapped to that LSP. 121 3.2. CR-LDP Overview 123 As described in CR-LDP [1], Constraint Base Routing offers the 124 opportunity to extend the information used to setup paths beyond what 125 is available from the routing protocol. For instance, an LSP can be 126 setup based on explicit route constraints, QoS constraints, and other 127 constraints. 129 4. LDP Message Structure Overview 131 The LDP message format is specified in the LDP Specification [4]. All 132 LDP messages have the following format: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |U| Message Type | Message Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Message ID | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 + + 143 | Mandatory Parameters | 144 + + 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 + + 149 | Optional Parameters | 150 + + 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 U bit 155 Unknown message bit. Upon receipt of an unknown message, if U is 156 clear (=0), a notification is returned to the message originator; 157 if U is set (=1), the unknown message is silently ignored. 159 Message Type 160 Identifies the type of message 162 Message Length 163 Specifies the cumulative length in octets of the Message ID, 164 Mandatory Parameters, and Optional Parameters. 166 Message ID 167 32-bit value used to identify this message. It is used by the 168 sending LSR to facilitate identifying notification messages that 169 may apply to this message. An LSR sending a notification message 170 in response to this message should include this MessageId in the 171 Status TLV carried by the notification message; see Section 172 "Notification Message". 174 Mandatory Parameters 175 Variable length set of required message parameters. Some messages 176 have no required parameters. 178 For messages that have required parameters, the required parameters 179 must appear in the order specified by the individual message 180 specifications in the sections that follow. 182 Optional Parameters 183 Variable length set of optional message parameters. Many messages 184 have no optional parameters. 186 For messages that have optional parameters, the optional parameters 187 may appear in any order. 189 5. LSRs with constraints in handling the query messages 191 Upon receiving a Query message, an LSR has to behave according to its 192 configuration constraints in handling the query messages and 193 returning the queried information. The following cases were 194 identified: 195 - the LSR does not support the code to handle the messages 196 for the query mechanism 197 - the LSR supports the code to handle the messages for the 198 query mechanism, but it is configured not to return any data 199 - the LSR supports the code to handle the messages for the 200 query mechanism, but it is configured not to return part of 201 the queried data 202 - the LSR supports the code to handle the messages for the 203 query mechanism, and it is configured to return all the data 204 which is queried. 206 This memo provides flexibility to handle each of the above cases. 208 5.1. LSR does not support the query messages 210 In this case, the LSR has to behave as if it received an unknown 211 message type. It therefore honors the U bit. 213 5.2. LSR cannot share any information 215 In this case, the LSR is able to decode and process the query 216 messages. However, it is configured to hide all the data. It should 217 propagate the message after it encodes a zero-length TLV for its hop 218 in the hop list in the Query message. When Query-Reply message is 219 received from downstream, the LSR is requested to propagate the reply 220 message upstream after it encodes the zero-length TLVs for the 221 queried data. When the ingress receives back the reply, it can 222 identify which TLVs are empty; it can therefore ignore the zero- 223 length TLVs and process the rest of the data. 225 Note: zero-length TLV encoding can be used for all types of queried 226 information except the merge information. The LSR is requested to 227 signal the fact that the merging information is private by encoding a 228 special value in the corresponding merge bits (for more information 229 on the merge flags values please refer to Section 7.2 of this memo - 230 Query Merge Flags TLV ). 232 5.3. LSR cannot share some of the queried information 234 In this case, the LSR is able to decode and process the query 235 messages. It has to propagate the query messages. It has to encode 236 values for the data types that it is willing to return and zero- 237 length TLVs for values for the data that is hidden. 239 Note: zero-length TLV encoding can be used for all types of queried 240 information except the merge information. The LSR is requested to 241 signal the fact that the merging information is private by encoding a 242 special value in the corresponding merge bits (for more information 243 on the merge flags values please refer to Section 7.2 of this memo - 244 Query Merge Flags TLV). 246 5.4. LSR can share the queried information 248 In this case, the LSR's behavior has to follow the query and replies 249 procedures described in the following sections of this memo. 251 In order to have consistency among data encoded in the query and 252 reply messages, each LSR which can propagate the messages has to 253 encode its information in the query and in the reply messages. 255 The decision that an LSR can share the queried information has to be 256 controlled through configuration flags. This way each node along the 257 path can protect its data if they consider it private. 259 Note: It would be more efficient to control/restrict the private data 260 per MPLS cloud (inter MPLS domain) and not per LSR node (inter and 261 intra MPLS domain). When there are different MPLS clouds which have 262 nodes belonging to different vendors, the control of the private 263 information could be restricted to the boundary nodes. Within an MPLS 264 domain, there should be no restrictions on the queried information. 265 It would be useful to have some knowledge on which are the nodes on 266 the boundaries and have only those hiding the queried data. Because 267 there is no mechanism to identify which are the boundary nodes, this 268 is subject for future study. 270 6. Query Message 272 This sections describes the Query message and its encodings and 273 procedures. This message is meant to be used to gather information 274 about an LSP. It can be sent at any time for an established LSP. 275 This memo currently describes the procedures for the cases when the 276 Query Message is initiated by the ingress LER. Additional procedures 277 may be added in the future for the query message when issued from an 278 LSR or from egress. 280 The Query Message can be used to gather information about: 281 - LSRs which form the LSP 282 - labels along the LSP 283 - information on what LSRs are merging points along the path 284 - unused bandwidth (as described in "Improving Topology Data 285 Base Accuracy with LSP Feedback" [2]) 286 - anything that is needed in the future and can be computed and 287 encoded in a TLV. 289 The queried information is encoded in the Query-Reply message which 290 is sent back upstream, as a response to the Query message. 292 6.1. Query Message encoding 294 The encoding for the Query message is: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |0| Query type TBD IANA | Message Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Message ID | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Query Label TLV | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Query TLV | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Hop Count TLV | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Optional Parameters | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Message ID 313 32-bit value used to identify this message. 315 Query Label TLV 316 The label associated to the LSP which is queried. This TLV is a 317 list of Generalized Label TLVs [3]. The Generalized Label TLV 318 provides a more generic encoding for different types of labels. 319 Most of the time the list has one element; this is the case when 320 the LSP is not tunneled. For tunneled LSPs, the Label TLV has 321 more that one element; it has to behave like a label stack (it 322 contains the previous label and the tunnel's label). See Section 323 7.1 of this memo - Query Label TLV - for more information on Label 324 TLV encoding. 326 Query TLV 327 What to query. See Section 7 of this memo - Query TLV - for 328 encoding. 330 Hop Count TLV 331 Specifies the number of LSR hops that can still be traversed 332 before the message is dropped due to loop detection. It is 333 initialized to the max default value of 255 (or the configured 334 value, if any). Every LSR that receives the Query Message has to 335 subtract 1 from the Hop Count value. The Query message should be 336 dropped if the hop count value becomes zero; a Notification 337 signaling Loop Detection should be sent in reply to the sender of 338 the message. See [4] for Hop Count TLV encoding. 340 Optional Parameters 341 This variable length field contains 0 or more parameters, each 342 encoded as a TLV. 344 Optional Parameter Length Value 346 ER TLV var See [1] 347 LSPID TLV var See [1] 348 FEC TLV var See [4] 350 The ER TLV is a list of hops. It is used when the Query flag Q3 is 351 set. Every LSR should add its IP address. The address to be added 352 should be the outgoing interface address. Addresses are organized as 353 a last-in-fist-out stack (the first address in TLV is considered the 354 top). By carrying this TLV in the Query Message and preserving this 355 order for the hops, we allow the possibility to interwork the Query 356 Message with the RSVP Path message. 358 FEC TLV is used when PHP is in use, for LDP. 360 LSPID TLV is used when PHP is in use, for CR-LDP. 362 For more details on the FEC or LSPID usage, please refer to the Query 363 Message Procedures below. 365 6.2. Query Message Procedures 367 The LER ingress initiates the Query message. It populates the Query 368 TLV Parameters according to what kind of information it wants to 369 gather. The query for an LSP is done by its label. The only data that 370 the Query Message could carry is the list of hops. This way, each 371 node along the path can have a complete route from source to 372 destination. This is useful for network management. Please note that 373 this parameter is optional. If the Query message does not contain the 374 ER TLV, it should be propagated by LSRs along the path without the ER 375 TLV. 377 Upon receiving a Query Message, an LSR decodes the label to identify 378 which LSP is queried. If it cannot find the LSP which is using the 379 label, it sends back a Notification message with "No LSP to query" 380 status. Otherwise, it checks which is the out label which is bound to 381 the queried in-label and which is the downstream LSR peer. It 382 replaces the in-label from Query Label TLV with the out-label used by 383 the LSP. It then passes the Query message to the downstream peer. 385 When the Query message gets to a tunnel, it has to be able to handle 386 both the previous label and the tunnel's label. The Query Label TLV 387 behaves like a label stack. The previous label is pushed and the 388 tunnel label is used. At the end of the tunnel, we need to pop the 389 stack and start substituting the lower level labels. 391 Upon receiving the Query message, the egress node has to reply with a 392 Query Reply Message. The Query-Reply Message contains the Query TLV 393 which was received in the Query Message. The Query TLV tells the LSRs 394 along the path which information is being queried and allows 395 intermediate LSRs to piggy back their own queried information on the 396 Query reply message. 398 The initiator of a Query reply might not receive a response back. In 399 this case, it is the initiator's responsibility to decide if and when 400 to retry. 402 If PHP is in use, the Query Message sent from the PHP to the 403 destination node needs to carry the FEC (for LDP) or LSPID (for CR- 404 LDP). This information is required because the label between the PHP 405 and the destination is a special label and the destination cannot 406 uniquely identify the queried LSP just by using the label value. If 407 the PHP does not encode the FEC or the LSPID, the destination node 408 should reply with a notification message with "Ambiguous label 409 value". 411 7. Reply Messages 413 These messages are propagated upstream. There are two types of reply 414 messages: 416 - Query-Reply message (final reply) 417 - Partial Query-Reply message. 419 The Reply messages carry the queried information upstream. A Query- 420 Reply message is sent in response to a Query message. The ingress 421 which initiated the Query message is interested to gather the 422 information from all the nodes along the queried LSP. However, there 423 are situations in which the Query message does not reach the end 424 point of the queried LSP. In these scenarios it would be useful if 425 the ingress LSR gathered at least some information about the LSRs 426 which are along the path, up to the one that failed. The Partial 427 Query-Reply message provides this mechanism. It is recommended to use 428 the Partial Query-Reply messages when a Query message fails. If the 429 Reply message is full, TCP will take care of it by segmenting and 430 re-assembling the message. 432 Both reply messages are described in the following sections. 434 7.1. Query-Reply Message encoding 436 This message is generated by the end point of the LSP. It is 437 propagated upstream, by each LSR along the path. 439 The encoding for the Query-Reply message is: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |0| Query-Reply Type TBD IANA | Message Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Message ID | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Query TLV | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | MessageId TLV | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Optional Parameters | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Message ID 456 32-bit value used to identify this message. 458 Query TLV 459 What is to be queried. See Section 7 of this memo - Query TLV - 460 for encoding. 462 MessageId TLV 463 The value of this parameter is the message id of the corresponding 464 Query message. 466 Optional Parameters 467 This variable length field contains 0 or more parameters, each 468 encoded as a TLV. The optional parameters are: 470 Optional Parameter Length Value 472 ER TLV var See [1] 473 Query Label TLV var See Query Label TLV section 474 IPV4/6 specified link feedback TLV See [2] 475 Query Merge Flags TLV var See Query Merge Flags TLV 476 section 477 The TLV types are defined in CR-LDP [1] and LDP [4]. They are: 479 - IPV4/6 specified link feedback TLV 480 - ER TLV 481 - Generalized Label TLV (used in the Query Label TLV encoding) 482 - Hop Count TLV. 484 The IPV4/6 specified link feedback TLV is used when the Q1 flag from 485 the Query TLV is set. It is used to encode the bandwidth information. 486 For more information on query flags, Q1, Q2, Q3 and Q4, refer to 487 Query TLV section. 489 The ER TLV is a list of hops. It is used when the Query flag Q3 is 490 set. Every LSR should add its IP address. The address to be added 491 should be the outgoing interface address. Addresses are organized as 492 a last-in-fist-out stack (the first address in TLV is considered the 493 top). 495 The Query Label TLV is a list of labels. It is used when the Query 496 flag Q2 is set. It is populated with the labels used for the path 497 which is queried. For tunneled LSPs, the Query Label TLV represents a 498 list of labels associated to the lowest level tunnel. 500 If Q3 and Q2 flags are set, the labels should be encoded in the same 501 order as the hops. 503 Query Merge Flags TLV is a list of pairs of bits. It has variable 504 length and every two bits in the mask will correspond to an LSR along 505 the path. Its length is rounded up to the next byte. If Q4 is set, 506 every LSP along the path will have to set its corresponding bits in 507 the mask. The bits have to be set in the same order as the labels and 508 hops. Usually, Q4 is set when Q2 set and/or Q3 set. 510 For more information for the TLV encodings of the TLVs which are 511 used, please see [1], [4] and [2]. 513 7.2. Query-Reply Message Procedures 515 A Query-Reply message is initiated by an egress node which receives a 516 Query message, if the egress is able to identify the queried LSP. If 517 not, the egress replies with a Notification message with "No LSP to 518 query" status. 520 Upon receiving the Query message, the egress node has to reply with a 521 Query Reply message. The egress node has to encode into the Query- 522 Reply message a MessageId TLV. The mapping between a Query and a 523 Query-Reply Message is done based on the message id. Besides the 524 MessageId TLV, the egress has to encode the information that was 525 queried (bandwidth, path, etc). 527 After the encoding is done, the query reply message is sent back, on 528 the reversed path, towards the ingress. Every LSR across the LSP has 529 to encode its information according to what query flags are set. 531 7.3. Partial Query-Reply Message encoding 533 The Partial Query-Reply message is initiated by LSRs along the 534 queried path. The message is generated only if the following rules 535 apply: 536 - if the Query message asked for partial 537 replies (the Query message signals this request 538 through Q8 bit) 539 - if the LSR is configured to provide partial replies. 541 The encoding for the Partial Query-Reply message is identical to the 542 Query-Reply, except the message type. For more details on the 543 encoding please refer to the Query-Reply encoding. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |0|Partial Query-Reply TBD IANA | Message Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Message ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Query TLV | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | MessageId TLV | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Optional Parameters | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 7.4. Partial Query-Reply Message Procedures 561 The procedures are similar to the Query-Reply's procedures. Upon 562 receiving a Query message, an LSR will check the flag from the Query 563 message (Q8) which signals if the partial replies are requested by 564 the ingress node. If the flag is set, the LSR has to check next if it 565 is configured to fulfill this request. If the LSR supports partial 566 replies, it has to create a Partial Query-Reply and encode the 567 queried data and send it upstream like any Query-Reply messages. It 568 has then to process the Query message according to the Query message 569 procedures. When an LSR receives a Partial Query-Reply from upstream, 570 it should encode its information according to what is queried and 571 propagate the message. It is recommended to use the Partial Query 572 mechanism when the Query message fails (when the ingress LER does not 573 receive a Query-Reply message in response to a Query message). 575 8. Query TLVs 577 The Query TLV is used to specify the information being queried. The 578 Query TLV travels in the Query message to the egress node, where it 579 is copied into a reverse flowing Query-Reply messages and used by the 580 egress and intermediate LSRs to know what information is being 581 queried. 583 The format for the Query TLV is: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |0|0| Query TLV Type TBD IANA | Length | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Query Flags | Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Query Flags can be set according to what the Query is used for. A 594 query flag is set when it is 1. 596 +--+--+--+--+--+--+--+--+ 597 |Q8|Reserved|Q4|Q3|Q2|Q1| 598 +--+--+--+--+--+--+--+--+ 600 They can be: 602 - Q1 : query the bandwidth; if set, the LSR that 603 receives the Query message has to encode the bandwidth 604 that is available on the link (unused bandwidth); 605 - Q2 : query the labels which are associated to each hop in the 606 path; 607 - Q3 : query the LSRs which form the LSP which is queried; 608 if set, the LSR that received the Query-Reply message 609 has to encode the current hop in the ER-TLV 610 - Q4 : query which LSPs along the path are merging points; if set, 611 the LSR that receives the Query message has to encode 612 if it is a merging point; the encoding is done in the 613 Query Merge flags TLV. 614 - Q8 : if set, the ingress requests partial query-replies; each LSR 615 along the path is signaled to send a Partial Query Reply. 617 The reserved bits need to be set to zero on transmission and must be 618 ignored on receipt. They might be used in the future to signal other 619 types of queried information. The Query Flags can only be defined by 620 updating this memo. 622 8.1. Query Label TLV 624 The Query Label TLV is used to encode the labels used along the path 625 which is queried. 627 Note: Query Label TLV is used in both Query and Query Reply. It is a 628 required parameter in the Query message and it is an optional 629 parameter in Query Reply message. When being used in the Query 630 message, it carries the label or stack of labels which are being 631 followed and queried. When being used in the Query Reply message, it 632 carries the list of labels which make up the queried path. 634 The format for the Query Label TLV is: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |0|0| Query Label TLV TBD IANA | Length | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Generalized Label TLV 1 | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 ~ ~ 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Generalized Label TLV n | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Generalized Label TLV is used to encode labels along the path. Please 648 refer to [3] for more information on the Generalized Label TLV 649 encoding. If the Q2 flag is set, every LSR has to encode the out- 650 label corresponding to the queried LSP. In the Query Label TLV, 651 labels are organized as a last-in-fist-out stack (the first label in 652 TLV is considered the top). They should be encoded in the same order 653 as the hops and the merge flags. 655 8.2. Query Merge Flags TLV 657 The Query Merge Flags TLV is used to encode the information about 658 which LSRs along the path the queried LSP is being merged into. 660 The format for the Query Merge Flags TLV is: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |0|0| Merge Flags TLV TBD IANA | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Number of merge flags | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Merge flags ~ 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 ~ ~ 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 The Query Merge Flags TLV has 4 bytes field to store the number of 677 merge flags. This number is equal to the number of LSRs which are 678 traversed by the Query-Reply Message. The Merge flags field contains 679 the merge information. It is a variable length field which is rounded 680 up to the next byte. Each pair of bits in the Merge flags field 681 carries the merge information for one LSR. The valid values for the 682 merge bits for an LSR are: 684 01 - LSR does not do merge for the queried LSP 685 10 - LSR does merge for the queried LSP 686 00 - LSR cannot share the merge information. 688 Every LSR which is asked to encode the merging info has to update the 689 Number of merge flags and to set its corresponding bits accordingly. 691 8.3. Status code summary 693 Status Code E Status Data Section Title 695 No LSP to query 1 TBD IANA "Query Message Procedures..." 696 Ambiguous label value 1 TBD IANA "Query Message Procedures..." 698 9. Security Considerations 700 The Query mechanism inherits the same security mechanism described in 701 Section 4.0 of [4]. The Query mechanism provides an additional 702 security measure for cases when a node cannot share the queried 703 information. Such nodes have the option of hiding their information, 704 if their configuration requires it. Please refer to Section 4 of this 705 memo - "Behavior of LSRs with constraints in handling the query 706 messages" - for more details. 708 10. IANA Considerations 710 RFC 3036 [4] defines several name spaces including the Message Type 711 Name Space, the TLV Type Name Space, and the Status Code Name Space. 712 This document makes the following assignments within those spaces. 714 10.1. Message Type Space Extension 716 The message types for Query Message, Query-Reply Message and Partial 717 Query-Reply Message are as follows: 719 Message Type 720 -------------------------------------- ---------- 721 Query Message TBD IANA 722 Query Reply Message TBD IANA 723 Partial Query Reply Message TBD IANA 725 10.2. TLV Type Name Space Extension 727 The TLV types for Query TLV, Query Label TLV and Query Merge Flags 728 TLV are as follows: 730 TLV Type 731 -------------------------------------- ---------- 732 Query TLV TBD IANA 733 Query Label TLV TBD IANA 734 Query Merge Flags TLV TBD IANA 736 10.3. Status Code Space Extension 738 The Status codes "No LSP to query" and "Ambiguous label value" are as 739 follows: 741 Status Code Type 742 -------------------------------------- ---------- 743 No LSP to query TBD IANA 744 Ambiguous label value TBD IANA 746 11. Acknowledgments 748 The authors would like to acknowledge the careful review and comments 749 of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk, Gregory Wright and 750 Adrian Farrel. 752 12. Normative References 754 [1] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC 755 3212, January 2002 757 [2] Peter Ashwood-Smith et al., "Improving Topology Data Base 758 Accuracy with LSP Feedback", Work in Progress, draft-ietf-mpls-te-feed- 759 03.txt. 761 [3] Ashwood-Smith P., Berger L., "Generalized MPLS - Signaling 762 Functional Description", Work in Progress, draft-ietf-mpls-generalized- 763 signaling-07.txt. 765 [4] Andersson et al., "LDP Specification", RFC 3036, January 2001. 767 13. Author's Addresses 769 Peter Ashwood-Smith Antonela Paraschiv 770 Nortel Networks Corp. Nortel Networks Corp. 771 P.O. Box 3511 Station C, 600 Technology Park Drive 772 Ottawa, ON K1Y 4H7 Billerica, MA 01821 773 Canada USA 774 Phone: +1 613-763-4534 phone: +1 978-288-6136 775 petera@nortelnetworks.com antonela@nortelnetworks.com 777 Full Copyright Statement 779 Copyright (C) The Internet Society (2002). All Rights Reserved. This 780 document and translations of it may be copied and furnished to 781 others, and derivative works that comment on or otherwise explain it 782 or assist in its implementation may be prepared, copied, published 783 and distributed, in whole or in part, without restriction of any 784 kind, provided that the above copyright notice and this paragraph 785 are included on all such copies and derivative works. However, this 786 document itself may not be modified in any way, such as by removing 787 the copyright notice or references to the Internet Society or other 788 Internet organizations, except as needed for the purpose of 789 developing Internet standards in which case the procedures for 790 copyrights defined in the Internet Standards process must be 791 followed, or as required to translate it into languages other than 792 English. 794 The limited permissions granted above are perpetual and will not be 795 revoked by the Internet Society or its successors or assigns.