idnits 2.17.1 draft-ietf-mpls-te-feed-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 4: '...Expiration Date: MAY 2003 ...' RFC 2119 keyword, line 461: '... Implementations MUST NOT permit bandw...' RFC 2119 keyword, line 483: '... SHOULD therefore consider the most ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Nov 2002) is 7826 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) == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'IS-IS') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-08 -- No information found for draft-anto-ldp-query - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Peter Ashwood-Smith 3 Internet Draft Bilel Jamoussi 4 Expiration Date: MAY 2003 Don Fedyk 5 Standards Track Darek Skalecki 6 Nortel Networks 8 Nov 2002 10 Improving Topology Data Base Accuracy with Label Switched Path 11 Feedback in Constraint Based Label Distribution Protocol 13 draft-ietf-mpls-te-feed-05.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 One key component of traffic engineering is a concept known as 39 constraint based routing. In constraint based routing a topology 40 database is maintained on all participating nodes. This database 41 contains a complete list of all the links in the network that 42 participate in traffic engineering and for each of these links a set 43 of constraints, which those links can meet. Bandwidth, for example, 44 is one essential constraint. Since the bandwidth available changes 45 as new LSPs are established and terminated the topology database 46 will develop inconsistencies with respect to the real network. It is 47 not possible to increase the flooding rates arbitrarily to keep the 48 database discrepancies from growing. A new mechanism is proposed 49 whereby a source node can learn about the successes or failures of 50 its path selections by receiving feedback from the paths it is 51 attempting. This information is most valuable in failure scenario's 52 but is beneficial during other path setup functions as well. This 53 fed back information can be incorporated into subsequent route 54 computations, which greatly improves the accuracy of the overall 55 routing solution by significantly reducing the database 56 discrepancies. 58 Table of Contents 60 1.0 Introduction and Description . . . . . . . . . . . . . . . 2 61 2.0 Adding feedback TLVs to CR-LDP . . . . . . . . . . . . . . 6 62 2.1 Bandwidth directionality considerations. . . . . . . . 6 63 3.0 Link Feedback TLV. . . . . . . . . . . . . . . . . . . . . 7 64 3.1 Link feedback TLV Description . . . . . . . . . . . . . 7 65 3.2 Local Interface IP Address Subtypes . . . . . . . . . . 8 66 3.3 Remote Interface IP Address Subtypes . . . . . . . . .. 8 67 3.4 Unreserved Bandwidth Sub Type. . . . . . . . . . . . . 8 68 4.0 Detailed Procedures. . . . . . . . . . . . . . . . . . . . 9 69 5.0 IGP Considerations . . . . . . . . . . . . . . . . . . . .10 70 6.0 Future Considerations . . . . . . . . . . . . . . . . . .10 71 7.0 RSVP-TE Considerations . . . . . . . . . . . . . . . . . .11 72 8.0 Intellectual Property Considerations . . . . . . . . . . .11 73 9.0 Security Considerations. . . . . . . . . . . . . . . . . .11 74 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . .11 75 11.0 Acknowledgements . . . . . . . . . . .. . . . . . . . . .11 76 12.0 Normative References. . . . . . . . . . . . . . . . . . .11 77 13.0 Informative References. . . . . . . . . . . . . . . . . .12 78 14.0 Authors Addresses . . . . . . . . . . . . . . . . . . . .12 80 1.0 Introduction and Description 82 Because the network is a distributed system, it is necessary to have 83 a mechanism to advertise information about links to all nodes in the 84 network [IS-IS], [OSPF]. A node can then build a topology map of 85 the network. This information is required to be as up-to-date as 86 possible for accurate traffic engineered paths. Information about 87 link or node failures must be rapidly propagated through the network 88 so that recovery can be initiated. Other information about links 89 that may be useful for reasons of quality of service includes 90 parameters such as available bandwidth, and delay. The information 91 in this topology database is often out of date with respect to the 92 real network. Available bandwidth is the most critical of these 93 attributes and it can drift substantially with respect to reality 94 due to the low frequency of link state updates that can be sustained 95 in a very large topology. The deviation in the topology database 96 available bandwidth is referred to as being optimistic if the 97 database shows more available bandwidth than there really is, or 98 pessimistic if the topology database shows less bandwidth than there 99 really is. This distinction is important to enable an efficient 100 algorithm to deal with optimistic databases without resorting to 101 shorter flooding intervals. 103 One of the major problems for a constraint based routing system is 104 dealing with changing constraints. Obviously, since bandwidth is one 105 of the essential constraints, dealing with the rapid changes in 106 reserved bandwidth poses some interesting challenges. In smaller 107 networks, one can resort to higher frequency flooding but this 108 obviously does not scale. The feedback mechanism is particularly 109 useful in the case of link or node failures where the rapid change 110 and notification of resource change is crucial to the restoration 111 time. Feedback is work conserving in this case since the 112 availability of feedback information minimizes the extra burden of 113 dealing with out of date topology and resource information. 115 The basic approach is to add to the signaling protocol the ability 116 to piggyback actual link bandwidth availability information at every 117 link that the signaling traverses. This is done as part of the 118 reverse messaging on success or failure (mapping, release, withdraw 119 or notification). What this means is that every time signaling 120 messages flow backwards toward a source to tell it of the success, 121 failure or termination of a request, that message contains a 122 detailed slice of bandwidth availability information for the exact 123 path that the message has followed. This slice of reservation 124 information, which is very up to date, is received by the source 125 node and attached to the source node's topology database prior to 126 making any further source route computations. The result is that the 127 source node's topology database will tend to stay synchronized with 128 the slices of the network through which it is establishing paths. 129 This is nothing more than learning from successes and failures and 130 represents an intelligent alternative to either waiting for floods 131 or introducing non-determinism (guessing) into the source 132 algorithms. It is important to note that the fed-back data is never 133 re-flooded. It simply overrides flooded information for the purpose 134 of route computation until a superceding flood or fed-back value 135 arrives. As such, it is not actually inserted into a topology 136 database, most likely it simply is linked to that database as an 137 override used only by source route computations. Also the inclusion 138 of feedback information is optional. At a minimum the blocked or 139 failed link is required but if processing resources are scarce the 140 additional feedback at other hops is optional. 142 Operating a constraint based routing system without such feedback is 143 inefficient at best since a source node will continue to give out 144 incorrect route over and over again until it gets an IGP update. 145 This could be minutes away and as a result the worst case blocking 146 time for a new route is the minimum repeatable flooding interval 147 (often several minutes in big networks). Alternatives to feedback 148 mechanisms involve adding some non-determinism (randomness) to the 149 routing algorithm in the hopes that it will stumble onto a path that 150 works. These sorts of approaches are seen in ATM dynamic routing 151 systems, which do not have these forms of feedback. 153 In order to get a good understanding of how the feedback works, 154 imagine a network with precisely one path (with sufficient 155 unreserved bandwidth) available from the source to the destination. 156 Further, imagine that the topology database at the source is 157 significantly out of date with respect to the real network in that 158 the source topology database sees sufficient bandwidth available on 159 many different routes to the destination. This is termed being 160 optimistic with respect to the network since the source thinks that 161 more bandwidth is available than there really is. 163 When such an optimistic source selects its first path it will likely 164 contain links that do not in reality have sufficient unreserved 165 bandwidth. Therefore, the path is only established up to the link 166 that does not have sufficient bandwidth. A notification message is 167 formatted that contains the actual unreserved bandwidth for this 168 blocking link which flows back toward the source, collapsing the 169 partially created path as it goes. In addition, at every link that 170 this notification traverses, the current unreserved bandwidth 171 information for each corresponding link is appended to the vector of 172 unreserved bandwidth along the path. In this manner, an accurate 173 view of the slice through the network traversed is constructed. 174 Eventually this message arrives back at the source node, where the 175 vector is taken and used to temporarily override the topology 176 database for route computations. This node has just learned from its 177 mistake and is now slightly less optimistic with respect to the real 178 network conditions. 180 Path selection can be attempted again but this time the node will 181 not make the same mistake it made the previous time. The link in 182 question, at which rejection occurred the first time, will not even 183 be eligible this time around, so a source route computation is 184 guaranteed to produce a different path (or none). The same procedure 185 may be repeated as many times as is necessary, each time learning 186 from its mistakes, until eventually no paths remain in the source 187 topology to the destination, or a path is found that works. This 188 tendency to converge either to a solution or determine that there is 189 no solution is an important property of a routing system (it 190 actually behaves a lot like a depth first search). This property is 191 not present with flooding mechanisms alone since the source node 192 must randomly hunt, or continually make the same mistakes, or abort 193 until the next flood arrives. 195 In addition to feeding back bandwidth on failure, feedback on 196 success is recommended. This has important consequences on our 197 ability to spread load or to spill over to new links as existing 198 links fill. It is true that spilling over to new links does not 199 require feedback on success since a node could simply wait for a 200 feedback on failure, but better load spreading can be achieved 201 earlier. 203 Finally, when a path is torn down the release/withdraw messages also 204 contain bandwidth information that can be fed back to override the 205 source topology database. This is very important during failure 206 scenarios where the links required for rerouting the path share 207 common sub-segments with the failed path. Without the feedback, the 208 common sub-segments may not indicate sufficient available bandwidth 209 until an LSA flood is received which may mean many seconds without a 210 connection. With feedback at least the database is up to date with 211 respect to available bandwidth up to the point of failure in the 212 path. Also since failure involves many paths tearing down and re- 213 establishing this is the time that it is most critical to have an 214 accurate view. 216 When preemption is being employed it is also extremely important 217 that the topology database inconsistencies be small. If not, high 218 setup priority LSPs may unnecessarily preempt lower holding priority 219 LSPs to obtain bandwidth that, had they had a more up to date view 220 of unreserved bandwidth, they would have been able to find 221 elsewhere. Since preempted LSPs may in turn preempt other LSPs in a 222 domino like effect, the results of such database inconsistencies can 223 have wide reaching ripple like impacts. These feedback mechanisms 224 help reduce these occurrences significantly. 226 There are a number of network conditions where feedback shows its 227 value. One can think of a constraint-based network as being in one 228 of three conditions. The first is called ramp-up, this is when the 229 rate of arriving reservations exceeds the rate of departing 230 reservations. The second is called steady state, this is when the 231 rate of arriving reservations is about the same as the rate of 232 departing reservations. Finally, the ramp-down condition is that 233 which has a greater rate of departing reservations than arriving 234 reservations. 236 These three network conditions show distinctly different types of 237 error in the topology databases. In particular an optimistic view of 238 available bandwidth by a source node is characteristic of the ramp- 239 up condition of a network. A pessimistic view of available bandwidth 240 by a source node is characteristic of the ramp-down condition of a 241 network. If one plots the average error in the topology databases 242 with respect to the real network for the three different network 243 conditions, one will see the error slowly go positive during ramp 244 up, slowly go negative during ramp down, and drift slowly around 0 245 for the steady condition. The effect of flooding on this plot is to 246 periodically snap the error back to 0 at flooding intervals. The 247 effect of the feedback algorithm is to bring an optimistic error 248 back to zero without having to wait for the flood interval. On 249 average then, the feedback algorithm tends to halve the absolute 250 error, keeping it mostly negative or pessimistic. This makes sense 251 since a routing system will never give paths to links that it thinks 252 do not have resources and as a result its pessimistic view of the 253 world stays that way until it gets a flood. This relieves the IGP 254 updates of the most urgent requirement of flooding when bandwidth is 255 consumed. Availability of new bandwidth occurs when paths are 256 released or new links become available. Floods already accompany 257 new links. Significant releases of bandwidth can be broadcast at 258 relatively low frequencies in the order of several minutes with 259 little operational impact. 261 2.0 Adding feedback TLVs to CR-LDP 263 Two new TLVs are optionally added to the CR-LDP mapping, 264 notification, and withdraw messages. There may be an arbitrary 265 number of these TLV in any order or position in the message. It is 266 recommended that they be placed such that they can be read and 267 applied to override the topology database by scanning the message 268 forwards and walking the topology database from the point where the 269 last link feedback TLV left off. 271 Each TLV consists of the eight unreserved bandwidth values for each 272 holding priority 0 through 7 as IEEE floating-point numbers (the 273 units are unidirectional bytes per second). Following this are the 274 IP addresses of the two ends of the interface. Two TLVs are 275 possible, one for IPV4 and one for IPV6 addressing of the link. 277 Note: the feedback TLVs may also optionally be included in query or 278 query-reply messages in response to bandwidth update queries from an 279 LER. Details of this mechanism are provided in [QUERY]. 281 2.1 Bandwidth directionality considerations 283 The order of the two addresses in the feedback TLV implies the 284 direction in which the bandwidth is available. For example if the 285 first address is A and the second address is B the bandwidth is 286 unreserved in the A to B direction. 288 It is possible for an implementation to provide both the A to B 289 direction and the B to A direction as part of the same feedback 290 message. This is done by simply including a TLV with A, B as the 291 addresses of the link and a different TLV with B, A as the addresses 292 of the link. Should CR-LDP evolve to be able to support bi- 293 directional traffic flow and reservations, it is expected that bi- 294 directional feedback would also be implemented via this mechanism. 296 3.0 Link Feedback TLV 298 The Feedback payload consists of one or more nested 299 Type/Length/Value (TLV) triplets for extensibility. The format of 300 each TLV is: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Value... | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 The Length field defines the length of the value portion in octets 311 (thus a TLV with no value portion would have a length of zero). The 312 TLV is padded to four-octet alignment; padding is not included in 313 the length field (so a three octet value would have a length of 314 three, but the total size of the TLV would be eight octets). Nested 315 TLVs are also 32-bit aligned. Unrecognized types are ignored. 317 3.1 Link feedback TLV Description 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |U|F| TBD IANA | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Sub TLVs | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 This document introduces essentially one Feedback TLV. There may be 328 multiple instances of the Feedback TLV in a CR-LDP message, one for 329 each different links along the path. Due to the current format that 330 TE extension documents organize TE information the feedback TLV has 331 sub TLVs. This allows the information to conform to the current TE 332 conventions and allows options for additional future feedback 333 elements. The formats are derived from the TE extensions TLVs for 334 IS-IS [IS-IS] and OSPF [OSPF]. 336 U bit 337 Unknown TLV bit must be set to 1. As with all CR-LDP messages, upon 338 receipt of an unknown TLV, if U is if U is set (=1), the unknown TLV 339 is silently ignored and the rest of the message is processed as if 340 the unknown TLV did not exist. 342 F bit 343 Forward unknown TLV bit must be set to 1. This bit applies only 344 when the U bit is set and the CR-LDP message containing the unknown 345 TLV is to be forwarded. If F is set (=1), the unknown TLV is 346 forwarded with the containing message. 348 The following sub tlvs for the Feedback TLV are defined: 350 1 - Local interface IP address (IPv4) 351 2 - Remote interface IP address (IPv4) 352 3 - Local interface IP address (IPv6) 353 4 - Remote interface IP address (IPv6) 354 5 - Unreserved bandwidth 356 This document defines the sub types. The code points are to be 357 assigned by IANA. 359 3.2 Local Interface IP Address Sub Types 361 The Local Interface IP Address sub-TLV specifies the IP address(es) 362 of the interface corresponding to this link. Normally there will 363 only be one address. If there are multiple 364 local addresses on the link, they are all listed in this sub-TLV. 366 The Local Interface IPv4 Address sub-TLV is TLV type 1, and is 4N 367 octets in length, where N is the number of local addresses. 369 The Local Interface IPv6 Address sub-TLV is TLV type 3, and is 16N 370 octets in length, where N is the number of local addresses. 372 3.3 Remote Interface IP Address Sub Types 374 The Remote Interface IP Address sub-TLV specifies the IP address(es) 375 of the neighbor's interface corresponding to this link. This and 376 the local address are used to discern multiple parallel links 377 between systems. 379 The Remote Interface IPv4 Address sub-TLV is TLV type 2, and is 4N 380 octets in length, where N is the number of neighbor addresses. 382 The Remote Interface IPv6 Address sub-TLV is TLV type 4, and is 16N 383 octets in length, where N is the number of neighbor addresses. 385 3.4 Unreserved Bandwidth Sub Type 387 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 388 not yet reserved at each of the eight priority levels, in IEEE 389 floating point format. The values correspond to the bandwidth that 390 can be reserved with a setup priority of 0 through 7, arranged in 391 increasing order with priority 0 occurring at the start of the sub- 392 TLV, and priority 7 at the end of the sub-TLV. The units are bytes 393 per second. 395 The Unreserved Bandwidth sub-TLV is TLV type 5, and is 32 octets in 396 length. 398 4.0 Detailed Procedures 400 On receipt of a withdraw, notification, query-reply, or mapping 401 message pertaining to a request made by CR-LDP (as opposed to LDP), 402 a feedback TLV of the appropriate format for the interface over 403 which the message was received is inserted into the message before 404 forwarding it back to the source of the request. The interface's 405 local and remote interface address in the appropriate format are 406 placed in the TLV. 407 The eight bandwidth values are filled in with the outgoing bandwidth 408 available on this interface for each of the eight holding priorities 409 in bytes per second. 411 On receipt of a CR-LDP request message, which cannot be satisfied, a 412 notification message is formatted normally. The Feedback TLV with 413 the local and remote interface address in the appropriate format and 414 the eight bandwidth values are filled in with the outgoing bandwidth 415 available on this interface for each of the eight holding priorities 416 in bytes per second. 418 On receipt of a CR-LDP request message which has been satisfied and 419 which results in a mapping being generated. No feedback TLV is added 420 since the previous node will insert the proper TLV when it receives 421 the reverse flowing mapping. 423 When an LDP session goes down either because of a link failure, 424 TCP/IP timeout, keep alive timeout, adjacency timeout etc. Other LDP 425 sessions in the module must generate either notification, withdraw 426 or release messages for LSPs that traversed the LDP in question. In 427 the case that the LSP was created by CR-LDP and that a withdraw or 428 notification is about to be generated, LDP will insert a feedback 429 TLV for the interface which just went down that contains 0's for all 430 the bandwidth values and attach to it the proper interface 431 addresses. Where LDP FT procedures [LDP-FT] are in use, LSPs that 432 are protected by FT procedures should not be torn down until after 433 session reestablishment has failed. During LDP re-establishment 434 time new connections may be queued and delayed for the re- 435 establishment time. If signaling delay is undesirable feedback may 436 be used to report zero bandwidth. In this case, if LDP is 437 successfully re-established a Link LSA should be triggered if 438 sufficient amount bandwidth is available. 440 When the LDP session that originated a CR-LDP label request receives 441 a mapping that contains feedback TLV's it is recommended that these 442 bandwidth values supersede the corresponding values in the node's 443 topology database for source route computations. Doing so permits 444 this node to immediately synchronize its topology with respect to 445 the real bandwidth reservations along the path that was just 446 established. 448 When the LDP session that originated a CR-LDP label request receives 449 a notification that contains feedback TLV's it is recommended that 450 these bandwidth values supersede the corresponding values in the 451 node's topology database for source route computations. Doing so 452 permits this node to immediately synchronize its topology with 453 respect to the real bandwidth reservations along the path that just 454 failed to establish. The source node may then re-compute a path 455 knowing that the computation will take into account the failure if 456 it was caused by the topology database being in error with respect 457 to the real network state. 459 5.0 IGP considerations 461 Implementations MUST NOT permit bandwidth information learned by 462 this feedback mechanism to be re-flooded via IS-IS, OSPF or any 463 other IGP. The bandwidth information learned via these feedback 464 mechanisms is to be used ONLY for source route computations on the 465 nodes that are directly on the path that fed back the bandwidth. 466 Normally only the source node of the LSP, or perhaps intermediate 467 gateway nodes will use this information. It is however permitted for 468 intermediate nodes that are forwarding this feedback information to 469 store it for their own local source route computations. 470 There is a possibility of a race condition between the bandwidth 471 information that is received via feedback and that, which is 472 received via a normal IGP flood. While there may be a discrepancy 473 between the two, both are within a few 100 milliseconds of being 474 correct. Solutions to allow us to determine which information is 475 most up to date (say by adding a sequence number) do not add any 476 significant benefit. Constraint based, source routed systems will 477 always have errors in the local topology database with respect to 478 the real network. These errors can be reduced through reduced 479 flooding intervals, path following feedback and selective flooding 480 but realistically the errors cannot be reduced below the second or 481 so range. As a result propagation delay order race conditions are 482 noise with respect to the average expected errors. An implementation 483 SHOULD therefore consider the most recently received update (IGP or 484 feedback) as being the most up to date. 486 6.0 Future considerations 488 Constraint based routing systems such as CR-LDP will in the future 489 offer other forms of constraint than simply reserved bandwidth. 490 Actual utilization levels, current congestion levels, number of 491 discrete channels/wavelengths available etc. are all possible 492 constraints that change rapidly and which must be taken into 493 consideration when computing a route. It is expected that this 494 mechanism will be used to feedback these and other new forms of link 495 constraining data. 497 7.0 RSVP-TE consideration 499 Nothing precludes the use of such feedback mechanisms with a similar 500 TLV structure in the RSVP-TE Resv and other reverse flowing messages 501 although repeatedly applying unchanged feedback should be avoided. 502 This could be accomplished by a simple rule that only permits 503 feedback information on the original RESV, not on subsequent 504 refreshes. This document only covers the CR-LDP protocol. 506 8.0 Intellectual Property Consideration 508 The IETF has been notified of intellectual property rights claimed 509 in regard to some or all of the specification contained in this 510 document. For more information consult the online list of claimed 511 rights. 513 9.0 Security Considerations 515 This document covers an additional data structure, a TLV to an 516 existing LDP message. Therefore the security aspects of this are the 517 same as a LDP. CR-LDP inherits the same security mechanism described 518 in Section 4.0 of [LDP] to protect against the introduction of 519 spoofed TCP segments into LDP session connection streams. 521 10.0 IANA Considerations 523 The Feedback TLV as well as Types for sub-TLVs in a Feedback TLV are 524 to be registered with IANA. 526 [RFC3212] defines the CR-LDP TLV name space. This memo requires 527 assignment of one TLV Type from that range. 529 Also, sub-Types of a Feedback TLV need to be assigned by IANA. The 530 types from 6 to 32767 are by expert review controlled by IANA. The 531 types 32768 to 65535 are reserved for private use. 533 11.0 Acknowledgments 535 The authors would like to thank Keith Dysart for his guidance and 536 Jerzy Miernik for helping implement these concepts and bringing them 537 to life. The authors' would like to acknowledge Dave Allan for his 538 comments and suggestions. 540 12.0 Normative References 542 [RFC3212] Jamoussi, B. et al., "Constraint-Based LSP Setup using 543 LDP", RFC 3212, January 2002. 545 [LDP] Andersson, L. et al., "LDP Specification", RFC 3032, January 546 2001. 548 [IS-IS] Li, T., Smit, H., "Extensions to IS-IS for traffic 549 engineering", Internet Draft, draft-ietf-isis-traffic-04.txt, August 550 2001. 552 [OSPF] Katz,D., Yeung, D., Kompella, K., " Traffic Engineering 553 Extensions to OSPF Version 2," draft-katz-yeung-ospf-traffic-08.txt, 554 September 2002. 556 13.0 Informative References 558 [QUERY] Ashwood-Smith, P., Paraschiv, A., " Multi Protocol Label 559 Switching Label Distribution Protocol Query Message Description 560 ", Internet Draft, draft-anto-ldp-query-04.txt, May 2002. 562 [LDP-FT] Farrel, A et al., " Fault Tolerance for the Label 563 Distribution Protocol (LDP)", Internet Draft, draft-ietf-mpls-ldp- 564 ft-06.txt, September 2002 566 14.0 Author's Addresses 568 Peter Ashwood-Smith Bilel Jamoussi 569 Nortel Networks Corp. Nortel Networks Corp. 570 P.O. Box 3511 Station C, 600 Technology Park Drive 571 Ottawa, ON K1Y 4H7 Billerica, MA 01821 572 Canada USA 573 Phone: +1 613-763-4534 phone: +1 978-288-4506 574 petera@nortelnetworks.com jamoussi@nortelnetworks.com 576 Darek Skalecki Don Fedyk 577 Nortel Networks Corp. Nortel Networks Corp. 578 P.O. Box 3511 Station C, 600 Technology Park Drive 579 Ottawa, On K1Y 4H7 Billerica, MA 01821 580 Canada USA 581 Phone: +1 613-765-2252 Phone: +1 978-228-3041 582 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com 584 Full Copyright Statement 586 Copyright (C) The Internet Society 2002. All Rights Reserved. This 587 document and translations of it may be copied and furnished to 588 others, and derivative works that comment on or otherwise explain it 589 or assist in its implementation may be prepared, copied, published 590 and distributed, in whole or in part, without restriction of any 591 kind, provided that the above copyright notice and this paragraph 592 are included on all such copies and derivative works. However, this 593 document itself may not be modified in any way, such as by removing 594 the copyright notice or references to the Internet Society or other 595 Internet organizations, except as needed for the purpose of 596 developing Internet standards in which case the procedures for 597 copyrights defined in the Internet Standards process must be 598 followed, or as required to translate it into languages other than 599 English. 601 The limited permissions granted above are perpetual and will not be 602 revoked by the Internet Society or its successors or assigns.