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