idnits 2.17.1 draft-paraschiv-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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 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 8 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 158: '... MUST appear in the order specified ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '...essages have ...' == Line 249 has weird spacing: '...dresses are o...' == Line 350 has weird spacing: '...dresses are o...' -- 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 (June 2000) is 8709 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 70, but not defined == Unused Reference: 'CR-LDP' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RSVP-RR' is defined on line 542, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-te-feed-01 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-07 == Outdated reference: A later version (-05) exists of draft-ietf-rsvp-refresh-reduct-04 Summary: 7 errors (**), 0 flaws (~~), 12 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: December 2000 Nortel Networks 5 June 2000 7 MPLS LDP Query Message Description 9 draft-paraschiv-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 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 32 Directory, see http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the encoding and procedures for two new LDP 37 messages, the Query Message and Query-Reply Message. An LER sends a 38 Query message when it needs to find out information about an LSP. The 39 Query message is sent for an established LSP. The Query message can 40 be used for LDP LSPs as well as for CR-LSPs. The queried data is 41 encoded into the Query-Reply message and partially into the Query 42 Message. 44 Contents 46 1 Introduction ............................................. 3 47 2 Overview ................................................. 3 48 2.1 LDP Overview ............................................. 3 49 2.2 CR-LDP Overview .......................................... 4 50 3 LDP Message Structure Overview ........................... 4 51 4 Query Message ............................................ 5 52 4.1 Query Message encoding ................................ 6 53 4.2 Query Message Procedures ................................. 7 54 4.3 Query-Reply Message encoding .......................... 8 55 4.4 Query-Reply Message Procedures ........................... 10 56 4.5 Query TLV ................................................ 10 57 4.6 Query Label TLV .......................................... 11 58 4.7 Query Merge Flags TLV .................................... 12 59 4.8 Label TLV ................................................ 12 60 5 Acknowledgments .......................................... 13 61 6 References ............................................... 13 62 7 Author's Addresses ....................................... 14 63 Changes from previous version: 65 o First revision. 67 1. Introduction 69 The original Multiprotocol Label Switching (MPLS) architecture 70 [MPLS-ARCH] was been defined to support the forwarding of data based 71 on a label. The MPLS architecture does not assume a single label 72 distribution protocol. A number of different label distribution 73 protocols are being standardized. This draft describes the query 74 mechanism for an LSP or CR-LSP. It specifies procedures and encodings 75 for the two new messages added for the query mechanism. Extensions 76 to the RSVP-TE to provide the same functionality are subject for 77 future study and will be covered in future draft versions. 79 The two new LDP messages are: Query Message and Query-Reply Message. 80 The following new TLVs are added to accommodate the encodings for the 81 new query messages: 82 - Query TLV 83 - Query Label TLV 84 - Query Merge Flags TLV 85 - Label TLV. 87 2. Overview 89 2.1. LDP Overview 91 Label Distribution Protocol (LDP) defined in [LDP Specification] 92 contains a set of procedures and messages by which Label Switched 93 Routers (LSR) establish Label Switch Paths (LSP) through a network by 94 mapping network layer routing information directly to data-link layer 95 switched paths. LDP associates a Forwarding Equivalence Class (FEC) 96 with each LSP it creates. The FEC associated with an LSP specifies 97 which packets are mapped to that LSP. 99 2.2. CR-LDP Overview 101 As described in [Constraint-Base LSP Setup using LDP], Constraint 102 Base Routing (CR-LDP) offers the opportunity to extend the 103 information used to setup paths beyond what is available for the 104 routing protocol. 106 3. LDP Message Structure Overview 108 As described in LDP Specification draft, all LDP messages have the 109 following format: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |U| Message Type | Message Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Message ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | | 119 + + 120 | Mandatory Parameters | 121 + + 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | 125 + + 126 | Optional Parameters | 127 + + 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 U bit 132 Unknown message bit. Upon receipt of an unknown message, if U is 133 clear (=0), a notification is returned to the message originator; 134 if U is set (=1), the unknown message is silently ignored. The 135 sections following that define messages specify a value for the U- 136 bit. 138 Message Type 139 Identifies the type of message 141 Message Length 142 Specifies the cumulative length in octets of the Message ID, 143 Mandatory Parameters, and Optional Parameters. 145 Message ID 146 32-bit value used to identify this message. Used by the sending 147 LSR to facilitate identifying notification messages that may apply 148 to this message. An LSR sending a notification message in 149 response to this message should include this Message Id in the 150 Status TLV carried by the notification message; see Section 151 "Notification Message". 153 Mandatory Parameters 154 Variable length set of required message parameters. Some messages 155 have no required parameters. 157 For messages that have required parameters, the required parameters 158 MUST appear in the order specified by the individual message 159 specifications in the sections that follow. 161 Optional Parameters 162 Variable length set of optional message parameters. Many messages 163 have no optional parameters. 165 For messages that have optional parameters, the optional parameters 166 may appear in any order. 168 4. Query Message 170 This sections describes the Query message and its encodings and 171 procedures. This message is meant to be used to gather information 172 about an LSP. It can be sent at any time for an established LSP. 173 The draft currently describes the procedures for the cases when the 174 Query Message is initiated by the ingress LER. Future versions of 175 the draft may add the procedures for the query message when issued 176 from a core LSR or from egress. 178 The Query Message can be used to gather information about: 179 - LSRs which form the LSP 180 - labels along the LSP 181 - information on what LSRs are merging points along the path 182 - unused bandwidth (as described in "Improving Topology Data Base Accuracy with LSP Feedback") 183 - congestion status 184 - round trip delay 185 - anything that is needed in the future and can be computed and 186 encoded in a TLV. 188 The queried information is going to be encoded in the Query-Reply 189 message which is sent back by the egress node, as a response to the 190 Query message. 192 4.1. Query Message encoding 194 The encoding for the Query message is: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |0| Query (0x0409) | Message Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Message ID | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Label TLV | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Query TLV | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Hop Count TLV | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Optional Parameters | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Message ID 213 32-bit value used to identify this message. 215 Label TLV 216 The label associated to the LSP which is queried. This TLV is a 217 list of Generalized Label TLVs [OPTICAL reference]. The 218 Generalized Label TLV provides a more generic encoding for 219 different types of labels. Most of the time the list has one 220 element; this is the case when the LSP is not tunneled. For 221 tunneled LSPs, the Label TLV has more that one element; it has to 222 behave like a label stack (it contains the previous label and the 223 tunnel's label). See Section Label TLV for more information on 224 Label TLV encoding. 226 Query TLV 227 What to query. See Section Query TLV for encoding. 229 Hop Count TLV 230 Specifies the number of LSR hops that can still be traversed 231 before the message is dropped due to loop detection. It is 232 initialized to the max value of 255 (or the configured value, if 233 any). Every LSR that receives the Query Message has to subtract 1 234 from the Hop Count value. The Query message should be dropped if 235 the hop count value becomes zero; a Notification signaling Loop 236 Detection should be send in reply to the sender of the message. 237 See [LDP Specification] for Hop Count TLV encoding. 239 Optional Parameters 240 This variable length field contains 0 or more parameters, each 241 encoded as a TLV. 243 Optional Parameter Length Value 245 ER TLV var See CR-LDP 247 The ER TLV is a list of hops. It is used when the Query flag Q3 is 248 set. Every LSR should add its IP address. The address to be added 249 should be the outgoing interface address. Addresses are organized as 250 a last-in-fist-out stack (the first address in TLV is considered the 251 top). By carrying this TLV in the Query Message and preserving this 252 order for the hops, we allow the possibility to interwork the Query 253 Message with the RSVP Path message. 255 4.2. Query Message Procedures 257 The LER ingress initiates the Query message. It populates the Query 258 TLV Parameters according to what kind of information it wants to 259 gather. The query for an LSP is done by its label. The only data that 260 the Query Message carries is the list of hops. This way, each node 261 along the path will have a complete route from source to destination. 262 This is useful for network management. 264 Upon receiving a Query Message, an LSR decodes the label to identify 265 which LSP is queried. If it cannot find the LSP which is using the 266 label, it sends back a Notification message. Otherwise, it checks 267 which is the out label which is bound to the queried in-label and 268 which is the downstream LSR peer. It replaces the in-label from Label 269 TLV with the out-label used by the LSP. It then passes the Query 270 message to the downstream peer. When the Query message gets to a 271 tunnel, it has to be able to handle both the previous label and the 272 tunnel's label. The Label TLV behaves like a label stack. The 273 previous label is pushed and the tunnel label is used. At the end of 274 the tunnel, we need to pop the stack and start substituting the lower 275 level labels. 277 Upon receiving the Query message, the egress node has to reply with a 278 Query Reply Message. This Query-Reply Message contains the Query TLV 279 which was received in the Query Message. The Query TLV tells the 280 egress LER which information is being queried and allows intermediate 281 LSRs to piggy back their own queried information on the Query reply 282 message. 284 4.3. Query-Reply Message encoding 286 The encoding for the Query-Reply message is: 288 0 1 2 3 289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |0| Query-Reply (0x0410) | Message Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Message ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Query TLV | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | MessageId TLV | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Hop Count TLV | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Optional Parameters | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Message ID 305 32-bit value used to identify this message. 307 Query TLV 308 What is to be queried. See Section Query TLV for encoding. 310 Message Id TLV 311 The value of this parameter is the message id of the corresponding 312 Query message. 314 Hop Count TLV 315 Specifies the number of LSR hops that can still be traversed 316 before the message is dropped due to loop detection. It is 317 initialized to the max value of 255 (or the configured value, if 318 any). Every LSR that receives the Query Message has to subtract 1 319 from the Hop Count value. The Query message should be dropped if 320 the hop count value becomes zero. See [LDP Specification] for Hop 321 Count TLV encoding. 323 Optional Parameters 324 This variable length field contains 0 or more parameters, each 325 encoded as a TLV. The optional parameters are: 327 Optional Parameter Length Value 329 ER TLV var See CR-LDP 330 Query Label TLV var See Query Label TLV section 331 IPV4 specified link feedback TLV See Improving Topology ... 332 Query Merge Flags TLV var See Query Merge Flags TLV 333 section 335 For simplicity we reuse here few TLV types defined for CR-LDP and 336 LDP. They are: 338 - IPV4 specified link feedback TLV 339 - ER TLV 340 - Generalized Label TLV (used in the Query Label TLV encoding) 341 - Hop Count TLV. 343 The IPV4 specified link feedback TLV is used when the Q1 flag from 344 the Query TLV is set. It is used by the egress LER to encode the 345 bandwidth. For more information on query flags, Q1, ... Q6, refer to 346 Query TLV section. 348 The ER TLV is a list of hops. It is used when the Query flag Q3 is 349 set. Every LSR should add its IP address. The address to be added 350 should be the outgoing interface address. Addresses are organized as 351 a last-in-fist-out stack (the first address in TLV is considered the 352 top). By carrying this TLV in the Query-Reply Message and preserving 353 this order for the hops, we allow the possibility to interwork the 354 Query-Reply Message with the RSVP Resv message. 356 The Query Label TLV is a list of labels. It is used when the Query 357 flag Q2 is set. It is populated with the labels used for the path 358 which is queried. For tunneled LSPs, the Query Label TLV represents a 359 list of labels associated to the lowest level tunnel. 361 If Q3 and Q2 flags are set, the labels should be encoded in the same 362 order as the hops. 364 Query Merge Flags TLV is a bit mask. It has variable length and every 365 bit in the mask will correspond to an LSR along the path. Its length 366 is rounded up to the next byte. If Q6 is set, every LSP along the 367 path will have to set its corresponding bit in the mask. The bits 368 have to be set in the same order as the labels and hops. Usually, Q6 369 is set when Q2 set and/or Q3 set. 371 For more information for the TLV encodings of the TLVs which are 372 reused, please see CR-LDP draft, LDP draft and IMPROVING TOPOLOGY 373 DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR_LDP draft. 375 4.4. Query-Reply Message Procedures 377 A Query-Reply message is initiated by an egress node which receives a 378 Query message, if the egress is able to identify the queried LSP. If 379 not (maybe the LSP was just torn down), the egress replies with a 380 Notification message. 382 Upon receiving the Query message, the egress node has to reply with a 383 Query Reply message. The egress node has to encode into the Query- 384 Reply message a MessageId Tlv. The mapping between a Query and a 385 Query-Reply Message is done based on the message id. Besides the 386 MessageId Tlv, the egress has to encode the information that was 387 queried (bandwidth, path, etc). 389 After the encoding is done, the query reply message is sent back, on 390 the reversed path, toward the ingress. Every LSR across the LSP has 391 to encode its information according to what query flags are set. 393 4.5. Query TLV 395 The Query TLV is used to specify the information being queried. The 396 Query TLV travels in the Query message to the egress node, where it 397 is copied into a reverse flowing Query Reply message and used by the 398 egress and intermediate LSRs to know what information is being 399 queried. 401 The format for the Query TLV is: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |0|0| Query TLV (0x0840) | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Query Flags | Reserved | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Query Flags can be set according to what the Query is used for. 413 +--+--+--+--+--+--+--+ 414 |Re|Q6|Q5|Q4|Q3|Q2|Q1| 415 +--+--+--+--+--+--+--+ 417 They can be: 419 - Q1 : query the bandwidth; if set, the LSR that 420 receives the Query message has to encode the bandwidth 421 that is available on the link (unused bandwidth); 422 - Q2 : query the labels which are associated to each hop in the 423 path; 424 - Q3 : query the LSRs which form the LSP which is queried; 425 if set, the LSR that received the Query-Reply message 426 has to encode the current hop in the ER-TLV 427 - Q4 : reserved for congestion status; < format - TBD > 428 - Q5 : query the round trip delay; if set, the edge egress 429 LSR should fill in the delay; < format - TBD > 430 - Q6 : query which LSPs along the path are merging points; if set, 431 the LSR that receives the Query message has to encode 432 if it is a merging point; the encoding is done in the 433 Query Merge flags TLV. 435 4.6. Query Label TLV 437 The Query Label TLV is used to encode the labels used along the path 438 which is queried. 440 The format for the Query Label TLV is: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |0|0| Query Label TLV (0x0841)| Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Generalized Label TLV 1 | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ~ ~ 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Generalized Label TLV n | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Generalized Label TLV is used to encode labels along the path. Please 455 refer to [OPTICAL reference] for more information on the Generalized 456 Label TLV encoding. If the Q2 flag is set, every LSR has to encode 457 the out-label corresponding to the queried LSP. In the Query Label 458 TLV, labels are organized as a last-in-fist-out stack (the first 459 label in TLV is considered the top). They should be encoded in the 460 same order as the hops and the merge flags. 462 Note: The Query Label TLV can use the Label TLV which is defined in 463 LDP draft. The same note applies to the Label TLV that encodes the 464 label which is queried. 466 4.7. Query Merge Flags TLV 468 The Query Merge Flags TLV is used to encode the information about 469 which LSRs along the path the queried LSP is being merged into. 471 The format for the Query Label TLV is: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |0|0| Merge Flags TLV (0x0842) | Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Number of merge flags | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Merge flags | | | ~ 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 ~ ~ 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 The Query Merge Flags TLV has 4 bytes field to store the number of 488 merge flags. This number is equal to the number of LSRs which are 489 traversed by the Query-Reply Message. Each bit in the Merge flags 490 field represents the merge info for an LSR. The bit is set to 0 if 491 the LSR does not do merge for the queried LSP and is set to 1 492 otherwise. The length is going to be rounded up to the next byte. 493 Every LSR which is asked to encode the merging info into this TLV has 494 to update the Number of merge flags and to set its corresponding bit 495 accordingly. If the Number of merge flags is already multiple of 8, 496 then a new byte needs to be added to this TLV. The length of the TLV 497 has to be updated as well. 499 4.8. Label TLV 501 The Label TLV is used to encode the label stack of the labels which 502 are queried (along the queried LSP). 504 The format for the Query Label TLV is: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |0|0| Label TLV (0x0843)| Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Generalized Label TLV 1 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 ~ ~ 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Generalized Label TLV n | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 The Label TLV is a stack of Generalized Labels. The top of the stack 519 is in the right octets of the TLV encoding. The Label TLV has to be 520 updated every time the Query message is processed by an LSR. The 521 encoding of the labels should follow the last-in-first-out stack 522 model. 524 Generalized Label TLV is used to encode labels. Please refer to 525 [OPTICAL reference] for more information on the Generalized Label TLV 526 encoding. 528 Note: The Label TLV can use the Label TLV which is defined in LDP 529 draft. 531 5. Acknowledgments 533 The authors would like to acknowledge the careful review and comments 534 of Jean-Pierre Coupal and Steve Hamilton. 536 6. References 538 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 539 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-07.txt, 540 May 2000. 542 [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini 543 S., "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp- 544 refresh-reduct-04.txt. 546 [CR-LDP] Peter Ashwood-Smith et al., "Improving Topology Data Base 547 Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt 549 Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional 550 Description" draft-ashwood-generalized-mpls-signaling-00.txt 552 7. Author's Addresses 554 Peter Ashwood-Smith Antonela Paraschiv 555 Nortel Networks Corp. Nortel Networks Corp. 556 P.O. Box 3511 Station C, 600 Technology Park Drive 557 Ottawa, ON K1Y 4H7 Billerica, MA 01821 558 Canada USA 559 Phone: +1 613-763-4534 phone: +1 978-288-6136 560 petera@nortelnetworks.com antonela@nortelnetworks.com 562 Full Copyright Statement 564 Copyright (C) The Internet Society (date). All Rights Reserved. This 565 document and translations of it may be copied and furnished to 566 others, and derivative works that comment on or otherwise explain it 567 or assist in its implementation may be prepared, copied, published 568 and distributed, in whole or in part, without restriction of any 569 kind, provided that the above copyright notice and this paragraph 570 are included on all such copies and derivative works. However, this 571 document itself may not be modified in any way, such as by removing 572 the copyright notice or references to the Internet Society or other 573 Internet organizations, except as needed for the purpose of 574 developing Internet standards in which case the procedures for 575 copyrights defined in the Internet Standards process must be 576 followed, or as required to translate it into languages other than 577 English. 579 The limited permissions granted above are perpetual and will not be 580 revoked by the Internet Society or its successors or assigns.