idnits 2.17.1 draft-ietf-diffserv-pdb-ar-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 112 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 11 instances of too long lines in the document, the longest one being 7 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 135: '...uter. The filter MUST be associated wi...' RFC 2119 keyword, line 141: '... traffic profile MAY also include othe...' RFC 2119 keyword, line 142: '... parameters MAY place additional c...' RFC 2119 keyword, line 143: '...rance applies or MAY further different...' RFC 2119 keyword, line 153: '...urance applies, MUST be marked green....' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 14 has weird spacing: '...d is in full ...' == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '...ups may also ...' == Line 23 has weird spacing: '... and may be...' == Line 24 has weird spacing: '...opriate to u...' == (107 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Yellow packets SHOULD not be dropped by the ingress policer. They MAY be dropped by the buffer management mechanisms of the ingress router but that will be due to PHB treatment. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC 2597' is mentioned on line 258, but not defined == Unused Reference: 'AFPHB' is defined on line 311, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TON98' ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. 'PDBDEF' ** Downref: Normative reference to an Informational RFC: RFC 2697 (ref. 'SRTCM') ** Downref: Normative reference to an Informational RFC: RFC 2698 (ref. 'TRTCM') ** Downref: Normative reference to an Experimental RFC: RFC 2859 (ref. 'TSWTCM') Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT N. Seddigh 3 Internet Engineering Task Force B. Nandy 4 Differentiated Services Working Group Nortel Networks 5 Expires August, 2001 J. Heinanen 6 Telia Finland 7 February, 2001 9 An Assured Rate Per-Domain Behaviour for Differentiated Services 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this memo is unlimited. 35 Abstract 37 This document describes a diffserv per-domain behaviour (PDB) called 38 Assured Rate (AR). The AR PDB is suitable for carrying traffic 39 aggregates that require rate assurance but do not require delay and 40 jitter bounds. The traffic aggregate will also have the opportunity 41 to obtain excess bandwidth beyond the assured rate. The PDB can be 42 created using the diffserv AF PHB along with suitable policers at the 43 domain ingress nodes. 45 1.0 Description of the Assured Rate PDB 47 This document defines a differentiated services per-domain behaviour 48 (PDB) suitable for traffic aggregates that require rate assurance. 49 This PDB ensures that traffic conforming to a committed information 50 rate (CIR) will incur low drop probability. The aggregate will have 51 the opportunity of obtaining excess bandwidth beyond the CIR but 52 there is no assurance. In addition to the CIR, the edge rules may 53 also include other traffic parameters such as the peak information 54 rate (PIR) to place additional constraints for packets to which the 55 assurance applies or to further differentiate packets which exceed 56 the CIR. 58 This PDB is referred to as the Assured Rate (AR) PDB and is defined 59 in accordance with the guidelines in [PDBDEF]. 61 It may be possible to determine delay and jitter bounds for traffic 62 aggregates using the AR PDB. However, such parameters are beyond the 63 scope of this PDB definition and no attempt is made to characterize 64 them. Development of a mathematical model to predict delay and jitter 65 for the AR PDB is left as a subject of future research and 66 investigation. 68 The PDB tries to avoid packet reordering within microflows. The PDB 69 is applicable for a one-to-one, one-to-few as well as one-to-any 70 types of service. 72 This document uses "one-to-one" to describe a traffic aggregate 73 entering via a single ingress point of a domain and exiting from a 74 single egress point for the domain. One-to-any refers to a traffic 75 aggregate with single entry point and multiple (any) exit points in 76 the domain. One-to-few refers to a traffic aggregate with single 77 ingress point and fixed set of egress points within a domain. 79 The possibility of obtaining excess bandwidth allows development of 80 various novel SLA models. For example, excess bandwidth is charged at 81 a higher rate than assured bandwidth; excess bandwidth is cheaper 82 than assured bandwidth; excess bandwith is charged proportionally 83 etc. Development and discussion of such service and charging models 84 are beyond the scope of this document. 86 2.0 Applicability 88 The Assured Rate PDB is intended to carry traffic aggregates that 89 require assurance for a specific bandwidth level. 91 This document does not restrict the PDB to any particular application 92 or traffic type. Regardless of the traffic mix, the CIR for the 93 aggregate will be assured. 95 However, it is also possible to use this PDB to create a service for 96 an aggregate consisting only of TCP microflows or non-responsive UDP 97 microflows. The provider may wish to create a TCP-only service for a 98 variety of reasons such as traffic isolation, better treatment of 99 individual short microflows within an aggregate, greater fairness 100 among TCP and UDP microflows access to the excess bandwidth allowed 101 for the aggregate. Such service definitions are outside the scope of 102 this document. They are mentioned here simply to show that the PDB 103 can be used to create diverse services. 105 The governing attributes of the PDB are only expressed in relation to 106 the entire traffic aggregate. The PDB specification does not specify 107 any attributes for the individual microflows within an aggregate. 109 The grouping of microflows into the traffic aggregate can be done 110 either at the customer site or by the provider's ingress router on 111 behalf of the customer. The AR PDB definition can be used in either 112 scenario. It is the responsibility of the service provider to 113 specify which approach is adopted in the service level specification 114 (SLS). 116 3.0 Technical Specification 118 The specification for this PDB consist of two parts: 120 1. A set of Edge rules that classifies packets arriving at 121 the domain ingress into a traffic aggregate, 122 performs metering/policing on the aggregate and associates 123 a packet marking with the aggregate. Traffic shaping 124 does not need to be performed on the aggregate as it 125 enters the domain. 127 2. Per-node PHB treatment for the traffic aggregate 128 as it weaves its way from the domain ingress to 129 the domain egress. 131 3.1 Edge Rules 133 As packets enter the domain they will be classified into a traffic 134 aggregate based on the specified filter at the domain ingress 135 interface of the border router. The filter MUST be associated with a 136 traffic profile that specifies committed information rate (CIR) AND a 137 description on how it is to be measured. For example, the measurement 138 may be based on a committed burst size (CBS) or an averaging time 139 interval (T1). 141 The traffic profile MAY also include other traffic parameters. These 142 parameters MAY place additional constraints on packets to which the 143 assurance applies or MAY further differentiate traffic that exceeds 144 the CIR. 146 Such parameters could include: peak information rate (PIR), peak 147 burst size (PBS), excess burst size (EBS) or even a second averaging 148 time interval (T2). 150 The policer causes each packet arriving into the domain to be marked 151 with one of up to three levels of drop precedence, which we call (in 152 the increasing order) green, yellow, red. The packets to which the 153 assurance applies, MUST be marked green. The excess packets MUST be 154 marked as either yellow or red. The details of packet colouring are 155 dependent on the specific policer utilized at the ingress router. 157 Red colour packets SHOULD be delivered with equal or lower 158 probability than yellow colour packets. A special case of this is 159 that all red colour packets are discarded by the ingress policer. 161 Yellow packets SHOULD not be dropped by the ingress policer. They MAY 162 be dropped by the buffer management mechanisms of the ingress router 163 but that will be due to PHB treatment. 165 The green, yellow and red packets MUST be marked with the DSCP for 166 AFx1, AFx2 and AFx3 PHBs respectively, where x MUST be any one value 167 from 1 to N. N is the number of AF classes supported by the routers 168 in the domain. 170 The service provider may utilize any policer algorithm to colour the 171 packets as long as it adheres to the general colouring principles 172 outlined above. Examples of such policers include [SRTCM] [TRTCM] or 173 [TSWTCM]. 175 3.2 PHB Configuration 177 As described above, the AR traffic aggregate is to be treated using 178 PHBs AFx1, AFx2 and AFx3 from a single AF class x. The resultant 179 combination of the edge rules and PHB treatment within a single AF 180 class, will ensure that: 182 "Within each AF class IP packets are marked (again by the customer or 183 the provider DS domain) with one of three possible drop precedence 184 values. In case of congestion, the drop precedence of a packet 185 determines the relative importance of the packet within the AF class. 186 A congested DS node tries to protect packets with a lower drop 187 precedence value from being lost by preferably discarding packets 188 with a higher drop precedence value." (taken from RFC 2597). 190 The requirement to achieve the PDB is as follows: 192 Nodes internal to the domain SHOULD not drop packets marked to 193 receive treatment with AFx1. Under exceptional circumstances, network 194 nodes MAY have to drop AFx1 packets for a short period. In such 195 cases, they should only start dropping AFx1 packets after they have 196 started dropping all AFx2 and AFx3 packets. See [TON98] for an 197 example and justification of this approach. In the case where the AF 198 class is lightly loaded, AFx2 and/or AFx3 packets MAY also be 199 transmitted successfully through the node. This will allow the 200 aggregate to obtain excess bandwidth beyond its assured rate. 202 As mentioned previously, any of the N AF classes may be selected to 203 treat this PDB. This makes it possible to create in a single DS 204 domain, multiple instances of the AR PDB, each with their own minimum 205 forwarding resources. However, all aggregates using the same 206 instance of the PDB in a single domain SHOULD utilize the same AF 207 class PHB set. 209 4.0 Attributes of AR PDB 211 The attributes of this PDB include a rate that is assured and low 212 drop probability for the traffic conformant to this rate. 214 5.0 Parameters 216 The AR PDB MUST have the following parameters: 218 - A committed information rate (CIR) that is assured with high 219 probability. The AR PDB specification does not define "high" 220 quantitatively, but an SLS MAY do so. 222 - Traffic parameters that are needed to measure CIR. The AR PDB 223 specification does not define these parameters, since they 224 depend on the policer used. Examples include a Committed Burst Size 225 (CBS) and an averaging interval (T1). 227 - A maximum packet size for the aggregate - MAX_PACKET_SIZE. 229 In addition to the above, the AR PDB MAY have other, optional traffic 230 parameters. These parameters MAY place further constraints on the 231 packets to which the assurance applies or MAY further differentiate 232 packets to which the assurance does not apply. The PDB does not 233 define these parameters, since they depend on the policer used. 234 Examples include a Peak Information Rate (PIR), a Peak Burst Size 235 (PBS), an Excess Burst Size (EBS), and a second time averaging 236 interval (T2). 238 6.0 Assumptions 240 Deployment of the AR PDB requires an assumption that the network is 241 well-provisioned enough so that the likelyhood of green packets being 242 dropped in case of congestion is very low. This draft does not 243 dictate a particular method to achieve the above objective. Various 244 traffic engineering methods may be used. As an example, the network 245 operator monitors the level of green packets in the selected AF class 246 on all links and takes appropriate action to limit the green packet 247 loss. 249 The PDB also assumes that there is relatively stable routing within 250 the domain. 252 7.0 Security 254 There are no specific security exposures for this PDB. See the 255 general security considerations in the Diffserv Header RFC [RFC2474] 256 and the Diffserv Architecture RFC [RFC2475]. 258 All the security concerns expressed in [RFC 2597] apply for the AR 259 PDB. 261 8.0 Example Uses 263 In this section, we provide only a few example services that are 264 possible with this PDB - the list is not exhaustive. Example 265 services that can be created out of this PDB include: (i) one-to-one 266 or one-to-few VPN-like services and (ii) one-to-any general service. 268 In the case of VPN-like services, the PDB can be utilized to assure a 269 rate for a traffic aggregate between an ingress and an egress within 270 a domain or from one ingress to few different egress points in the 271 domain. 273 In the case of one-to-any services, the PDB can be utilized to assure 274 a rate for a traffic aggregate that originates from one ingress node 275 but whose individual five-tuple flows may exit the domain at any of 276 the egress nodes. 278 It is easier for a provider to demonstrate conformance with the SLS 279 in the one-to-one service since all measurements can be performed at 280 a single egress point. In the case of a one-to-any service, 281 measurements need to be performed at all egress nodes where packets 282 are sent from an ingress node during the measurement interval. These 283 measurements then have to be correlated to determine the cumulative 284 bandwidth of the aggregate as it exits the domain. 286 The AR definition allows coupling of the PDB parameters with 287 probabilities for statistical assurance. For example, the SLS MAY 288 specify a Y% assurance for the CIR (with CBS/T1) when sampled every X 289 minutes. 291 9.0 Acknowledgements 293 The authors would like to thank the following individuals for their 294 helpful comments and suggestions: Brian Carpenter, Shahram Davari and 295 Alper Demir. 297 10.0 References 299 [TON98] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort 300 Packet Delivery Service", IEEE/ACM Transactions on Networking, 301 August 1998, Vol 6. No. 4, pp. 362-373. 303 [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of 304 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 305 Headers", Internet RFC 2474, December 1998. 307 [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and 308 W. Weiss, "An Architecture for Differentiated Services", 309 Internet RFC 2475, December 1998. 311 [AFPHB] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, 312 "Assured Forwarding PHB Group", RFC 2597, June 1999 314 [PDBDEF] Nichols K and Carpenter B, "Definition of Differentiated 315 Services Per Domain Behaviours and Rules for their 316 Specification", Internet Draft, October 2000 318 [SRTCM] J. Heinanen and R. Guerin, "A Single Rate Three Colour Marker", 319 Internet RFC 2697, September 1999 321 [TRTCM] J. Heinanen and R. Guerin, "A Two Rate Three Colour Marker", 322 Internet RFC 2698, September 1999 324 [TSWTCM] W. Fang, N. Seddigh and B. Nandy, "A Time Sliding Window 325 Three Colour Marker", Internet RFC 2859, June 2000 327 9.0 Author Addresses 329 Nabil Seddigh 330 Nortel Networks, 331 3500 Carling Ave 332 Ottawa, ON, K2H 8E9 333 Canada 334 Email: nseddigh@nortelnetworks.com 336 Biswajit Nandy 337 Nortel Networks, 338 3500 Carling Ave 339 Ottawa, ON, K2H 8E9 340 Canada 341 Email: bnandy@nortelnetworks.com 343 Juha Heinanen 344 Telia Finland, 345 Email: jh@telia.fi