idnits 2.17.1 draft-briscoe-tsvwg-cl-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1078. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1085. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1105), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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. ** 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 755: '... RECOMMENDED rather than EXP/LU (...' 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 (July 11, 2005) is 6857 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) == Unused Reference: 'AVQ' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'GSP- TR' is defined on line 927, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 970, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AVQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'Briscoe' == Outdated reference: A later version (-03) exists of draft-briscoe-tsvwg-cl-phb-00 -- Possible downref: Normative reference to a draft: ref. 'CL-PHB' -- Possible downref: Non-RFC (?) normative reference: ref. 'DCAC' == Outdated reference: A later version (-02) exists of draft-floyd-ecn-alternates-00 -- Possible downref: Normative reference to a draft: ref. 'Floyd' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSPa' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSP- TR' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSP-TR' -- Possible downref: Non-RFC (?) normative reference: ref. 'Johnson' -- Possible downref: Non-RFC (?) normative reference: ref. 'Re-feedback' -- Possible downref: Non-RFC (?) normative reference: ref. 'Reid' ** Downref: Normative reference to an Informational RFC: RFC 2208 ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 2998 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-rmd (ref. 'RMD') == Outdated reference: A later version (-05) exists of draft-babiarz-tsvwg-rtecn-03 -- Possible downref: Normative reference to a draft: ref. 'RTECN' -- Possible downref: Normative reference to a draft: ref. 'RTECN-usage' Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG B. Briscoe 2 Internet Draft G. Corliano 3 draft-briscoe-tsvwg-cl-architecture-00.txt P. Eardley 4 Expires: January 2006 P. Hovell 5 A. Jacquet 6 D. Songhurst 7 BT 8 July 11, 2005 10 An architecture for edge-to-edge controlled load service using 11 distributed measurement-based admission control 12 draft-briscoe-tsvwg-cl-architecture-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on January 11, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 This document describes an architecture to achieve a Controlled Load 47 (CL) service edge-to-edge, i.e. within a particular region of the 48 Internet, by using distributed measurement-based admission control. The 49 measurement made is of CL packets that have their Congestion 50 Experienced (CE) codepoint set as they travel across the edge-to-edge 51 region. Setting the CE codepoint, which is under the control of a new 52 Per Hop Behaviour (CL-ramp-PHB, defined in draft-briscoe-tsvwg-cl-phb- 53 00.txt), provides an "early warning" of potential congestion. This 54 information is used by the ingress node of the edge-to-edge region to 55 decide whether to admit a new CL microflow. 57 A use case is described which shows how the PHB is a fundamental 58 building block in the edge-to-edge architecture, and in turn how this 59 is a building block within a broader QoS architecture achieving an end- 60 to-end CL service. 62 Table of Contents 64 1. Introduction................................................3 65 1.1. Summary................................................3 66 1.2. Key features...........................................4 67 1.3. Benefits...............................................6 68 1.4. Standardisation requirements............................6 69 1.5. Terminology............................................7 70 1.6. Structure of rest of document...........................8 71 2. Use case....................................................8 72 2.1. Configured bandwidth allocation to the CL behaviour aggregate 73 ...........................................................10 74 2.2. Flexible bandwidth allocation to CL behaviour aggregate.11 75 3. Details....................................................12 76 3.1. Packet processing......................................12 77 3.1.1. Ingress nodes.....................................12 78 3.1.2. Interior nodes....................................13 79 3.1.3. Egress nodes......................................15 80 3.2. Signalling............................................16 81 4. Extensions.................................................17 82 4.1. Multi-domain and multi-operator usage..................17 83 4.2. Variable bit rate sources..............................18 84 4.3. Starvation prevention..................................18 85 5. Relationship to other QoS mechanisms........................18 86 5.1. Standardisation requirements...........................18 87 5.2. Controlled Load........................................18 88 5.3. Integrated services operation over Diffserv............19 89 5.4. Differentiated Services................................19 90 5.5. ECN...................................................19 91 5.6. RTECN.................................................20 92 5.7. RMD...................................................20 93 5.8. MPLS-TE...............................................20 94 6. Security Considerations.....................................21 95 7. Acknowledgements...........................................21 96 8. Comments solicited.........................................21 97 9. References.................................................21 98 Authors' Addresses............................................24 99 Intellectual Property Statement................................26 100 Disclaimer of Validity........................................26 101 Copyright Statement...........................................26 103 1. Introduction 105 1.1. Summary 107 This document describes an architecture to achieve a controlled load 108 service edge-to-edge, i.e. within a particular region of the 109 Internet, using distributed measurement-based admission control. 110 Controlled load service is a quality of service (QoS) closely 111 approximating the QoS that the same flow would receive from a lightly 112 loaded network element [RFC2211]. Controlled Load (CL) is useful for 113 inelastic flows such as those for streaming real-time media. 115 The architecture described in this document achieves edge-to-edge 116 controlled load service using a new Per Hop Behaviour (PHB) as a 117 fundamental building block. In turn, an end-to-end CL service would 118 use this architecture as a building block within a broader QoS 119 architecture. The PHB, edge-to-edge and end-to-end aspects are now 120 briefly introduced in turn. 122 The new PHB, called CL-ramp-PHB, is defined in [CL-PHB]. Network 123 nodes that implement the differentiated services (DS) enhancements to 124 IP use a codepoint in the IP header to select a PHB as the specific 125 forwarding treatment for that packet [RFC2474, RFC2475]. The CL-ramp- 126 PHB is different from PHBs defined so far, in that it defines 127 Explicit Congestion Notification (ECN) marking semantics as part of 128 the PHB. A node in the CL-region sets the Congestion Experienced (CE) 129 codepoint in the IP header as an "early warning" of potential 130 congestion, and aims to do so before there is any significant build- 131 up of CL packets in the queue. 133 To achieve the CL service edge-to-edge, ie within a region of the 134 Internet - which we call CL-region (defined below) - distributed 135 measurement-based admission control is used. All nodes within the CL- 136 region run the CL-ramp-PHB. The measurement is of the CL packets that 137 have had their CE codepoint set as they travel across the CL-region. 138 Since any node in the CL-region may set the CE codepoint, the 139 measurement is distributed. The measurement is recorded by the egress 140 node of the CL-region. The egress node calculates the bits in these 141 CE packets as a fraction of the bits in all the CL packets, as an 142 exponentially weighted moving average (which we term Congestion- 143 Level-Estimate). Depending on the value of Congestion-Level-Estimate, 144 the ingress node of the CL-region decides whether to admit a new CL 145 microflow. Since setting the CE codepoint is an "early warning" of 146 potential congestion (ie before there is any significant build-up of 147 CL packets in the queue), the admission control procedure means that 148 previously accepted CL microflows will suffer minimal queuing delay, 149 jitter and loss - exactly the requirements of real time traffic. 151 In turn, the edge-to-edge architecture is a building block in 152 delivering an end-to-end CL service. The approach is similar to that 153 described in [RFC2998] for Integrated services operation over 154 Diffserv networks. Like [RFC2998], an IntServ class (CL in our case) 155 is achieved end-to-end, with a CL-region viewed as a single 156 reservation hop in the total end-to-end path. Interior routers of the 157 CL-region do not process flow signalling nor do they hold state. 158 Unlike [RFC2998] we do not require the end-to-end signalling 159 mechanism to be RSVP, although it can be - as indeed we assume in 160 Sections 2 and 3. [RFC2998] and our approach are compared further in 161 Section 5. 163 1.2. Key features 165 In this section we discuss some of the key aspects of the edge-to- 166 edge architecture. 168 One key feature of our approach revolves around the use of Explicit 169 Congestion Notification (ECN) [RFC3168] to indicate that the amount 170 of packets flowing is getting close to the engineered capacity. Note 171 that ECN operates across the CL-region, ie edge-to-edge, and not 172 host-to-host as in [RFC3168]. 174 The new PHB, CL-ramp-PHB, is designed to provide an "early warning" 175 of potential congestion. It assumes that a new microflow won't move 176 the CL-region directly from no congestion to overload; there will 177 always be an intermediate stage where a new CL microflow causes CL 178 packets to have their CE codepoint set but still be delivered without 179 significant delay. This assumption is valid for core and backbone 180 networks but is unlikely to be valid in access networks where the 181 granularity of an individual call becomes significant. 183 Note that the CL-region can potentially span multiple domains. 184 Indeed, over time CL-regions may incrementally grow and merge, and 185 could eventually become a single CL-region encompassing all core and 186 backbone networks, providing Internet-wide controlled load service in 187 concert with stateful admission control mechanisms at the very edges 188 of the Internet. 190 It is also possible for a CL-region to include domains run by 191 different operators. The border routers between operators within the 192 CL-region only have to do bulk accounting - per microflow metering 193 and policing is not needed. Section 4.1 discusses further. 195 CL-packets are marked with a Differentiated Services Codepoint 196 (DSCP), so that nodes in the CL-region can distinguish the CL packets 197 from non-CL ones [RFC2474] and know that the CL-ramp-PHB is required. 199 However, note that we do not use the traffic conditioning agreements 200 (TCAs) of the (informational) Diffserv architecture [RFC2475], in 201 which operators in practice rely on subscription-time Service Level 202 Agreements (SLAs) that statically define the parameters of the 203 traffic that will be accepted from a customer. Operators deploying 204 our mechanism do not need to make a fixed assignment of capacity 205 because the division of bandwidth between CL and non-CL traffic can 206 be flexible. 208 Our edge-to-edge architecture uses dynamic admission control: the 209 closed feedback loop between the ingress and egress nodes of the CL- 210 region. The key advantage of controlling the load dynamically rather 211 than with TCAs is that the latter can fail catastrophically. The 212 problem arises because the TCA at the ingress must allow any 213 destination address, if it is to remain scalable. But for longer 214 topologies, the chances increase that traffic will focus on a 215 resource near the egress, even though it is within contract at the 216 ingress [Reid]. Even though networks can be engineered to make such 217 failures rare, when they occur all inelastic flows through the 218 congested resource fail catastrophically. This is also why in our 219 approach the egress node of the CL-region calculates the Congestion- 220 Level-Estimate separately for CL packets from each ingress node. 222 Finally, it is assumed that the end systems react properly to non-CL 223 packets that are dropped or have their CE codepoint set, otherwise 224 new CL microflows calls may get unfairly blocked. How to police this 225 is out of scope of this document. 227 1.3. Benefits 229 We believe that the mechanism described in this document has several 230 advantages, which we briefly explain with reference to the key 231 features described above: 233 o It achieves statistical guarantees of quality of service for 234 microflows, delivering a very low delay, jitter and packet loss 235 service suitable for applications like voice and video calls that 236 generate real time inelastic traffic. This is because of its per 237 microflow admission control scheme, combined with its "early 238 warning" of potential congestion. The guarantee is at least as 239 strong as with Intserv Controlled Load (Section 5 mentions why the 240 guarantee may be somewhat better), but without its scalability 241 problems [RFC2208]. 243 o It scales well, because there is no signal processing or path 244 state held by the interior nodes of the CL-region. 246 o It is resilient, again because no state is held by the interior 247 nodes of the CL-region. 249 o It requires minimal new standardisation, because it reuses 250 existing QoS protocols. 252 o It can be deployed incrementally, network by network. Not all the 253 networks on the end-to-end path need to have it deployed. Two CL- 254 regions can be separated by a network that uses another QoS 255 mechanism (eg MPLS), or where they are adjacent can merge to 256 become a single CL-region. 258 o It can work between operators, ie the CL-region can include 259 domains run by different operators. This is scalable because there 260 is only bulk metering at the inter-operator interface; there is no 261 need for per microflow accounting or policing. 263 1.4. Standardisation requirements 265 The architecture described in this document has two new 266 standardisation requirements: for a new PHB, as described in [CL- 267 PHB], and for the end-to-end signalling protocol to carry the 268 Congestion-Level-Estimate report (eg with RSVP, the RESV message must 269 carry a new opaque object across the CL-region). Other than these two 270 things, the arrangement uses existing standards throughout although, 271 as mentioned above, not in their usual architecture. Section 5 272 discusses standardisation issues further. 274 This document is INFORMATIONAL. 276 1.5. Terminology 278 o Ingress node: a node which is an ingress gateway to the CL-region. 279 A CL-region may have several ingress nodes. 281 o Egress node: a node which is an egress gateway from the CL-region. 282 A CL-region may have several egress nodes. 284 o Interior node: a node which is part of the CL-region, but isn't an 285 ingress or egress node. 287 o CL-region: A region of the Internet in which all nodes run the CL- 288 ramp-PHB and all traffic enters/leaves through an ingress/egress 289 node. A CL-region is a DS region (a DS region is either a single 290 DS domain or set of contiguous DS domains), but note that the CL- 291 region does not use the traffic conditioning agreements (TCAs) of 292 the (informational) Diffserv architecture. 294 o CL-ramp-PHB: A new Per Hop Behaviour, described in [CL-PHB]. 296 o Congestion-Level-Estimate: the bits in CL packets that have the CE 297 codepoint set, divided by the bits in all CL packets. It is 298 calculated as an exponentially weighted moving average. It is 299 calculated by an egress node for CL packets from a particular 300 ingress node. 302 ______________________________ 303 / \ 304 / \ 305 |-------| |--------| |-------| 306 |Ingress|----|Interior|----|Egress | 307 | node | | node | | node | 308 |-------| |--------| |-------| 309 \ / 310 \______________________________/ 312 < ---------- CL-region ----------- > 314 Figure 1: Sample edge-to-edge configuration and terminology 316 1.6. Structure of rest of document 318 Section 2 describes a use case, with further details in Section 3 and 319 extensions in Section 4. Section 5 discusses standardisation aspects. 321 2. Use case 323 In this section we outline a usage scenario to illustrate how our 324 mechanism works. It is intended to show how the main features fit 325 together to deliver QoS, with further details in Section 3. 327 Our QoS mechanism operates over a CL-region. For now we assume that 328 it consists of one domain whilst in Section 4.1 we extend it to the 329 multi-domain case, including where different operators run the 330 domains. So our scenario consists of two end hosts, each connected to 331 their own access networks, which are linked by the CL-region. We 332 require some other method, for instance IntServ, to be used outside 333 the CL-region to provide QoS. For now we assume that the end-to-end 334 signalling protocol is RSVP; other protocols are considered in 335 Section 3.2. From the perspective of RSVP the CL-region is a single 336 hop, so the RSVP PATH and RESV messages are processed by the ingress 337 and egress nodes but are carried transparently across all the 338 interior nodes. Hence, the ingress and egress nodes hold per 339 microflow state, whilst no state is kept by the interior nodes. 341 Section 2.1 describes a restricted scenario where the CL behaviour 342 aggregate is assigned a fixed amount of bandwidth. This is equivalent 343 to the case today with the DS architecture: a subscription-time 344 Service Level Agreement (SLA) statically defines the amount of 345 bandwidth reserved for a particular behaviour aggregate. Section 2.2 346 describes the more general case where there is no fixed allocation to 347 CL traffic. 349 Each node in the CL-region runs an algorithm to determine whether to 350 set the CE codepoint of a particular CL packet. In our description we 351 assume that a bulk token bucket is used (other implementations are 352 possible), and that tokens are added when packets are queued and are 353 consumed at a fixed rate. The idea is that an excess of tokens is 354 seen before the queue of CL packets has got long enough to cause the 355 CL packets to suffer a significant delay - the algorithms are 356 explained more fully below and are slightly different in Sections 2.1 357 and 2.2. Note that the same token bucket is used for all the CL 358 packets, ie it operates in bulk on the CL behaviour aggregate and not 359 per microflow. 361 ___ ____ _______________________________________ ____ ___ 362 | | | | | | | | | | 363 | | | | |Ingress Interior Interior Egress| | | | | 364 | | | | | node node node node | | | | | 365 | | | | |------| |------| |------| |------| | | | | 366 | | | | | CL- | | CL- | | CL- | | | | | | | 367 | |..| |..| PHB |...| PHB |...| PHB |...| Meter|..| |..| | 368 | | | | |------| |------| |------| |------| | | | | 369 | | | | | \ / | | | | | 370 | | | | | \ / | | | | | 371 | | | | | --<------------<-----------<-- | | | | | 372 | | | | | | | | | | 373 |___| |____| |_______________________________________| |____| |___| 375 Sx Access CL-region Access Rx 376 End Network Network End 377 Host Host 379 <------ edge-to-edge signalling ------> 380 (admission control) 382 <-------------------end-to-end QoS signalling protocol----------------> 384 Figure 2: Overall QoS architecture 385 2.1. Configured bandwidth allocation to the CL behaviour aggregate 387 Each node in the CL-region has a fixed rate (bandwidth) allocated to 388 CL traffic, under the control of management configuration. Tokens are 389 consumed at a fixed rate that is slightly slower than the configured 390 rate, and added when packets are queued. This means that the amount 391 of tokens starts to increase before the actual queue builds up but 392 when it is in danger of doing so soon; hence it can be used as an 393 "early warning" of potential congestion. The probability that a node 394 sets the CE codepoint of a CL packet depends on the number of tokens 395 in the bucket. Below one threshold value of the number of tokens no 396 packets have their CE codepoint set and above the second they all do; 397 in between, the probability increases linearly. 399 We now describe how setting the CE codepoint influences admission 400 control by the ingress node. For ease of description we imagine that 401 packets are already flowing. Each egress meters whether a CL packet 402 has its CE codepoint set. We assume that initially the traffic load 403 is such that there are no CE packets. 405 Next a source tries to set up a new CL microflow. The RSVP PATH 406 message is processed by the ingress and egress nodes and PATH state 407 is installed in these two routers. When the RSVP RESV message travels 408 back from the receiving end host, the egress node adds on an RSVP 409 object which states that currently no CL packets have their CE 410 codepoint set. Hence the ingress node admits the new CL microflow, 411 and the RESV message continues on to the source. 413 We imagine that this new microflow results in one (or more) of the 414 interior nodes starting to set the CE codepoint of CL packets because 415 their arrival rate is nearing the configured rate. The egress 416 calculates - as an exponentially weighted moving average - the 417 fraction of CL packets from a particular ingress node that have their 418 CE codepoint set (or rather the calculation is done according to the 419 bits in those packets). This Congestion-Level-Estimate provides an 420 estimate of how near the CL-region is getting to a load where the CL 421 traffic will start suffering significant delays. Note that the 422 metering is done separately per ingress node, because (as discussed 423 in Section 1.2) there may be sufficient capacity on all the nodes on 424 the path between one ingress node and a particular egress, but not 425 from a second ingress. 427 The next time a source tries to set up a CL microflow, the egress 428 informs the ingress node about the relevant Congestion-Level- 429 Estimate; this is included as an opaque object within the RSVP RESV 430 message. If it is greater than some threshold value then the ingress 431 refuses the request, otherwise it is accepted and the RSVP RESV 432 continues to the source end host. 434 It is also possible for an egress node to get a RSVP RESV message and 435 not know what Congestion-Level-Estimate is. For example, if there are 436 no CL microflows at present between the relevant ingress and egress 437 nodes. In this case the egress requests the ingress to send probe 438 packets, from which it can initialise its meter. 440 Having explained how the admission control decision is reached we now 441 look at an on-going data microflow. The source sends CL packets, 442 which arrive at the ingress node. The ingress uses a normal five- 443 tuple filter to identify that the packets are part of a previously 444 admitted CL microflow, and it also polices the microflow to ensure it 445 remains within its traffic profile. (The ingress has learnt the 446 required information from the RSVP PATH message.) The ingress sets 447 the DSCP appropriately and the ECN field to ECT (ECN-Capable 448 Transport). The CL packets now travel across the CL-region, with the 449 CE codepoint getting set if necessary. Also, appropriate queue 450 scheduling is needed in each node to ensure that CL traffic gets its 451 configured bandwidth. For instance, a Weighted Round Robin scheduler 452 could be used. 454 2.2. Flexible bandwidth allocation to CL behaviour aggregate 456 The set-up is similar to the previous sub-section, except that nodes 457 in the CL-region do not allocate a fixed bandwidth to CL flows. As a 458 consequence, the algorithm for setting the CE codepoint is slightly 459 altered. 461 Tokens are consumed at a fixed rate that is slightly slower than the 462 (total) outgoing service rate, and added when packets are queued. The 463 probability that a node sets the CE codepoint of a CL packet depends 464 on the number of tokens in the bucket *plus* the number of queued 465 non-CL packets. Below one threshold value of this sum no packets have 466 their CE codepoint set and above the second they all do; in between, 467 the probability increases linearly. 469 Note that the probability reflects the load of both CL and non-CL 470 traffic. The reason is to ensure a 'fair balance' between the two 471 classes, by rejecting CL session requests if non-CL demand is very 472 high. Alternatively, if the number of queued non-CL packets is not 473 included, then the admission of a CL microflow is independent of the 474 amount of non-CL traffic. 476 The admission control procedure is as in the previous sub-section. As 477 regards queue scheduling, CL packets are always scheduled ahead of 478 non-CL ones, in order to minimise their delay and jitter, and FIFO 479 (First In First Out) queuing is used to prevent reordering within a 480 CL microflow. This is more restrictive than in the previous sub- 481 section, which we believe is necessary now the arrival rate of CL 482 packets is unknown. 484 3. Details 486 In this section we first concentrate on the details about packet 487 processing in nodes in the CL-region, before looking more briefly at 488 issues associated with the signalling for admission control. 490 3.1. Packet processing 492 A network operator upgrades normal IP routers by: 494 o Adding functionality related to admission control to all its 495 ingress and egress nodes 497 o Adding appropriate queuing and scheduling behaviour to its nodes, 498 including the ability to set the CE codepoint "early". 500 We consider the detailed actions required for each of the types of 501 node in turn. 503 3.1.1. Ingress nodes 505 Ingress nodes perform the following tasks: 507 o Classify incoming packets - decide whether they are CL or non-CL 508 packets. This is done using a normal filter spec (source and 509 destination addresses and port numbers), whose details have been 510 gathered from the RSVP PATH message 512 o Police - check that the microflow is conformant with what has been 513 agreed (ie the flow keeps to its agreed data rate). If necessary, 514 the suggested action is that packets are marked to Best Effort. 516 o Packet colouring - for CL microflows, set the DSCP appropriately 517 and set the ECN field to ECT(0) or ECT(1) 519 o Perform standard 'interior node' functions (see next sub-section) 521 3.1.2. Interior nodes 523 Interior nodes do the following tasks: 525 o Examine the DSCP - to see if it's a CL packet 527 o Enqueue - CL and non-CL packets are put into logically separate 528 queues; if required, a CL packet can pre-empt non-CL packet(s) in 529 the total buffer (see below). 531 o Non-CL packets are handled as usual. A RED algorithm [RFC2309] is 532 used to decide whether to drop packets or, if they are ECN- 533 capable, set their CE codepoint. 535 o CL packets have their CE codepoint set according to what is 536 essentially a token bucket algorithm (see below). 538 o Dequeue - any CL packet is always dequeued before a non-CL packet. 539 Within the CL class scheduling is FIFO. There may be a hierarchy 540 of non-CL classes, this is out of scope. 542 Queuing: 544 Although CL and non-CL packets are put into logically separate 545 queues, implementations in practice share the same buffer space. If 546 the buffer is full then an incoming non-CL packet is dropped, whilst 547 an incoming CL packets is queued and sufficient of the newest non-CL 548 packet(s) are dropped. In the unlikely event that the buffer is full 549 of CL packets, then the newest CL packet is discarded (ie tail drop). 550 Because of the admission procedure this should be rare, but it is 551 needed to protect the network in case of misconfiguration for 552 instance. 554 Setting the CE codepoint: 556 Tokens are added when CL packets are queued and are consumed at a 557 fixed rate related to the outgoing service rate. 559 When a CL packet arrives the token bucket is updated as follows: 561 [CL-bucket-level]n+1 = [CL-bucket-level]n + CL-packet-size - 562 (service-bit-rate * time * safety-factor) 564 Where 566 CL-bucket-level is the amount of tokens in the token bucket. It is 567 constrained to lie between 0 and a fixed upper limit 569 time is the time elapsed since CL-bucket-level was last updated 571 safety-factor is > 1 and gives the "early warning" of potential 572 congestion 574 service-bit-rate is 576 either the configured bit rate for CL traffic - for the fixed 577 bandwidth case (ie Section 2.1), 579 or the outgoing service rate for all traffic - for the flexible 580 bandwidth case (ie Section 2.2). 582 CL packets have their CE codepoint set with a probability that 583 depends on the number of non-CL packets in the queue, as well as the 584 number of tokens in a token bucket. 586 When a CL packet arrives, the probability that the node sets its CE 587 codepoint is determined as follows: 589 if [CL-bucket-level]n+1 + (A * smoothed-non-CL-queue-length) < min- 590 threshold 592 Probability-CE-codepoint-set = 0 594 if [CL-bucket-level]n+1 + (A * smoothed-non-CL-queue-length) > 595 max-threshold 597 Probability-CE-codepoint-set = 1 599 otherwise 601 Probability-CE-codepoint-set = (CL-bucket-level - min-threshold) / 602 (max-threshold - min-threshold) 603 Where 605 max-threshold > min-threshold 607 max-threshold <= the fixed upper limit of CL-bucket-level 609 smoothed-non-CL-queue-length is the number of bits in packets in the 610 non-CL queue, smoothed as an exponentially weighted moving average 611 (EWMA) 613 A is either 0 or 1: 615 A = 0 for the fixed bandwidth case (ie Section 2.1), 617 A = 1 for the flexible bandwidth case (ie Section 2.2). 619 3.1.3. Egress nodes 621 Egress nodes do the following tasks: 623 o Metering - for CL packets, calculating the fraction of the total 624 bits which are in CE packets. The calculation is done as an 625 exponentially weighted moving average. A separate calculation is 626 made for CL packets from each ingress router. 628 o Packet colouring - for CL packets, set the DSCP and the ECN field 629 to whatever has been agreed as appropriate for the next domain. 631 An egress node getting a CL packet first determines which ingress 632 node that packet has come from. The necessary details are gathered 633 from the RSVP PATH message (previous RSVP hop, ie ingress node, vs. 634 filter spec). It then updates the two meters associated with that 635 ingress node. The meters work on an aggregate basis, and not per 636 microflow. 638 For every CL packet arrival: 640 [EWMA-total-bits]n+1 = (w * bits-in-packet) + ((1-w) * [EWMA- 641 total-bits]n ) 643 [EWMA-CE-bits]n+1 = (B * w * bits-in-packet) + ((1-w) * [EWMA-CE- 644 bits]n ) 646 [Congestion-Level-Estimate]n+1 = [EWMA-CE-bits]n+1 / [EWMA-total- 647 bits]n+1 649 where 651 EWMA-total-bits is the total number of bits in CL packets, calculated 652 as an exponentially weighted moving average (EWMA) 654 EWMA-CE-bits is the total number of bits in CL packets where the 655 packet has its CE codepoint set, again calculated as an EWMA. 657 B is either 0 or 1: 659 B = 0 if the CL packet does not have its CE codepoint set 661 B = 1 if the CL packet has its CE codepoint set 663 w is the exponential weighting factor. 665 Varying the value of the weight trades off between the smoothness and 666 responsiveness of the estimate of the percentage of CE packets. There 667 will be a threshold inter-arrival time between packets of the same 668 aggregate below which the egress will consider the estimate of the 669 Congestion-Level-Estimate as too stale, and it will then trigger 670 probing by the ingress. 671 For packet colouring, by default the ECN field is set to the Not-ECT 672 codepoint. Note that this results in the loss of the end-to-end 673 meaning of the ECN field. It can usually be assumed that end-to-end 674 congestion control is unnecessary within an end-to-end reservation. 675 But if a genuine need is identified for end-to-end ECN semantics 676 within a reservation, then an alternative is to tunnel CL packets 677 across the CL-region, or to agree an extension to end-to-end 678 signalling to indicate that the microflow uses an ECN-capable 679 transport. We do not recommend such apparently unnecessary 680 complexity. 682 3.2. Signalling 684 The admission control procedure involves signalling between the 685 ingress and egress nodes. The following new messages are needed:- 686 o Egress to ingress: piggy-backed on reservation reply: this is the 687 current value of Congestion-Level-Estimate. An egress node is 688 configured to know it is an egress node, so it always appends this 689 to the reservation response. A flag in this message can indicate 690 the value is unknown, in order to trigger probing by the ingress. 692 o Ingress to egress: probe: this is a probe packet 694 The description in the earlier sections has assumed that RSVP 695 signalling is used. In this case, the first bullet requires 696 standardisation so that the RSVP RESV message can carry a new opaque 697 object with the load report. 699 However, there are several other possible signalling protocols, for 700 instance using NSIS. It would therefore be sensible to ensure that 701 the new signalling messages do not constrain the choice of end-to-end 702 QoS mechanism nor how the end-to-end and edge-to-edge (ie ingress-to- 703 egress) mechanisms interact. As an example on the latter point, with 704 RSVP the PATH message is forwarded immediately to the next domain, 705 with the Congestion-Level-Estimate report only being calculated when 706 the RESV returns, at which point it can be piggy-backed on to the 707 RESV and sent to the ingress. In other cases, it may be that 708 admission control is performed before the signalling message is 709 forwarded to the next domain. 711 4. Extensions 713 4.1. Multi-domain and multi-operator usage 715 The CL-region can consist of multiple domains. Then only the ingress 716 and egress nodes of the CL-region take part in the admission control 717 procedure, ie at the ingress to the first domain and the egress from 718 the final domain. Note that domain border nodes within the CL-region 719 do not take part in signal processing or hold path state. 721 The multiple domains can even be run by different operators. The 722 border routers between operators within the CL-region only have to do 723 bulk accounting - per microflow metering and policing is not needed 724 [Briscoe]. This is possible even when the operators do not trust each 725 other. In a later version of the draft we will explain how a 726 downstream domain can police that its upstream domain does not 727 'cheat' by admitting traffic when the downstream path is over- 728 congested [Re-feedback]. 730 4.2. Variable bit rate sources 732 So far we have assumed that the real time inelastic sources operate 733 at a constant bit rate. We have determined under what conditions it 734 is possible to handle variable bit rate (VBR) sources. The simplest 735 approach is an algorithm that decides whether to set the CE codepoint 736 using a service rate much less than the real service rate (ie 737 allowing an extra safety margin); the network can still operate 738 efficiently when resources are shared between CL and non-CL flows. 739 This approach assumes that the sources are statistically independent. 741 4.3. Starvation prevention 743 According to the particular traffic levels it may sometimes be 744 possible for either the non-CL or CL traffic to be starved. An 745 algorithm to prevent starvation will be documented in a future draft. 747 5. Relationship to other QoS mechanisms 749 5.1. Standardisation requirements 751 Standardisation of two functions is needed: 753 o First, a new per hop behaviour is required (CL-ramp-PHB), which is 754 described in [CL-PHB]. The corresponding DSCP needs to be 755 RECOMMENDED rather than EXP/LU (experimental / local use), to 756 enable multi-domain operation and vendor interoperability. This 757 document is a use case of CL-ramp-PHB. 759 o Signalling between the ingress and egress nodes and its 760 interaction with the end-to-end QoS mechanism, for instance RSVP 761 or NSIS. For instance, given RSVP's capabilities to carry opaque 762 objects, define an object to carry the Congestion-Level-Estimate 763 report. Probe packets are simply data addressed to the egress 764 gateway and require no protocol standardisation, although best 765 practice is required for their number, size and rate. 767 5.2. Controlled Load 769 The CL mechanism delivers QoS similar to Integrated Services 770 controlled load, but rather better as queues are kept empty by 771 driving admission control from bulk token buckets on each interface 772 that can detect a rise in load before queues build, sometimes termed 773 a virtual queue [AVQ, vq]. It is also more robust to route changes. 775 5.3. Integrated services operation over Diffserv 777 Our approach to end-to-end QoS is similar to that described in 778 [RFC2998] for Integrated services operation over Diffserv networks. 779 Like [RFC2998], an IntServ class (CL in our case) is achieved end-to- 780 end, with a CL-region viewed as a single reservation hop in the total 781 end-to-end path. Interior routers of the CL-region do not process 782 flow signalling nor do they hold state. Unlike [RFC2998] we do not 783 require the end-to-end signalling mechanism to be RSVP, although it 784 can be. Also, we do not use the DS architecture (see Section 5.4). 786 Bearing in mind these differences, we can describe our architecture 787 in the terms of the options in [RFC2998]. The Diffserv network region 788 is RSVP-aware, but awareness is confined to (what [RFC2998] calls) 789 the "border routers" of the Diffserv region. We use explicit 790 admission control into this region, with either static provisioning 791 or explicit signalling (corresponding to the configured and flexible 792 bandwidth cases of Sections 2.1 and 2.2 respectively). The ingress 793 "border router" does per microflow policing and sets the correct DSCP 794 (ie we use router marking rather than host marking). 796 5.4. Differentiated Services 798 The DS architecture does not specify any way for devices outside the 799 domain to dynamically reserve resources or receive indications of 800 network resource availability. In practice, service providers rely 801 on subscription-time Service Level Agreements (SLAs) that statically 802 define the parameters of the traffic that will be accepted from a 803 customer. The CL mechanism allows dynamic reservation of resources 804 and unlike Diffserv it can span multiple domains without active 805 mechanisms at the borders. Therefore we do not use the traffic 806 conditioning agreements (TCAs) of the (informational) Diffserv 807 architecture [RFC2475]. 809 [Johnson] compares admission control with a 'generously dimensioned' 810 Diffserv network as ways to achieve QoS. The former is recommended. 812 5.5. ECN 814 CL complies with the ECN aspects of the IP wire protocol [RFC3168], 815 but provides its own edge-to-edge feedback instead of the TCP aspects 816 of ECN. All nodes within a particular CL-region are upgraded with the 817 CL mechanism, so the requirements of [Floyd] are met. The operator 818 prevents traffic arriving at a node that doesn't understand CL by 819 administrative configuration of the ring of gateways around the 820 region. Where a region of nodes that understand CL spans multiple 821 domains, the operators contract with each other to surround the 822 region by gateways to prevent CL traffic being handled by nodes that 823 do not understand it. 825 5.6. RTECN 827 Real-time ECN (RTECN) [RTECN, RTECN-usage] has a similar aim to this 828 document (to achieve a low delay, jitter and loss service suitable 829 for RT traffic) and a similar approach (per microflow admission 830 control combined with an "early warning" of potential congestion 831 through setting the CE codepoint). But it has a different 832 architecture: host-to-host (rather than edge-to-edge). [CL-PHB] 833 defines a new PHB, CL-step-PHB, that should be suitable; its 834 algorithm is similar to CL-ramp-PHB, but setting the CE codepoint is 835 either 'on' or 'off'. Only probe packets use the CL-step-PHB, whilst 836 data uses the Expedited Forwarding PHB [RFC3246]. 838 5.7. RMD 840 Resource Management in Diffserv (RMD) [RMD] is similar to this work, 841 in that it pushes complex classification, traffic conditioning and 842 admission control functions to the edge of a DS domain and simplifies 843 the operation of the interior nodes. One of the RMD modes uses 844 measurement-based admission control, however it works differently: 845 each interior node measures the user traffic load in the PHB traffic 846 aggregate, and each interior node processes a local RESERVE message 847 and compares the requested resources with the available resources 848 (maximum allowed load minus current load). 850 Hence a difference is that the CL architecture described in this 851 document has been designed not to require interaction between 852 interior nodes and signalling, whereas in RMD all interior nodes are 853 QoS-NSLP aware. So our architecture is more agnostic to signalling, 854 requires fewer changes to existing standards and therefore works with 855 existing RSVP as well as having the potential to work with future 856 signalling protocols like NSIS. 858 5.8. MPLS-TE 860 Multi-protocol label switching traffic engineering (MPLS-TE) allows 861 reservation of resources for an aggregate of many flows. However, it 862 still requires admission control and policing (using a bandwidth 863 manager) of microflows into the aggregate. This must be repeated at 864 each trust boundary. The present technique could be used for 865 admission control of microflows into a set of MPLS-TE aggregates. 866 They may span multiple domains without requiring per-microflow 867 processing at the trust boundaries. However it would require that the 868 MPLS header could include the ECN field. 870 6. Security Considerations 872 To protect against denial of service attacks, the ingress node of the 873 CL-region needs to police all CL packets and drop packets in excess 874 of the reservation. 876 Further security aspects to be considered later. 878 7. Acknowledgements 880 We thank Joe Babiarz for very helpful discussion about this document 881 and [RTECN]. 883 This work evolved from the Guaranteed Stream Provider developed in 884 the M3I project [GSPa, GSP-TR], which in turn was based on the 885 theoretical work of Gibbens and Kelly [DCAC]. 887 8. Comments solicited 889 Comments and questions are encouraged and very welcome. They can be 890 sent to the Transport Area Working Group's mailing list, 891 tsvwg@ietf.org, and/or to the authors (either individually or 892 collectively at gqs@jungle.bt.co.uk). 894 9. References 896 A later version will distinguish normative and informative 897 references. 899 [AVQ] S. Kunniyur and R. Srikant "Analysis and Design of an 900 Adaptive Virtual Queue (AVQ) Algorithm for Active 901 Queue Management", In: Proc. ACM SIGCOMM'01, Computer 902 Communication Review 31 (4) (October, 2001). 904 [Briscoe] Bob Briscoe and Steve Rudkin, "Commercial Models for 905 IP Quality of Service Interconnect", BT Technology 906 Journal, Vol 23 No 2, April 2005. 908 [CL-PHB] B. Briscoe, G. Corliano, P. Eardley, P. Hovell, A. 909 Jacquet, D. Songhurst, "The Controlled Load per hop 910 behaviour", draft-briscoe-tsvwg-cl-phb-00.txt (work in 911 progress), July 2005 913 [DCAC] Richard J. Gibbens and Frank P. Kelly "Distributed 914 connection acceptance control for a connectionless 915 network", In: Proc. International Teletraffic Congress 916 (ITC16), Edinburgh, pp. 941�952 (1999). 918 [Floyd] S. Floyd, 'Specifying Alternate Semantics for the 919 Explicit Congestion Notification (ECN) Field', draft- 920 floyd-ecn-alternates-00.txt (work in progress), April 921 2005 923 [GSPa] Karsten (Ed.), Martin "GSP/ECN Technology \& 924 Experiments", Deliverable: 15.3 PtIII, M3I Eu Vth 925 Framework Project IST-1999-11429, URL: 926 http://www.m3i.org/ (February, 2002) (superseded by 927 [GSP- TR]) 929 [GSP-TR] Martin Karsten and Jens Schmitt, "Admission Control 930 Based on Packet Marking and Feedback Signalling �-- 931 Mechanisms, Implementation and Experiments", TU- 932 Darmstadt Technical Report TR-KOM-2002-03, URL: 933 http://www.kom.e-technik.tu- 934 darmstadt.de/publications/abstracts/KS02-5.html (May, 935 2002) 937 [Johnson] DM Johnson, 'QoS control versus generous 938 dimensioning', BT Technology Journal, Vol 23 No 2, 939 April 2005 941 [Re-feedback] Bob Briscoe, Arnaud Jacquet, Carla Di Cairano- 942 Gilfedder, Andrea Soppera, Re-feedback for Policing 943 Congestion Response in an Inter-network, ACM SIGCOMM 944 2005, August 2005. 946 [Reid] ABD Reid, 'Economics and scalability of QoS 947 solutions', BT Technology Journal, Vol 23 No 2, April 948 2005 950 [RFC2208] F. Baker et al, "Resource ReSerVation Protocol (RSVP) 951 --- Version 1 Applicability Statement; Some Guidelines 952 on Deployment" RFC2208 (January, 1997) 954 [RFC2211] J. Wroclawski, Specification of the Controlled-Load 955 Network Element Service, September 1997 957 [RFC2309] Braden, B., et al., "Recommendations on Queue 958 Management and Congestion Avoidance in the Internet", 959 RFC 2309, April 1998. 961 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 962 "Definition of the Differentiated Services Field (DS 963 Field) in the IPv4 and IPv6 Headers", RFC 2474, 964 December 1998 966 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, 967 Z. and W. Weiss, "An Architecture for Differentiated 968 Services", RFC 2475, December 1998. 970 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, 971 "Assured Forwarding PHB Group", RFC 2597, June 1999. 973 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, 974 L., Speer, M., Braden, R., Davie, B., Wroclawski, J. 975 and E. Felstaine, "A Framework for Integrated Services 976 Operation Over DiffServ Networks", RFC 2998, November 977 2000. 979 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black "The Addition 980 of Explicit Congestion Notification (ECN) to IP", RFC 981 3168, September 2001. 983 [RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le 984 Boudec, W. Courtney, S. Davari, V. Firoiu, D. 985 Stiliadis, 'An Expedited Forwarding PHB (Per-Hop 986 Behavior)', RFC 3246, March 2002. 988 [RMD] Attila Bader, Lars Westberg, Georgios Karagiannis, 989 Cornelia Kappler, Tom Phelan, 'RMD-QOSM - The Resource 990 Management in Diffserv QoS model', draft-ietf-nsis- 991 rmd-03 Work in Progress, June 2005. 993 [RTECN] Babiarz, J., Chan, K. and V. Firoiu, 'Congestion 994 Notification Process for Real-Time Traffic', draft- 995 babiarz-tsvwg-rtecn-03" Work in Progress, February 996 2005. 998 [RTECN-usage] Alexander, C., Ed., Babiarz, J. and J. Matthews, 999 'Admission Control Use Case for Real-time ECN, draft- 1000 alexander-rtecn-admission-control-use-case-00', Work 1001 in Progress, February 2005. 1003 [vq] Costas Courcoubetis and Richard Weber "Buffer Overflow 1004 Asymptotics for a Switch Handling Many Traffic 1005 Sources" In: Journal Applied Probability 33 pp. 886-- 1006 903 (1996). 1008 Authors' Addresses 1010 Bob Briscoe 1011 BT Research 1012 B54/77, Sirius House 1013 Adastral Park 1014 Martlesham Heath 1015 Ipswich, Suffolk 1016 IP5 3RE 1017 United Kingdom 1018 Email: bob.briscoe@bt.com 1020 Dave Songhurst 1021 BT Research 1022 B54/69, Sirius House 1023 Adastral Park 1024 Martlesham Heath 1025 Ipswich, Suffolk 1026 IP5 3RE 1027 United Kingdom 1028 Email: dsonghurst@jungle.bt.co.uk 1029 Philip Eardley 1030 BT Research 1031 B54/77, Sirius House 1032 Adastral Park 1033 Martlesham Heath 1034 Ipswich, Suffolk 1035 IP5 3RE 1036 United Kingdom 1037 Email: philip.eardley@bt.com 1039 Peter Hovell 1040 BT Research 1041 B54/69, Sirius House 1042 Adastral Park 1043 Martlesham Heath 1044 Ipswich, Suffolk 1045 IP5 3RE 1046 United Kingdom 1047 Email: peter.hovell@bt.com 1049 Gabriele Corliano 1050 BT Research 1051 B54/70, Sirius House 1052 Adastral Park 1053 Martlesham Heath 1054 Ipswich, Suffolk 1055 IP5 3RE 1056 United Kingdom 1057 Email: gabriele.2.corliano@bt.com 1059 Arnaud Jacquet 1060 BT Research 1061 B54/70, Sirius House 1062 Adastral Park 1063 Martlesham Heath 1064 Ipswich, Suffolk 1065 IP5 3RE 1066 United Kingdom 1067 Email: arnaud.jacquet@bt.com 1069 Intellectual Property Statement 1071 The IETF takes no position regarding the validity or scope of any 1072 Intellectual Property Rights or other rights that might be claimed to 1073 pertain to the implementation or use of the technology described in 1074 this document or the extent to which any license under such rights 1075 might or might not be available; nor does it represent that it has 1076 made any independent effort to identify any such rights. Information 1077 on the procedures with respect to rights in RFC documents can be 1078 found in BCP 78 and BCP 79. 1080 Copies of IPR disclosures made to the IETF Secretariat and any 1081 assurances of licenses to be made available, or the result of an 1082 attempt made to obtain a general license or permission for the use of 1083 such proprietary rights by implementers or users of this 1084 specification can be obtained from the IETF on-line IPR repository at 1085 http://www.ietf.org/ipr. 1087 The IETF invites any interested party to bring to its attention any 1088 copyrights, patents or patent applications, or other proprietary 1089 rights that may cover technology that may be required to implement 1090 this standard. Please address the information to the IETF at 1091 ietf-ipr@ietf.org 1093 Disclaimer of Validity 1095 This document and the information contained herein are provided on an 1096 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1097 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1098 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1099 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1100 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1101 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1103 Copyright Statement 1105 Copyright (C) The Internet Society (2005). 1107 This document is subject to the rights, licenses and restrictions 1108 contained in BCP 78, and except as set forth therein, the authors 1109 retain all their rights.