idnits 2.17.1 draft-ietf-mpls-lsp-query-00.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 13 instances of too long lines in the document, the longest one being 33 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 118 has weird spacing: '...essages have ...' == Line 343 has weird spacing: '...dresses are o...' == Line 463 has weird spacing: '...dresses are o...' == Line 513 has weird spacing: '...ical to the...' == Line 514 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 (October 2000) is 8587 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 75, but not defined == Unused Reference: 'CR-LDP' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RSVP-RR' is defined on line 696, 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-Smith 2 Internet Draft A. Paraschiv 3 Expiration Date: April 2001 Nortel Networks 5 October 2000 7 MPLS LDP Query Message Description 9 draft-ietf-mpls-lsp-query-00.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. The Query Message carries only the list of hops. 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 .......................... 10 58 6.2 Query-Reply Message Procedures ........................... 12 59 6.3 Partial Query-Reply Message encoding .................. 13 60 6.4 Partial Query-Reply Message Procedures ................... 13 61 7 Query TLVs ............................................... 14 62 7.1 Query Label TLV .......................................... 15 63 7.2 Query Merge Flags TLV .................................... 15 64 7.3 Label TLV ................................................ 16 65 8 Acknowledgments .......................................... 17 66 9 References ............................................... 17 67 10 Author's Addresses ....................................... 18 68 Changes from previous version: 70 o First revision. 72 1. Introduction 74 The original Multiprotocol Label Switching (MPLS) architecture 75 [MPLS-ARCH] was been defined to support the forwarding of data based 76 on a label. The MPLS architecture does not assume a single label 77 distribution protocol. A number of different label distribution 78 protocols are being standardized. This draft describes the query 79 mechanism for an LSP or CR-LSP. It specifies procedures and encodings 80 for the new messages added for the query mechanism. Extensions to 81 the RSVP-TE to provide the same functionality are subject for future 82 study and will be covered in future draft versions. 84 The new LDP messages are: Query Message, Query-Reply Message and 85 Partial Query-Reply Message. The following new TLVs are added to 86 accommodate the encodings for the new query messages: 87 - Query TLV 88 - Query Label TLV 89 - Query Merge Flags TLV 90 - Label TLV. 92 LDP uses the TCP transport for session, advertisement and 93 notification messages; i.e., for everything but the UDP-based 94 discovery mechanism. The messages which are added to support the 95 query mechanism are sent over TCP as well. 97 2. Overview 99 2.1. LDP Overview 101 Label Distribution Protocol (LDP) defined in [LDP Specification] 102 contains a set of procedures and messages by which Label Switched 103 Routers (LSR) establish Label Switch Paths (LSP) through a network by 104 mapping network layer routing information directly to data-link layer 105 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 106 with each LSP it creates. The FEC associated with an LSP specifies 107 which packets are mapped to that LSP. 109 2.2. CR-LDP Overview 111 As described in [Constraint-Base LSP Setup using LDP], Constraint 112 Base Routing (CR-LDP) offers the opportunity to extend the 113 information used to setup paths beyond what is available for the 114 routing protocol. 116 3. LDP Message Structure Overview 118 As described in LDP Specification draft, all LDP messages have the 119 following format: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 |U| Message Type | Message Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Message ID | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | | 129 + + 130 | Mandatory Parameters | 131 + + 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 + + 136 | Optional Parameters | 137 + + 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 U bit 142 Unknown message bit. Upon receipt of an unknown message, if U is 143 clear (=0), a notification is returned to the message originator; 144 if U is set (=1), the unknown message is silently ignored. The 145 sections following that define messages specify a value for the U- 146 bit. 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 reply with a Notification message. 201 The notification message is sent upstream and the status is "Unknown 202 Message Type". 204 4.2. LSR cannot share any information 206 In this case, the LSR is able to decode and process the query 207 messages. However, it is configured to hide all the data. It should 208 propagate the message after it encodes a zero-length TLV for its hop 209 in the hop list in the Query message. When Query-Reply message is 210 received from downstream, the LSR is requested to propagate the reply 211 message upstream after it encodes the zero-length tlvs for the 212 queried data. When the ingress receives back the reply, it can 213 identify which TLVs are empty; it can therefore ignore the zero- 214 length TLVs and process the rest of the data. 216 Note: zero-length TLV encoding can be used for all types of queried 217 information except the merge information. The LSR is requested to 218 signal the fact that the merging information is private by encoding a 219 special value in the corresponding merge bits (for more information 220 on the merge flags values please refer to Query Merge Flags TLV 221 section). 223 4.3. LSR cannot share some of the queried information 225 In this case, the LSR is able to decode and process the query 226 messages. It has to propagate the query messages. It has to encode 227 values for the data types that it is willing to return and zero- 228 length TLVs for values for the data that is hidden. 230 Note: zero-length TLV encoding can be used for all types of queried 231 information except the merge information. The LSR is requested to 232 signal the fact that the merging information is private by encoding a 233 special value in the corresponding merge bits (for more information 234 on the merge flags values please refer to Query Merge Flags TLV 235 section). 237 4.4. LSR can share the queried information 239 This is the normal case for an LSR. In this case, the LSR's behavior 240 has to follow the query and replies procedures described in the 241 following sections of the draft. 243 In order to have consistency among data encoded in the query and 244 reply messages, each LSR which can propagate the messages has to 245 encode its information in the query and in the reply messages. 247 The decision that an LSR can share the queried information has to be 248 controlled through configuration flags. This way each node along the 249 path can protect its data if they consider it private. 251 Note: It would be more efficient to control/restrict the private data 252 per MPLS cloud (inter MPLS domain) and not per LSR node (inter and 253 intra MPLS domain). When there are different MPLS clouds which have 254 nodes belonging to different vendors, the control of the private 255 information could be restricted to the boundary nodes. Within an MPLS 256 domain, there should be no restrictions on the queried information. 257 It would be useful to have some knowledge on which are the nodes on 258 the boundaries and have only those hiding the queried data. Because 259 there is no mechanism to identify which are the boundary nodes, this 260 is subject for future study. 262 5. Query Message 264 This sections describes the Query message and its encodings and 265 procedures. This message is meant to be used to gather information 266 about an LSP. It can be sent at any time for an established LSP. 267 The draft currently describes the procedures for the cases when the 268 Query Message is initiated by the ingress LER. Future versions of 269 the draft may add the procedures for the query message when issued 270 from a core LSR or from egress. 272 The Query Message can be used to gather information about: 273 - LSRs which form the LSP 274 - labels along the LSP 275 - information on what LSRs are merging points along the path 276 - unused bandwidth (as described in "Improving Topology Data Base Accuracy with LSP Feedback") 277 - congestion status 278 - round trip delay 279 - anything that is needed in the future and can be computed and 280 encoded in a TLV. 282 The queried information is going to be encoded in the Query-Reply 283 message which is sent back upstream, as a response to the Query 284 message. 286 5.1. Query Message encoding 288 The encoding for the Query message is: 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |0| Query (0x0409) | Message Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Message ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Label TLV | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Query TLV | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Hop Count TLV | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Optional Parameters | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Message ID 307 32-bit value used to identify this message. 309 Label TLV 310 The label associated to the LSP which is queried. This TLV is a 311 list of Generalized Label TLVs [OPTICAL reference]. The 312 Generalized Label TLV provides a more generic encoding for 313 different types of labels. Most of the time the list has one 314 element; this is the case when the LSP is not tunneled. For 315 tunneled LSPs, the Label TLV has more that one element; it has to 316 behave like a label stack (it contains the previous label and the 317 tunnel's label). See Section Label TLV for more information on 318 Label TLV encoding. 320 Query TLV 321 What to query. See Section Query TLV for encoding. 323 Hop Count TLV 324 Specifies the number of LSR hops that can still be traversed 325 before the message is dropped due to loop detection. It is 326 initialized to the max value of 255 (or the configured value, if 327 any). Every LSR that receives the Query Message has to subtract 1 328 from the Hop Count value. The Query message should be dropped if 329 the hop count value becomes zero; a Notification signaling Loop 330 Detection should be sent in reply to the sender of the message. 331 See [LDP Specification] for Hop Count TLV encoding. 333 Optional Parameters 334 This variable length field contains 0 or more parameters, each 335 encoded as a TLV. 337 Optional Parameter Length Value 339 ER TLV var See CR-LDP 341 The ER TLV is a list of hops. It is used when the Query flag Q3 is 342 set. Every LSR should add its IP address. The address to be added 343 should be the outgoing interface address. Addresses are organized as 344 a last-in-fist-out stack (the first address in TLV is considered the 345 top). By carrying this TLV in the Query Message and preserving this 346 order for the hops, we allow the possibility to interwork the Query 347 Message with the RSVP Path message. 349 5.2. Query Message Procedures 351 The LER ingress initiates the Query message. It populates the Query 352 TLV Parameters according to what kind of information it wants to 353 gather. The query for an LSP is done by its label. The only data that 354 the Query Message carries is the list of hops. This way, each node 355 along the path will have a complete route from source to destination. 356 The hop list information is useful for network management. 358 Upon receiving a Query Message, an LSR decodes the label to identify 359 which LSP is queried. If it cannot find the LSP which is using the 360 label, it sends back a Notification message. Otherwise, it checks 361 which is the out label which is bound to the queried in-label and 362 which is the downstream LSR peer. It replaces the in-label from Label 363 TLV with the out-label used by the LSP. It then passes the Query 364 message to the downstream peer. When the Query message gets to a 365 tunnel, it has to be able to handle both the previous label and the 366 tunnel's label. The Label TLV behaves like a label stack. The 367 previous label is pushed and the tunnel label is used. At the end of 368 the tunnel, we need to pop the stack and start substituting the lower 369 level labels. 371 Upon receiving the Query message, the egress node has to reply with a 372 Query Reply Message. The Query-Reply Message contains the Query TLV 373 which was received in the Query Message. The Query TLV tells the LSRs 374 along the path which information is being queried and allows 375 intermediate LSRs to piggy back their own queried information on the 376 Query reply message. 378 6. Reply Messages 380 These messages are propagated upstream. There are situations in 381 which the Query message does not reach the end point of the queried 382 LSP (e.g. when an LSR along the path is congested, or when it does 383 not support the Query messages). In these scenarios it would be 384 useful if the ingress LSR gathered at least some information about 385 the LSRs which are along the path, up to the one that failed. The 386 Partial Query-Reply message provides this mechanism. It is 387 recommended to use the Partial Query-Reply messages when a Query 388 message fails. There are two types of 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 | Hop Count TLV | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Optional Parameters | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Message ID 418 32-bit value used to identify this message. 420 Query TLV 421 What is to be queried. See Section Query TLV for encoding. 423 Message Id TLV 424 The value of this parameter is the message id of the corresponding 425 Query message. 427 Hop Count TLV 428 Specifies the number of LSR hops that can still be traversed 429 before the message is dropped due to loop detection. It is 430 initialized to the max value of 255 (or the configured value, if 431 any). Every LSR that receives the Query Message has to subtract 1 432 from the Hop Count value. The Query message should be dropped if 433 the hop count value becomes zero. See [LDP Specification] for Hop 434 Count TLV encoding. 436 Optional Parameters 437 This variable length field contains 0 or more parameters, each 438 encoded as a TLV. The optional parameters are: 440 Optional Parameter Length Value 442 ER TLV var See CR-LDP 443 Query Label TLV var See Query Label TLV section 444 IPV4 specified link feedback TLV See Improving Topology ... 445 Query Merge Flags TLV var See Query Merge Flags TLV 446 section 448 For simplicity we reuse here TLV types defined for CR-LDP and LDP. 449 They are: 451 - IPV4 specified link feedback TLV 452 - ER TLV 453 - Generalized Label TLV (used in the Query Label TLV encoding) 454 - Hop Count TLV. 456 The IPV4 specified link feedback TLV is used when the Q1 flag from 457 the Query TLV is set. It is used by the egress LER to encode the 458 bandwidth. For more information on query flags, Q1, ... Q6, refer to 459 Query TLV section. 461 The ER TLV is a list of hops. It is used when the Query flag Q3 is 462 set. Every LSR should add its IP address. The address to be added 463 should be the outgoing interface address. Addresses are organized as 464 a last-in-fist-out stack (the first address in TLV is considered the 465 top). 467 The Query Label TLV is a list of labels. It is used when the Query 468 flag Q2 is set. It is populated with the labels used for the path 469 which is queried. For tunneled LSPs, the Query Label TLV represents a 470 list of labels associated to the lowest level tunnel. 472 If Q3 and Q2 flags are set, the labels should be encoded in the same 473 order as the hops. 475 Query Merge Flags TLV is a bit mask. It has variable length and every 476 two bits in the mask will correspond to an LSR along the path. Its 477 length is rounded up to the next byte. If Q6 is set, every LSP along 478 the path will have to set its corresponding bits in the mask. The 479 bits have to be set in the same order as the labels and hops. 480 Usually, Q6 is set when Q2 set and/or Q3 set. 482 For more information for the TLV encodings of the TLVs which are 483 reused, please see CR-LDP draft, LDP draft and IMPROVING TOPOLOGY 484 DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR_LDP draft. 486 6.2. Query-Reply Message Procedures 488 A Query-Reply message is initiated by an egress node which receives a 489 Query message, if the egress is able to identify the queried LSP. If 490 not, the egress replies with a Notification message. 492 Upon receiving the Query message, the egress node has to reply with a 493 Query Reply message. The egress node has to encode into the Query- 494 Reply message a MessageId Tlv. The mapping between a Query and a 495 Query-Reply Message is done based on the message id. Besides the 496 MessageId Tlv, the egress has to encode the information that was 497 queried (bandwidth, path, etc). 499 After the encoding is done, the query reply message is sent back, on 500 the reversed path, toward the ingress. Every LSR across the LSP has 501 to encode its information according to what query flags are set. 503 6.3. Partial Query-Reply Message encoding 505 The Partial Query-Reply message is initiated by tandem LSRs along the 506 queried path. The message is generated only if the following rules 507 apply: 508 - if the Query message asked for partial 509 replies (the Query message signals this request 510 through Q8 bit) 511 - if the tandem LSR is configured to provide partial replies. 513 The encoding for the Partial Query-Reply message is identical to the 514 Query-Reply, except the message type. For more details on the 515 encoding please refer to the Query-Reply encoding. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |0| Query-Reply (0x0411) | Message Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Message ID | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Query TLV | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | MessageId TLV | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Hop Count TLV | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Optional Parameters | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 6.4. Partial Query-Reply Message Procedures 535 The procedures are similar to the Query-Reply's procedures. Upon 536 receiving a Query message, a tandem LSR will check the flag from the 537 Query message (Q8) which signals if the partial replies are requested 538 by the ingress node. If the flag is set, the LSR has to check next if 539 it is configured to fulfill this request. If the LSR supports partial 540 replies, it has to create a Partial Query-Reply and encode the 541 queried data and send it upstream like any Query-Reply messages. It 542 has then to process the Query message according to the Query message 543 procedures. When an LSR receives a Partial Query-Reply from upstream, 544 it should encode its information according to what is queried and 545 propagate the message. It is recommended to use the Partial Query 546 mechanism when the Query message fails (when the ingress LER does not 547 receive a Query-Reply message in response to a Query message). 549 7. Query TLVs 551 The Query TLV is used to specify the information being queried. The 552 Query TLV travels in the Query message to the egress node, where it 553 is copied into a reverse flowing Query-Reply messages and used by the 554 egress and intermediate LSRs to know what information is being 555 queried. 557 The format for the Query TLV is: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |0|0| Query TLV (0x0840) | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Query Flags | Reserved | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Query Flags can be set according to what the Query is used for. 569 +--+--+--+--+--+--+--+--+ 570 |Q8|Re|Q6|Q5|Q4|Q3|Q2|Q1| 571 +--+--+--+--+--+--+--+--+ 573 They can be: 574 - Q1 : query the bandwidth; if set, the LSR that 575 receives the Query message has to encode the bandwidth 576 that is available on the link (unused bandwidth); 577 - Q2 : query the labels which are associated to each hop in the 578 path; 579 - Q3 : query the LSRs which form the LSP which is queried; 580 if set, the LSR that received the Query-Reply message 581 has to encode the current hop in the ER-TLV 582 - Q4 : reserved for congestion status; < format - TBD > 583 - Q5 : query the round trip delay; if set, the LSR should fill in 584 the link delay information if available; < format - TBD > 585 - Q6 : query which LSPs along the path are merging points; if set, 586 the LSR that receives the Query message has to encode 587 if it is a merging point; the encoding is done in the 588 Query Merge flags TLV. 590 - Q8 : if set, the ingress requests partial query-replies; 591 7.1. Query Label TLV 593 The Query Label TLV is used to encode the labels used along the path 594 which is queried. 596 The format for the Query Label TLV is: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |0|0| Query Label TLV (0x0841)| Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Generalized Label TLV 1 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 ~ ~ 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Generalized Label TLV n | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Generalized Label TLV is used to encode labels along the path. Please 611 refer to [OPTICAL reference] for more information on the Generalized 612 Label TLV encoding. If the Q2 flag is set, every LSR has to encode 613 the out-label corresponding to the queried LSP. In the Query Label 614 TLV, labels are organized as a last-in-fist-out stack (the first 615 label in TLV is considered the top). They should be encoded in the 616 same order as the hops and the merge flags. 618 Note: The Query Label TLV could use the Label TLV which is defined in 619 LDP draft. The same note applies to the Label TLV that encodes the 620 label which is queried. 622 7.2. Query Merge Flags TLV 624 The Query Merge Flags TLV is used to encode the information about 625 which LSRs along the path the queried LSP is being merged into. 627 The format for the Query Label TLV is: 629 0 1 2 3 630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |0|0| Merge Flags TLV (0x0842) | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Number of merge flags | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Merge flags | | | ~ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 ~ ~ 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 The Query Merge Flags TLV has 4 bytes field to store the number of 644 merge flags. This number is equal to the number of LSRs which are 645 traversed by the Query-Reply Message. Each 2 bits in the Merge flags 646 field represents the merge info for an LSR. The bit is set to 1 if 647 the LSR does not do merge for the queried LSP and is set to 2 648 otherwise. If the LSR want to hide the merging information, it has to 649 set the merging flags to 0. The length is going to be rounded up to 650 the next byte. Every LSR which is asked to encode the merging info 651 into this TLV has to update the Number of merge flags and to set its 652 corresponding bits accordingly. 654 7.3. Label TLV 656 The Label TLV is used to encode the label stack of the labels which 657 are queried (along the queried LSP). 659 The format for the Query Label TLV is: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |0|0| Label TLV (0x0843)| Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Generalized Label TLV 1 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 ~ ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Generalized Label TLV n | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 The Label TLV is a stack of Generalized Labels. The top of the stack 673 is in the right octets of the TLV encoding. The Label TLV has to be 674 updated every time the Query message is processed by an LSR. The 675 encoding of the labels should follow the last-in-first-out stack 676 model. 678 Generalized Label TLV is used to encode labels. Please refer to 679 [OPTICAL reference] for more information on the Generalized Label TLV 680 encoding. 682 Note: The Label TLV could use the Label TLV which is defined in LDP 683 draft. 685 8. Acknowledgments 687 The authors would like to acknowledge the careful review and comments 688 of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk and Gregory Wright. 690 9. References 692 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 693 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-07.txt, 694 May 2000. 696 [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini 697 S., "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp- 698 refresh-reduct-04.txt. 700 [CR-LDP] Peter Ashwood-Smith et al., "Improving Topology Data Base 701 Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt 703 Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional 704 Description" draft-ashwood-generalized-mpls-signaling-00.txt 705 10. Author's Addresses 707 Peter Ashwood-Smith Antonela Paraschiv 708 Nortel Networks Corp. Nortel Networks Corp. 709 P.O. Box 3511 Station C, 600 Technology Park Drive 710 Ottawa, ON K1Y 4H7 Billerica, MA 01821 711 Canada USA 712 Phone: +1 613-763-4534 phone: +1 978-288-6136 713 petera@nortelnetworks.com antonela@nortelnetworks.com 715 Full Copyright Statement 717 Copyright (C) The Internet Society (date). All Rights Reserved. This 718 document and translations of it may be copied and furnished to 719 others, and derivative works that comment on or otherwise explain it 720 or assist in its implementation may be prepared, copied, published 721 and distributed, in whole or in part, without restriction of any 722 kind, provided that the above copyright notice and this paragraph 723 are included on all such copies and derivative works. However, this 724 document itself may not be modified in any way, such as by removing 725 the copyright notice or references to the Internet Society or other 726 Internet organizations, except as needed for the purpose of 727 developing Internet standards in which case the procedures for 728 copyrights defined in the Internet Standards process must be 729 followed, or as required to translate it into languages other than 730 English. 732 The limited permissions granted above are perpetual and will not be 733 revoked by the Internet Society or its successors or assigns.