idnits 2.17.1 draft-ietf-mpls-te-feed-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 2 instances of too long lines in the document, the longest one being 2 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 392: '... Implementations MUST NOT permit bandw...' RFC 2119 keyword, line 414: '...ected errors. An implementation SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8830 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: 'OSPF' is mentioned on line 58, but not defined == Unused Reference: 'CR-LDP' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-05 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'IS-IS') Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: September 2000 Don Fedyk 4 Darek Skalecki 5 Nortel Networks 7 February 2000 9 IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR-LDP 11 draft-ietf-mpls-te-feed-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 One key component of traffic engineering is a concept known as 37 constraint based routing. In constraint based routing a topology 38 database is maintained on all participating nodes. This database 39 contains a complete list of all the links in the network that 40 participate in traffic engineering and for each of these links a set 41 of constraints which those links can meet. Bandwidth, for example, 42 is one essential constraint. Since the bandwidth available changes 43 as new LSPs are established and terminated the topology database 44 will develop inconsistencies with respect to the real network. It is 45 not possible to increase the flooding rates arbitrarily to keep the 46 database discrepancies from growing. We propose a new mechanism 47 whereby a source node can learn about the successes or failures of 48 its path selections by receiving feedback from the paths it is 49 attempting. This fed-back information can be incorporated into 50 subsequent route computations, which greatly improves the accuracy 51 of the overall routing solution by significantly reducing the 52 database discrepancies. 54 1. Introduction 56 Because the network is a distributed system, it is necessary to have 57 a mechanism to advertise information about links to all nodes in the 58 network [IS-IS], [OSPF]. A node can then build a topology map of 59 the network. This information is required to be as up-to-date as 60 possible for accurate traffic engineered paths. Information about 61 link or node failures must be rapidly propagated through the network 62 so that recovery can be initiated. Other information about links 63 that may be useful for reasons of quality of service include 64 parameters such as available bandwidth, and delay. The information 65 in this topology database is often out of date with respect to the 66 real network. Available bandwidth is the most critical of these 67 attributes and it can drift substantially with respect to reality 68 due to the low frequency of link state updates that can be sustained 69 in a very large topology. We refer to the deviation in the topology 70 database available bandwidth as being optimistic if the database 71 shows more available bandwidth than there really is, or pessimistic 72 if the topology database shows less bandwidth than there really is. 73 This distinction is important because we shall propose an efficient 74 algorithm to deal with optimistic databases without resorting to 75 shorter flooding intervals. 77 One of the major problems for a constraint based routing system is 78 dealing with changing constraints. Obviously, since bandwidth is one 79 of the essential constraints, dealing with the rapid changes in 80 reserved bandwidth poses some interesting challenges. In smaller 81 networks, one can resort to higher frequency flooding but this 82 obviously does not scale. 84 The basic proposal is to add to the signaling protocol the ability 85 to piggyback actual link bandwidth availability information at every 86 link that the signaling traverses. This is done as part of the 87 reverse messaging on success or failure (mapping, release, withdraw 88 or notification). What this means is that every time signaling 89 messages flow backwards toward a source to tell it of the success, 90 failure or termination of a request, that message contains a 91 detailed slice of bandwidth availability information for the exact 92 path that the message has followed. This slice of reservation 93 information, which is very up to date, is received by the source 94 node and inserted into the source node's topology database prior to 95 making any further source route computations. The result is that the 96 source node's topology database will tend to stay synchronized with 97 the slices of the network through which it is establishing paths. 98 This is nothing more than learning from successes and failures and 99 represents an intelligent alternative to either waiting for floods 100 or introducing non-determinism (guessing) into the source 101 algorithms. 103 Operating a constraint based routing system without such feedback is 104 inefficient at best since a source node will continue to give out 105 incorrect route over and over again until it gets an IGP update. 106 This could be minutes away and as a result the worst case blocking 107 time for a new route is the minimum repeatable flooding interval 108 (often several minutes in big networks). Alternatives to feedback 109 mechanisms involve adding some non-determinism (randomness) to the 110 routing algorithm in the hopes that it will stumble onto a path that 111 works. These sorts of approaches are seen in ATM dynamic routing 112 systems, which do not have these forms of feedback. 114 In order to get a good understanding of how the feedback works, 115 imagine a network with precisely one path (with sufficient 116 unreserved bandwidth) available from the source to the destination. 117 Further, imagine that the topology database at the source is 118 significantly out of date with respect to the real network in that 119 the source topology database sees sufficient bandwidth available on 120 many different routes to the destination. We call this being 121 optimistic with respect to the network since the source thinks that 122 more bandwidth is available than there really is. 124 When such an optimistic source selects its first path it will likely 125 contain links that do not in reality have sufficient unreserved 126 bandwidth. Therefore, the path is only established up to the link 127 that does not have sufficient bandwidth. A notification message is 128 formatted that contains the actual unreserved bandwidth for this 129 blocking link which flows back toward the source, collapsing the 130 partially created path as it goes. In addition, at every link that 131 this notification traverses, the current unreserved bandwidth 132 information for each corresponding link is appended to the vector of 133 unreserved bandwidth along the path. In this manner, an accurate 134 view of the slice through the network we are traversing is 135 constructed. Eventually this message arrives back at the source 136 node, where the vector is taken and inserted into the topology 137 database. This node has just learned from its mistake and is now 138 slightly less optimistic with respect to the real network 139 conditions. 141 Path selection can be attempted again but this time the node will 142 not make the same mistake it made the previous time. The link in 143 question, at which rejection occurred the first time, will not even 144 be eligible this time around, so a source route computation is 145 guaranteed to produce a different path (or none). The same procedure 146 may be repeated as many times as is necessary, each time learning 147 from its mistakes, until eventually no paths remain in the source 148 topology to the destination, or we actually find a path that works. 149 This tendency to converge either to a solution or determine that 150 there is no solution is an important property of a routing system 151 (it actually behaves a lot like a depth first search). This property 152 is not present with flooding mechanisms alone since the source node 153 must randomly hunt, or continually make the same mistakes, or abort 154 until the next flood arrives. 156 In addition to feeding back bandwidth on failure, we also recommend 157 feedback on success. This has important consequences on our ability 158 to spread load or to spill over to new links as existing links fill. 159 It is true that spilling over to new links does not require feedback 160 on success since we could simply wait for a feedback on failure, but 161 we can achieve better load spreading earlier. 163 Finally, when a path is torn down the release/withdraw messages also 164 contain bandwidth information that can be fed back into the source 165 topology database. This is very important during failure scenarios 166 where the links we need to use to reroute the path share common sub- 167 segments with the failed path. Without the feedback, the common sub- 168 segments may not indicate sufficient available bandwidth until we 169 get a flood that may mean many seconds without a connection. With 170 feedback at least we will be up to date with respect to available 171 bandwidth up to the point of failure in the path. Also since failure 172 involves many paths tearing down and re-establishing this is the 173 time that it is most critical to have an accurate view. 175 When preemption is being employed it is also extremely important 176 that the topology database inconsistencies be small. If not, high 177 setup priority LSPs may unnecessarily preempt lower holding priority 178 LSPs to obtain bandwidth that, had they had a more up to date view 179 of unreserved bandwidth, they would have been able to find 180 elsewhere. Since preempted LSPs may in turn preempt other LSPs in a 181 domino like effect, the results of such database inconsistencies can 182 have wide reaching ripple like impacts. These feedback mechanisms 183 help reduce these occurrences significantly. 185 There are a number of network conditions where feedback shows its 186 value. One can think of a constraint-based network as being in one 187 of three conditions. The first is called ramp-up, this is when the 188 rate of arriving reservations exceeds the rate of departing 189 reservations. The second is called steady-state, this is when the 190 rate of arriving reservations is about the same as the rate of 191 departing reservations. Finally, the ramp-down condition is that 192 which has a greater rate of departing reservations than arriving 193 reservations. 195 These three network conditions show distinctly different types of 196 error in the topology databases. In particular an optimistic view of 197 available bandwidth by a source node is characteristic of the ramp- 198 up condition of a network. A pessimistic view of available bandwidth 199 by a source node is characteristic of the ramp-down condition of a 200 network. If one plots the average error in the topology databases 201 with respect to the real network for the three different network 202 conditions, one will see the error slowly go positive during ramp 203 up, slowly go negative during ramp down, and drift slowly around 0 204 for the steady condition. The effect of flooding on this plot is to 205 periodically snap the error back to 0 at flooding intervals. The 206 effect of the feedback algorithm is to bring an optimistic error 207 back to zero without having to wait for the flood interval. On 208 average then, the feedback algorithm tends to halve the absolute 209 error, keeping it mostly negative or pessimistic. This makes sense 210 since a routing system will never give paths to links that it thinks 211 do not have resources and as a result its pessimistic view of the 212 world stays that way until it gets a flood. This relieves the IGP 213 updates of the most urgent requirement of flooding when bandwidth is 214 consumed. Availability of new bandwidth occurs when paths are 215 released or new links become available. New links are accompanied 216 by floods. Significant releases of bandwidth can be broadcast at 217 relatively low frequencies in the order of several minutes with 218 little operational impact. 220 Extensive operational experience with this feedback protocol in 221 proprietary Nortel Networks (pre-standard CR-LDP) products has shown 222 it to work very well for networks up to 1000 nodes with significant 223 flooding intervals damped to several minutes. Without this protocol, 224 these networks would block setups for up to several minutes. With 225 this protocol, the blocking in most cases is reduced to a small 226 number of retry attempts which is usually sub-second depending 227 mostly on the propagation delays in the network. 229 These feedback algorithms have been particularly beneficial in cases 230 of failure recovery during which the network is in a sudden 231 condition of ramp-up. Since a large number of reservations must be 232 remade, it is highly likely that we will exceed the limits of 233 certain key links in the network. Without feedback, the rerouting 234 must block until a flood arrives telling us of the situation at 235 those key links at which time rerouting can continue. With feedback, 236 the rerouting simply continues until a feedback indicates that a 237 link is full. In addition since reservation-balancing algorithms are 238 also often used, feedback allows the balancing algorithms to make 239 better distribution decisions based on immediate feedback. 241 We have also explored through simulation and implementation a 242 variety of mechanisms to deal with the pessimistic error in the 243 database. One simple proposal is to use selective forgetting. In 244 this algorithm, a reserved bandwidth value slowly drops back to zero 245 over a relatively short time interval. The theory being that you 246 shift the network back to an optimistic state (by forgetting your 247 pessimism) where the feedback algorithm will again correctly 248 operate. These algorithms have not shown any great advantage and are 249 actually non-optimal when the error is purely optimistic. 251 Other algorithmic permutations we have explored include such 252 variations as: 254 Feeding-back to all intermediate nodes, information learned from 255 control messages upstream of that intermediate node. 257 Feeding back in both directions so that both the source and 258 destination node's databases stay synchronized. 260 Allowing a request to continue to its destination despite there 261 being insufficient bandwidth at some intermediate hop. Then, 262 rejecting the request with a full bandwidth vector slice all the way 263 to the destination instead of just to the point of rejection. 265 Our simulations have not show significant benefits relative to the 266 simpler algorithm proposed here. However, it is an interesting 267 research topic to explore and quantify the different feedback 268 algorithms and their impacts on blocking times so we do not want to 269 discourage the interested reader from exploring these concepts more 270 fully. 272 2. Adding feedback TLVs to CR-LDP 274 Two new TLVs are optionally added to the CR-LDP mapping, 275 notification, and withdraw messages. There may be an arbitrary 276 number of these TLV in any order or position in the message. It is 277 recommended that they be placed such that they can be read and 278 applied to a topology database by scanning the message forwards and 279 walking the topology database from the point where the last link 280 feedback TLV left off. 282 Each TLV consists of the 8 unreserved bandwidth values for each 283 holding priority 0 through 7 as IEEE floating point numbers (the 284 units are unidirectional bytes per second). Following this are the 285 IP addresses of the two ends of the interface. Two TLVs are 286 possible, one for IPV4 and one for IPV6 addressing of the link. 288 2.1 Bandwidth directionality considerations 290 The order of the two addresses in the feedback TLV implies the 291 direction in which the bandwidth is available. For example if the 292 first address is A and the second address is B the bandwidth is 293 unreserved in the A to B direction. 295 It is possible for an implementation to provide both the A to B 296 direction and the B to A direction as part of the same feedback 297 message. This is done by simply including a TLV with A,B as the 298 addresses of the link and a different TLV with B,A as the addresses 299 of the link. Should CR-LDP evolve to be able to support bi- 300 directional traffic flow and reservations it is expected that bi- 301 directional feedback would also be implemented via this mechanism. 303 3. IPV4 specified link feedback TLV 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |U|F| 0x830 | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 . . . . . . . . 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | IPV4 address of interface (near end) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | IPV4 address of interface (far end) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 4. IPV6 specified link feedback TLV 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |U|F| 0x831 | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 . . . . . . . . 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | IPV6 address of interface (near end) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | IPV6 address of interface (far end) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 5. Detailed Procedures 341 On receipt of a withdraw, notification, or mapping message 342 pertaining to a request made by CR-LDP (as opposed to LDP), a 343 feedback TLV of the appropriate format for the interface over which 344 the message was received is inserted into the message before 345 forwarding it back to the source of the request. The 8 bandwidth 346 values are filled in with the outgoing bandwidth available on this 347 interface for each of the 8 holding priorities in bytes per second. 348 Finally the interface's address and far end address are placed in 349 the TLV. 351 On receipt of a CR-LDP request message which cannot be satisfied. A 352 notification message is formatted normally. The 8-bandwidth values 353 are filled in with the outgoing bandwidth available on this 354 interface for each of the 8 holding priorities in bytes per second. 355 Finally, the interface's address and far end address are placed in 356 the TLV. 358 On receipt of a CR-LDP request message which has been satisfied and 359 which results in a mapping being generated. No feedback TLV is added 360 since the previous node will insert the proper TLV when it receives 361 the reverse flowing mapping. 363 When an LDP session goes down either because of a link failure, 364 TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP 365 sessions in the module must generate either notification, withdraw 366 or release messages for LSPs that traversed the LDP in question. In 367 the case that the LSP was created by CR-LDP and that a withdraw or 368 notification is about to be generated, LDP will insert a feedback 369 TLV for the interface which just went down that contains 0's for all 370 the bandwidth values and attach to it the proper interface 371 addresses. 373 When the LDP session that originated a CR-LDP label request receives 374 a mapping that contains feedback TLV's it is recommended that these 375 bandwidth values overwrite the corresponding values in the node's 376 topology database. Doing so permits this node to immediately 377 synchronize its topology with respect to the real bandwidth 378 reservations along the path that was just established. 380 When the LDP session that originated a CR-LDP label request receives 381 a notification that contains feedback TLV's it is recommended that 382 these bandwidth values overwrite the corresponding values in the 383 nodes topology database. Doing so permits this node to immediately 384 synchronize its topology with respect to the real bandwidth 385 reservations along the path that just failed to establish. The 386 source node may then re-compute a path knowing that the computation 387 will take into account the failure if it was caused by the topology 388 database being in error with respect to the real network state. 390 6. IGP considerations 392 Implementations MUST NOT permit bandwidth information learned by 393 this feedback mechanism to be re-flooded via IS-IS, OSPF or any 394 other IGP. The bandwidth information learned via these feedback 395 mechanisms is to be used ONLY for source route computations on the 396 nodes that are directly on the path that fed back the bandwidth. 397 Normally only the source node of the LSP, or perhaps intermediate 398 gateway nodes will use this information. It is however permitted for 399 intermediate nodes that are forwarding this feedback information to 400 store it for their own local source route computations. 402 There is a possibility of a race condition between the bandwidth 403 information that is received via feedback and that which is received 404 via a normal IGP flood. While there may be a discrepancy between the 405 two, both are within a few 100 milliseconds of being correct. 406 Solutions to allow us to determine which information is most up to 407 date (say by adding a sequence number) do not add any significant 408 benefit. Constraint based, source routed systems will always have 409 errors in the local topology database with respect to the real 410 network. We can reduce these errors through reduced flooding 411 intervals, path following feedback and selective flooding but we 412 cannot realistically reduce the errors below the second or so range. 413 As a result propagation delay order race conditions are noise with 414 respect to the average expected errors. An implementation SHOULD 415 therefore consider the most recently received update (IGP or 416 feedback) as being the most up to date. 418 7. Future considerations 420 Constraint based routing systems such as CR-LDP will in the future 421 offer other forms of constraint than simply reserved bandwidth. 422 Actual utilization levels, current congestion levels, number of 423 discrete channels/wavelengths available etc. are all possible 424 constraints that change rapidly and which must be taken into 425 consideration when computing a route. It is expected that this 426 mechanism will be used to feedback these and other new forms of link 427 constraining data. 429 8. RSVP consideration 431 Nothing precludes the use of such feedback mechanisms with a similar 432 TLV structure in the RSVP Resv and other reverse flowing message 433 although repeatedly applying a fed-back update into a local topology 434 database is wasteful and probably should be damped. 436 9. Intellectual Property Consideration 438 The IETF has been notified of intellectual property rights claimed 439 in regard to some or all of the specification contained in this 440 document. For more information consult the online list of claimed 441 rights. 443 10. Security Considerations 445 This document raises no new security considerations for CR-LDP, RSVP 446 or MPLS in general. 448 11. Acknowledgments 450 The authors would like to thank Keith Dysart for his guidance, and 451 Jerzy Miernik for helping implement these concepts and bringing them 452 to life. 454 12. References 456 [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- 457 ldp-04.txt 459 [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt 461 [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- 462 isis-traffic-01.txt 464 13. Author's Addresses 466 Peter Ashwood-Smith Bilel Jamoussi 467 Nortel Networks Corp. Nortel Networks Corp. 468 P.O. Box 3511 Station C, 600 Technology Park Drive 469 Ottawa, ON K1Y 4H7 Billerica, MA 01821 470 Canada USA 471 Phone: +1 613-763-4534 phone: +1 978-288-4506 472 petera@nortelnetworks.com jamoussi@nortelnetworks.com 474 Darek Skalecki Don Fedyk 475 Nortel Networks Corp. Nortel Networks Corp. 476 P.O. Box 3511 Station C, 600 Technology Park Drive 477 Ottawa, On K1Y 4H7 Billerica, MA 01821 478 Canada USA 479 Phone: +1 613-765-2252 Phone: +1 978-228-3041 480 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com 482 Full Copyright Statement 484 Copyright (C) The Internet Society (date). All Rights Reserved. This 485 document and translations of it may be copied and furnished to 486 others, and derivative works that comment on or otherwise explain it 487 or assist in its implementation may be prepared, copied, published 488 and distributed, in whole or in part, without restriction of any 489 kind, provided that the above copyright notice and this paragraph 490 are included on all such copies and derivative works. However, this 491 document itself may not be modified in any way, such as by removing 492 the copyright notice or references to the Internet Society or other 493 Internet organizations, except as needed for the purpose of 494 developing Internet standards in which case the procedures for 495 copyrights defined in the Internet Standards process must be 496 followed, or as required to translate it into languages other than 497 English. 499 The limited permissions granted above are perpetual and will not be 500 revoked by the Internet Society or its successors or assigns.