idnits 2.17.1 draft-ietf-diffserv-rfc2598bis-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 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 abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 2001) is 8472 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) -- Looks like a reference, but probably isn't: 'RFC2474' on line 451 == Unused Reference: '1' is defined on line 462, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 472, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (ref. '1') (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2983 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruce Davie, Editor 3 Internet Draft Anna Charny 4 Expiration Date: August 2001 Fred Baker 5 Cisco Systems, Inc. 6 Jon Bennet 7 Riverdelta Networks 9 Kent Benson Jean-Yves Le Boudec 10 Tellabs EPFL 12 Angela Chiu William Courtney 13 AT&T Labs TRW 15 Shahram Davari Victor Firoiu 16 PMC-Sierra Nortel Networks 18 Charles Kalmanek K.K. Ramakrishnam 19 AT&T Research TeraOptic Networks 21 Dimitrios Stiliadis 22 Lucent Technologies 24 February 2001 26 An Expedited Forwarding PHB 28 draft-ietf-diffserv-rfc2598bis-00.txt 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This document is a product of the Diffserv working group of the 52 Internet Engineering Task Force. Please address comments to the 53 group's mailing list at diffserv@ietf.org, with a copy to the 54 authors. 56 Copyright Notice 58 Copyright (C) The Internet Society (2001). All Rights Reserved. 60 Abstract 62 The PHB (per-hop behavior) is a basic building block in the 63 Differentiated Services architecture. This document defines a PHB 64 called Expedited Forwarding (EF). EF is intended to provide a 65 building block for low delay and low loss services by ensuring that 66 the EF aggregate is served at a certain configured rate. 68 Contents 70 1 Introduction ........................................... 3 71 2 Definition of EF PHB ................................... 4 72 2.1 Intuitive Description of EF ............................ 4 73 2.2 Formal Definition of the EF PHB ........................ 5 74 2.3 Figures of merit ....................................... 8 75 2.4 Delay and jitter ....................................... 9 76 2.5 Loss ................................................... 9 77 2.6 Microflow misordering .................................. 10 78 2.7 Recommended codepoint for this PHB ..................... 10 79 2.8 Mutability ............................................. 10 80 2.9 Tunneling .............................................. 10 81 2.10 Interaction with other PHBs ............................ 10 82 3 Security Considerations ................................ 11 83 4 IANA Considerations .................................... 11 84 5 Acknowledgments ........................................ 11 85 6 References ............................................. 11 86 7 Full Copyright ......................................... 15 88 Specification of Requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [3]. 94 1. Introduction 96 Network nodes that implement the differentiated services enhancements 97 to IP use a codepoint in the IP header to select a per-hop behavior 98 (PHB) as the specific forwarding treatment for that packet [RFC2474, 99 RFC2475]. This memo describes a particular PHB called expedited 100 forwarding (EF). 102 The intent of the EF PHB is to provide a building block for low loss, 103 low delay, and low jitter services. The details of exactly how to 104 build such services are outside the scope of this specification. 106 The dominant causes of delay in packet networks are speed-of-light 107 propagation delays on wide area links and queuing delays in switches 108 and routers. Since propagation delays are a fixed property of the 109 topology, delay and jitter are minimized when queueing delays are 110 minimized. In this context, jitter is defined as the variation 111 between maximum and minimum delay. The intent of the EF PHB is to 112 provide a PHB in which suitably marked packets usually encounter 113 short or empty queues. Furthermore, if queues remain short relative 114 to the buffer space available, packet loss is also kept to a minimum. 116 To ensure that queues encountered by EF packets are usually short, it 117 is necessary to ensure that the service rate of EF packets on a given 118 output interface exceeds their arrival rate at that interface over 119 long and short time intervals, independent of the load of other 120 (non-EF) traffic. This specification defines a PHB in which EF 121 packets are guaranteed to receive service at or above a configured 122 rate and provides a means to quantify the accuracy with which this 123 service rate is delivered over any time interval. It also provides a 124 means to quantify the maximum delay and jitter that a packet may 125 experience under bounded operating conditions. 127 Note that the EF PHB only defines the behavior of a single node. The 128 specification of behavior of a collection of nodes is outside the 129 scope of this document. A Per-Domain Behavior (PDB) specification [7] 130 may provide such information. 132 When a DS-compliant node claims to implement the EF PHB, the 133 implementation MUST conform to the specification given in this 134 document. However, the EF PHB is not a mandatory part of the 135 Differentiated Services architecture - a node is NOT REQUIRED to 136 implement the EF PHB in order to be considered DS-compliant. 138 2. Definition of EF PHB 140 2.1. Intuitive Description of EF 142 Intuitively, the definition of EF is simple: the rate at which EF 143 traffic is served at a given output interface should be at least the 144 configured rate R, over a suitably defined interval, independent of 145 the offered load of non-EF traffic to that interface. Two 146 difficulties arise when we try to formalize this intuition: 148 - it is difficult to define the appropriate timescale at which to 149 measure R. By measuring at short timescales we may introduce 150 sampling errors; at long timescales we may allow excessive jitter. 152 - EF traffic clearly cannot be served at rate R if there are no EF 153 packets waiting to be served, but it may be impossible to 154 determine externally whether EF packets are actually waiting to be 155 served by the output scheduler. For example, if an EF packet has 156 entered the router and not exited, it may be awaiting service, or 157 it may simply have encountered some processing or transmission 158 delay within the router. 160 The formal definition below takes account of these issues. It assumes 161 that EF packets should ideally be served at rate R or faster, and 162 bounds the deviation of the actual departure time of each packet from 163 the "ideal" departure time of that packet. We define the departure 164 time of a packet as the time when the last bit of that packet leaves 165 the node. The "ideal" departure time of each EF packet is computed 166 iteratively. 168 In the case when an EF packet arrives to a device when all the 169 previous EF packets have already departed, the computation of the 170 ideal departure time is simple. Service of the packet should 171 (ideally) start as soon as it arrives, so the ideal departure time is 172 simply the arrival time plus the ideal time to transmit the packet at 173 rate R. For a packet of length L_j, that transmission time at the 174 configured rate R is L_j/R. (Of course, a real packet will typically 175 get transmitted at line rate once its transmission actually starts, 176 but we are calculating the ideal target behavior here; the ideal 177 service takes place at rate R.) 179 In the case when an EF packet arrives to a device which still 180 contains EF packets awaiting service, the computation of the ideal 181 departure time is more complicated. There are two cases to be 182 considered. If the previous (j-1-th) departure occurred after its own 183 ideal departure time, then the scheduler is running "late". In this 184 case, the ideal time to start service of the new packet is the ideal 185 departure time of the previous (j-1-th) packet, or the arrival time 186 of the new packet, whichever is later, because we can't expect a 187 packet to begin service before it arrives. If the previous (j-1-th) 188 departure occurred before its own ideal departure time, then the 189 scheduler is running "early". In this case, service of the new packet 190 should begin at the actual departure time of the previous packet. 192 Once we know the time at which service of the jth packet should 193 (ideally) begin, then the ideal departure time of the jth packet is 194 L_j/R seconds later. Thus we are able to express the ideal departure 195 time of the jth packet in terms of the arrival time of the jth 196 packet, the actual departure time of the j-1-th packet, and the ideal 197 departure time of the j-1-th packet. Equations eq_1 and eq_2 in 198 Section 2.2 capture this relationship. 200 Whereas the original EF definition did not provide any means to 201 guarantee the delay of an individual EF packet, this property may be 202 desired. For this reason, the equations in Section 2.2 consist of two 203 parts: a "colorblind" set and a "packet-identity-aware" set of 204 equations. The colorblind equations (eq_1 and eq_2) simply describe 205 the properties of the service delivered to the EF aggregate by the 206 device. The "packet-identity-aware" equations (eq_3 and eq_4) enable 207 the bound on delay of an individual packet to be calculated given a 208 knowledge of the operating conditions of the device. The significance 209 of these two sets of equations is discussed further in Section 2.2. 210 Note that these two sets of equations provide two ways of 211 characterizing the behavior of a single device, not two different 212 modes of behavior. 214 2.2. Formal Definition of the EF PHB 216 A node that supports EF on an interface I at some configured rate R 217 MUST satisfy the following equations: 219 d_j <= f_j + E_a (eq_1) 221 where f_j is defined iteratively by 223 f_0 = 0, d_0 = 0 225 f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2) 227 In this definition: 229 - d_j is the time that the last bit of the j-th EF packet to 230 depart actually leaves the node from the interface I. 232 - f_j is the target departure time for the j-th EF packet to 233 depart from I, the "ideal" time at or before which the last bit of 234 that packet should leave the node. 236 - a_j is the time that the last bit of the j-th EF packet destined 237 to the output I to arrive actually arrives at the node. 239 - l_j is the size (bits) of the j-th EF packet to depart from I. 240 l_j is measured on the IP datagram (IP header plus payload) and 241 does not include any lower layer (e.g. MAC layer) overhead. 243 - R is the EF configured rate at output I (in bits/second). 245 - E_a is the error term for the treatment of the EF aggregate. 246 Note that E_a represents the worst case deviation between actual 247 departure time of an EF packet and ideal departure time of the 248 same packet, i.e. E_a provides an upper bound on (d_j - f_j) for 249 all j. 251 - d_0 and f_0 do not refer to a real packet departure but are used 252 purely for the purposes of the recursion. The time origin should 253 be chosen such that no EF packets are in the system at time 0. 255 An EF-compliant node MUST be able to be characterized by the range of 256 possible R values that it can support on each of its interfaces while 257 conforming to these equations, and the value of E_a that can be met 258 on each interface. R may be line rate or less. E_a MAY be specified 259 as a worst-case value for all possible R values or MAY be expressed 260 as a function of R. 262 Note also that, since a node may have multiple inputs and complex 263 internal scheduling, the jth packet to arrive may not be the jth 264 packet to depart. It is in this sense that eq_1 and eq_2 are 265 colorblind with regard to packet identity. 267 In addition, a node that supports EF on an interface I at some 268 configured rate R MUST satisfy the following equations: 270 D_j <= F_j + E_p (eq_3) 272 where F_j is defined iteratively by 274 F_0 = 0, D_0 = 0 276 F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4) 278 In this definition: 280 - D_j is actual the departure time of the individual EF packet 281 that arrived at time A_j, i.e., given a packet which was the j-th 282 EF packet destined for I to arrive at the node via any input, D_j 283 is the time at which the last bit of that individual packet 284 actually leaves the node from the interface I. 286 - F_j is the target departure time for the individual EF packet 287 which arrived at time A_j. 289 - A_j is the time that the last bit of the j-th EF packet destined 290 to the output I to arrive actually arrives at the node. 292 - L_j is the size (bits) of the j-th EF packet to arrive at the 293 node that is destined to output I. L_j is measured on the IP 294 datagram (IP header plus payload) and does not include any lower 295 layer (e.g. MAC layer) overhead. 297 - R is the EF configured rate at output I (in bits/second). 299 - E_p is the error term for the treatment of individual EF 300 packets. Note that E_p represents the worst case deviation between 301 actual departure time of an EF packet and ideal departure time of 302 the same packet, i.e. E_p provides an upper bound on (D_j - F_j) 303 for all j. 305 - D_0 and F_0 do not refer to a real packet departure but are used 306 purely for the purposes of the recursion. The time origin should 307 be chosen such that no EF packets are in the system at time 0. 309 It is the fact that D_j and F_j refer to departure times for the jth 310 packet to arrive that makes eq_3 and eq_4 aware of packet identity. 311 This is the critical distinction between the last two equations and 312 the first two. 314 An EF-compliant node SHOULD be able to be characterized by the range 315 of possible R values that it can support on each of its interfaces 316 while conforming to these equations, and the value of E_p that can be 317 met on each interface. E_p MAY be specified as a worst-case value for 318 all possible R values or MAY be expressed as a function of R. An E_p 319 value of "undefined" MAY be specified. For discussion of situations 320 in which E_p may be undefined see the Appendix and [6]. 322 2.3. Figures of merit 324 E_a and E_p may be thought of as "figures of merit" for a device. A 325 smaller value of E_a means that the device serves the EF aggregate 326 more smoothly at rate R over relatively short timescales, whereas a 327 larger value of E_a implies a more bursty scheduler which serves the 328 EF aggregate at rate R only when measured over longer intervals. A 329 device with a larger E_a can "fall behind" the ideal service rate R 330 by a greater amount than a device with a smaller E_a. 332 A lower value of E_p implies a tighter bound on the delay experienced 333 by an individual packet. Factors that might lead to a higher E_p 334 might include a large number of input interfaces (since an EF packet 335 might arrive just behind a large number of EF packets that arrived on 336 other interfaces), or might be due to internal scheduler details 337 (e.g. per-flow scheduling within the EF aggregate). 339 We observe that factors that increase E_a such as those noted above 340 will also increase E_p, and that E_p is thus typically greater than 341 or equal to E_a. In summary, E_a is a measure of deviation from 342 ideal service of the EF aggregate at rate R, while E_p measures both 343 non-ideal service and non-FIFO treatment of packets within the 344 aggregate. 346 For more discussion of these issues see the Appendix and [6]. 348 2.4. Delay and jitter 350 Given a known value of E_p and a knowledge of the bounds on the EF 351 traffic offered to a given output interface, summed over all input 352 interfaces, it is possible to bound the delay and jitter that will be 353 experienced by EF traffic leaving the node via that interface. The 354 delay bound is 356 D = B/R + E_p (eq_5) 358 where 360 - R is the configured EF service rate on the output interface 362 - the total offered load of EF traffic destined to the output 363 interface, summed over all input interfaces, is bounded by a token 364 bucket of rate r <= R and depth B 366 Since the minimum delay through the device is clearly at least zero, 367 D also provides a bound on jitter. To provided a tighter bound on 368 jitter, a device MAY advertise E_p as two separate components such 369 that 371 E_p = E_fixed + E_variable 373 where E_fixed represents the minimum delay that can be experienced by 374 an EF packet through the node. 376 2.5. Loss 378 The EF PHB is intended to be a building block for low loss services. 379 However, under sufficiently high load of EF traffic (including 380 unexpectedly large bursts from many inputs at once), any device with 381 finite buffers may need to discard packets. Thus, it must be possible 382 to establish whether a device conforms to the EF definition even when 383 some packets are lost. This is done by performing an "off-line" test 384 of conformance to equations 1 through 4. After observing a sequence 385 of packets entering and leaving the node, the packets which did not 386 leave are assumed lost and are notionally removed from the input 387 stream. The remaining packets now constitute the arrival stream (the 388 a_j's) and the packets which left the node constitute the departure 389 stream (the d_j's). Conformance to the equations can thus be verified 390 by considering only those packets that successfully passed through 391 the node. 393 In addition, to assist in meeting the low loss objective of EF, a 394 node MAY be characterized by the operating region in which loss of EF 395 due to congestion will not occur. This MAY be specified, using a 396 token bucket of rate r <= R and burstsize B, as the sum of traffic 397 across all inputs to a given output interface that can be tolerated 398 without loss. 400 In the event that loss does occur, the specification of which packets 401 are lost is beyond the scope of this document. However it is a 402 requirement that those packets not lost MUST conform to the equations 403 of Section 2.2. 405 2.6. Microflow misordering 407 Packets belonging to a single microflow within the EF aggregate 408 passing through a device SHOULD NOT experience re-ordering in normal 409 operation of the device. 411 2.7. Recommended codepoint for this PHB 413 Codepoint 101110 is RECOMMENDED for the EF PHB. 415 2.8. Mutability 417 Packets marked for EF PHB MAY be remarked at a DS domain boundary 418 only to other codepoints that satisfy the EF PHB. Packets marked for 419 EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS 420 domain. 422 2.9. Tunneling 424 When EF packets are tunneled, the tunneling packets SHOULD be marked 425 as EF. A full discussion of tunneling issues is presented in [5]. 427 2.10. Interaction with other PHBs 429 Other PHBs and PHB groups may be deployed in the same DS node or 430 domain with the EF PHB. The equations of Section 2.2 MUST hold for a 431 node independent of the amount of non-EF traffic offered to it. 433 If the EF PHB is implemented by a mechanism that allows unlimited 434 preemption of other traffic (e.g., a priority queue), the 435 implementation SHOULD include some means to limit the damage EF 436 traffic could inflict on other traffic. This will be reflected in the 437 range of supported R values as described in section 2.2. 439 3. Security Considerations 441 To protect itself against denial of service attacks, the edge of a DS 442 domain SHOULD strictly police all EF marked packets to a rate 443 negotiated with the adjacent upstream domain. Packets in excess of 444 the negotiated rate SHOULD be dropped. If two adjacent domains have 445 not negotiated an EF rate, the downstream domain SHOULD use 0 as the 446 rate (i.e., drop all EF marked packets). 448 4. IANA Considerations 450 This document allocates one codepoint, 101110, in Pool 1 of the code 451 space defined by [RFC2474]. 453 5. Acknowledgments 455 This document draws heavily on the original EF PHB definition of 456 Jacobson, Nichols and Poduri. It was also greatly influenced by the 457 work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, 458 Kumar, and Schnizlein. 460 6. References 462 [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 463 PHB", RFC 2598, June 1999 465 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 466 Levels", RFC 2119, BCP 14, March 1997 468 [3] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 469 Differentiated Services Field (DS Field) in the IPv4 and IPv6 470 Headers", RFC 2474, December 1998. 472 [4] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 473 Architecture for Differentiated Services", RFC 2475, December 1998. 475 [5] D. Black, "Differentiated Services and Tunnels", RFC 2983, 476 October 2000. 478 [6] A. Charny et al., "Supplemental Information for the New 479 Definition of the EF PHB", Work in Progress, February 2001. 481 [7] K. Nichols and B. Carpenter, "Definition of Differentiated 482 Services Per Domain Behaviors and Rules for their Specification", 483 Work in Progress, January 2001. 485 Appendix: Implementation Examples 487 This appendix is not part of the normative specification of EF. 488 However, it is included here as a possible source of useful 489 information for implementors. 491 A variety of factors in the implementation of a node supporting EF 492 will influence the values of E_a and E_p. These factors are discussed 493 in more detail in [6], and include both output schedulers and the 494 internal design of a device. 496 A priority queue is widely considered as the canonical example of an 497 implementation of EF. A "perfect" output buffered device (i.e. one 498 which delivers packets immediately to the appropriate output queue) 499 with a priority queue for EF traffic will provide both a low E_a and 500 a low E_p. We note that the main factor influencing E_a will be the 501 inability to pre-empt an MTU-sized non-EF packet that has just begun 502 transmission at the time when an EF packet arrives at the output 503 interface, plus any additional delay that might be caused by non- 504 pre-emptable queues between the priority queue and the physical 505 interface. E_p will be influenced primarily by the number of 506 interfaces. 508 Another example of an implementation of EF is a weighted round robin 509 scheduler. Such an implementation will typically not be able to 510 support values of R as high as the link speeds, because the maximum 511 rate at which EF traffic can be served in the presence of competing 512 traffic will be affected by the number of other queues and the 513 weights given to them. Furthermore, such an implementation is likely 514 to have a value of E_a that is higher than a priority queue 515 implementation, all else being equal, as a result of the time spent 516 serving non-EF queues by the round robin scheduler. 518 Finally, it is possible to implement hierarchical scheduling 519 algorithms, such that some non-FIFO scheduling algorithm is run on 520 sub-flows within the EF aggregate, while the EF aggregate as a whole 521 could be served at high priority or with a large weight by the top- 522 level scheduler. Such an algorithm might perform per-input scheduling 523 or per-microflow scheduling within the EF aggregate, for example. 524 Because such algorithms lead to non-FIFO service within the EF 525 aggregate, the value of E_p for such algorithms may be higher than 526 for other implementations. For some schedulers of this type it may be 527 difficult to provide a meaningful bound on E_p that would hold for 528 any pattern of traffic arrival, and thus a value of "undefined" may 529 be most appropriate. 531 Authors' Addresses 533 Bruce Davie 534 Cisco Systems, Inc. 535 300 Apollo Drive 536 Chelmsford, MA, 01824 538 E-mail: bsd@cisco.com 540 Anna Charny 541 Cisco Systems 542 300 Apollo Drive 543 Chelmsford, MA 01824 545 E-mail: acharny@cisco.com 547 Fred Baker 548 Cisco Systems 549 170 West Tasman Dr. 550 San Jose, CA 95134 552 E-mail: fred@cisco.com 554 Jon Bennett 555 RiverDelta Networks 556 3 Highwood Drive East 557 Tewksbury, MA 01876 559 E-mail: jcrb@riverdelta.com 561 Kent Benson 562 Tellabs Research Center 563 3740 Edison Lake Parkway #101 564 Mishawaka, IN 46545 566 E-mail: Kent.Benson@tellabs.com 567 Jean-Yves Le Boudec 568 ICA-EPFL, INN 569 Ecublens, CH-1015 570 Lausanne-EPFL, Switzerland 572 E-mail: leboudec@epfl.ch 574 Angela Chiu 575 AT&T Labs 576 100 Schulz Dr. Rm 4-204 577 Red Bank, NJ 07701 579 E-mail: alchiu@att.com 581 Bill Courtney 582 TRW 583 Bldg. 201/3702 584 One Space Park 585 Redondo Beach, CA 90278 587 E-mail: bill.courtney@trw.com 589 Shahram Davari 590 PMC-Sierra Inc 591 411 Legget Drive 592 Ottawa, ON K2K 3C9, Canada 594 E-mail: shahram_davari@pmc-sierra.com 596 Victor Firoiu 597 Nortel Networks 598 600 Tech Park 599 Billerica, MA 01821 601 E-mail: vfirou@nortelnetworks.com 602 Charles Kalmanek 603 AT&T Labs-Research 604 180 Park Avenue, Room A113, 605 Florham Park NJ 607 E-mail: crk@research.att.com. 609 K.K. Ramakrishnan 610 TeraOptic Networks, Inc. 611 686 W. Maude Ave 612 Sunnyvale, CA 94086 614 E-mail: kk@teraoptic.com 616 Dimitrios Stiliadis 617 Lucent Technologies 618 1380 Rodick Road 619 Markham, Ontario, L3R-4G5, Canada 621 E-mail: stiliadi@bell-labs.com 623 7. Full Copyright 625 Copyright (C) The Internet Society 2001. All Rights Reserved. 627 This document and translations of it may be copied and furnished to 628 others, and derivative works that comment on or otherwise explain it 629 or assist in its implementation may be prepared, copied, published 630 and distributed, in whole or in part, without restriction of any 631 kind, provided that the above copyright notice and this paragraph are 632 included on all such copies and derivative works. However, this 633 document itself may not be modified in any way, such as by removing 634 the copyright notice or references to the Internet Society or other 635 Internet organizations, except as needed for the purpose of 636 developing Internet standards in which case the procedures for 637 copyrights defined in the Internet Standards process must be 638 followed, or as required to translate it into languages other than 639 English. 641 The limited permissions granted above are perpetual and will not be 642 revoked by the Internet Society or its successors or assigns. 644 This document and the information contained herein is provided on an 645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.