| < draft-ietf-diffserv-header-02.txt | draft-ietf-diffserv-header-03.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT Kathleen Nichols | INTERNET-DRAFT Kathleen Nichols | |||
| Diffserv Working Group Bay Networks | Diffserv Working Group Cisco Systems | |||
| Expires: February 1999 Steven Blake | Expires: April 1999 Steven Blake | |||
| Torrent Networking Technologies | Torrent Networking Technologies | |||
| Fred Baker | Fred Baker | |||
| Cisco Systems | Cisco Systems | |||
| David L. Black | David L. Black | |||
| The Open Group | EMC Corporation | |||
| August 1998 | October 1998 | |||
| Definition of the Differentiated Services Field (DS Field) | Definition of the Differentiated Services Field (DS Field) | |||
| in the IPv4 and IPv6 Headers | in the IPv4 and IPv6 Headers | |||
| <draft-ietf-diffserv-header-02.txt> | <draft-ietf-diffserv-header-03.txt> | |||
| Status of This Memo | Status of This Memo | |||
| This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||
| documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
| and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
| working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern | Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern | |||
| Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific | Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific | |||
| Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). | Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (1998). All Rights Reserved. | Copyright (C) The Internet Society (1998). All Rights Reserved. | |||
| Abstract | Abstract | |||
| Differentiated services enhancements to the IP protocol are intended | Differentiated services enhancements to the Internet protocol are | |||
| to enable scalable service discrimination in the Internet without the | intended to enable scalable service discrimination in the Internet | |||
| need for per-flow state and signaling at every hop. A variety of | without the need for per-flow state and signaling at every hop. A | |||
| services may be built from a small, well-defined set of building | variety of services may be built from a small, well-defined set of | |||
| blocks which are deployed in network nodes. The services may be | building blocks which are deployed in network nodes. The services | |||
| either end-to-end or intra-domain; they include both those that can | may be either end-to-end or intra-domain; they include both those | |||
| satisfy quantitative performance requirements (e.g., peak bandwidth) | that can satisfy quantitative performance requirements (e.g., peak | |||
| and those based on relative performance (e.g., "class" | bandwidth) and those based on relative performance (e.g., "class" | |||
| differentiation). Services can be constructed by a combination of: | differentiation). Services can be constructed by a combination of: | |||
| - setting bits in an IP header field at network boundaries | - setting bits in an IP header field at network boundaries | |||
| (autonomous system boundaries, internal administrative boundaries, | (autonomous system boundaries, internal administrative boundaries, | |||
| Nichols, et. al. Expires: February 1999 [Page 1] | Nichols, et. al. Expires: April 1999 [Page 1] | |||
| or hosts), | or hosts), | |||
| - using those bits to determine how packets are forwarded by the | - using those bits to determine how packets are forwarded by the | |||
| nodes inside the network, and | nodes inside the network, and | |||
| - conditioning the marked packets at network boundaries in accordance | - conditioning the marked packets at network boundaries in accordance | |||
| with the requirements or rules of each service. | with the requirements or rules of each service. | |||
| The requirements or rules of each service must be set through | The requirements or rules of each service must be set through | |||
| administrative policy mechanisms which are outside the scope of this | administrative policy mechanisms which are outside the scope of this | |||
| document. A differentiated services-compliant network node includes a | document. A differentiated services-compliant network node includes | |||
| classifier that selects packets based on the value of the DS field | a classifier that selects packets based on the value of the DS field | |||
| and is capable of delivering the specific packet forwarding treatment | and is capable of delivering the specific packet forwarding treatment | |||
| indicated by the DS field value. Setting of the DS field and | indicated by the DS field value. Setting of the DS field and | |||
| conditioning of the temporal behavior of marked packets need only be | conditioning of the temporal behavior of marked packets need only be | |||
| performed at network boundaries and may vary in complexity. | performed at network boundaries and may vary in complexity. | |||
| This document defines the IP header field, called the DS (for | This document defines the IP header field, called the DS (for | |||
| differentiated services) field. In IPv4, it defines the layout of | differentiated services) field. In IPv4, it defines the layout of | |||
| the TOS octet; in IPv6, the Traffic Class octet. In addition, a base | the TOS octet; in IPv6, the Traffic Class octet. In addition, a base | |||
| set of packet forwarding treatments, or per-hop behaviors, is | set of packet forwarding treatments, or per-hop behaviors, is | |||
| defined. | defined. | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| 4.2.2 Subsuming IP Precedence into Class Selector .......... 10 | 4.2.2 Subsuming IP Precedence into Class Selector .......... 10 | |||
| Codepoints | Codepoints | |||
| 4.2.2.1 The Class Selector Codepoints ..................... 11 | 4.2.2.1 The Class Selector Codepoints ..................... 11 | |||
| 4.2.2.2 The Class Selector PHB Requirements ............... 11 | 4.2.2.2 The Class Selector PHB Requirements ............... 11 | |||
| 4.2.2.3 Using the Class Selector PHB Requirements ......... 11 | 4.2.2.3 Using the Class Selector PHB Requirements ......... 11 | |||
| for IP Precedence Compatibility | for IP Precedence Compatibility | |||
| 4.2.2.4 Example Mechanisms for Implementing Class ......... 12 | 4.2.2.4 Example Mechanisms for Implementing Class ......... 12 | |||
| Selector Compliant PHB Groups | Selector Compliant PHB Groups | |||
| 4.3 Summary ................................................... 12 | 4.3 Summary ................................................... 12 | |||
| 5. Per-Hop Behavior Standardization Guidelines .................. 12 | 5. Per-Hop Behavior Standardization Guidelines .................. 12 | |||
| 6. IANA Considerations .......................................... 14 | 6. IANA Considerations .......................................... 13 | |||
| 7. Security Considerations ...................................... 14 | 7. Security Considerations ...................................... 14 | |||
| 7.1 Theft and Denial of Service ............................... 14 | 7.1 Theft and Denial of Service ............................... 14 | |||
| 7.2 IPsec and Tunneling Interactions .......................... 15 | 7.2 IPsec and Tunneling Interactions .......................... 15 | |||
| 8. Acknowledgments .............................................. 16 | 8. Acknowledgments .............................................. 16 | |||
| 9. References ................................................... 16 | 9. References ................................................... 16 | |||
| Appendix A. Examples of Class Selector Compliant PHB ............ 17 | Authors' Addresses ............................................... 17 | |||
| Implementations | Full Copyright Statement ......................................... 18 | |||
| A.1 Priority Queues ........................................... 17 | ||||
| Nichols, et. al. Expires: February 1999 [Page 2] | ||||
| A.2 Round Robin Queueing ...................................... 18 | ||||
| A.3 Virtual Circuit or Virtual Channel Selection .............. 18 | ||||
| A.4 Priority Buffer Management ................................ 19 | ||||
| Authors' Addresses ............................................... 19 | ||||
| Full Copyright Statement ......................................... 20 | ||||
| Nichols, et. al. Expires: April 1999 [Page 2] | ||||
| 1. Introduction | 1. Introduction | |||
| Differentiated services are intended to provide a framework and | Differentiated services are intended to provide a framework and | |||
| building blocks to enable deployment of scalable service | building blocks to enable deployment of scalable service | |||
| discrimination in the Internet. The differentiated services approach | discrimination in the Internet. The differentiated services approach | |||
| aims to speed deployment by separating the architecture into two | aims to speed deployment by separating the architecture into two | |||
| major components, one of which is fairly well-understood and the | major components, one of which is fairly well-understood and the | |||
| other of which is just beginning to be understood. In this, we are | other of which is just beginning to be understood. In this, we are | |||
| guided by the original design of the Internet where the decision was | guided by the original design of the Internet where the decision was | |||
| made to separate the forwarding and routing components. Packet | made to separate the forwarding and routing components. Packet | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| differentiated services architecture that is being addressed first. | differentiated services architecture that is being addressed first. | |||
| In addition, the forwarding path may require that some monitoring, | In addition, the forwarding path may require that some monitoring, | |||
| policing, and shaping be done on the network traffic designated for | policing, and shaping be done on the network traffic designated for | |||
| "special" treatment in order to enforce requirements associated with | "special" treatment in order to enforce requirements associated with | |||
| the delivery of the special treatment. Mechanisms for this kind of | the delivery of the special treatment. Mechanisms for this kind of | |||
| traffic conditioning are also fairly well-understood. The wide | traffic conditioning are also fairly well-understood. The wide | |||
| deployment of such traffic conditioners is also important to enable | deployment of such traffic conditioners is also important to enable | |||
| the construction of services, though their actual use in constructing | the construction of services, though their actual use in constructing | |||
| services may evolve over time. | services may evolve over time. | |||
| Nichols, et. al. Expires: February 1999 [Page 3] | ||||
| The configuration of network elements with respect to which packets | The configuration of network elements with respect to which packets | |||
| get special treatment and what kinds of rules are to be applied to | get special treatment and what kinds of rules are to be applied to | |||
| the use of resources is much less well-understood. Nevertheless, | the use of resources is much less well-understood. Nevertheless, | |||
| it is possible to deploy useful differentiated services in networks | it is possible to deploy useful differentiated services in networks | |||
| by using simple policies and static configurations. As described in | by using simple policies and static configurations. As described in | |||
| [ARCH], there are a number of ways to compose per-hop behaviors and | [ARCH], there are a number of ways to compose per-hop behaviors and | |||
| Nichols, et. al. Expires: April 1999 [Page 3] | ||||
| traffic conditioners to create services. In the process, additional | traffic conditioners to create services. In the process, additional | |||
| experience is gained that will guide more complex policies and | experience is gained that will guide more complex policies and | |||
| allocations. The basic behaviors in the forwarding path can remain | allocations. The basic behaviors in the forwarding path can remain | |||
| the same while this component of the architecture evolves. | the same while this component of the architecture evolves. | |||
| Experiences with the construction of such services will continue for | Experiences with the construction of such services will continue for | |||
| some time, thus we avoid standardizing this construction as it is | some time, thus we avoid standardizing this construction as it is | |||
| premature. Further, much of the details of service construction are | premature. Further, much of the details of service construction are | |||
| covered by legal agreements between different business entities and | covered by legal agreements between different business entities and | |||
| we avoid this as it is very much outside the scope of the IETF. | we avoid this as it is very much outside the scope of the IETF. | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| blocks for future extensibility, both of the number and type of the | blocks for future extensibility, both of the number and type of the | |||
| building blocks and of the services built from them. | building blocks and of the services built from them. | |||
| Terminology used in this draft is defined in Sec. 2. The | Terminology used in this draft is defined in Sec. 2. The | |||
| differentiated services field definition (DS field) is given in Sec. | differentiated services field definition (DS field) is given in Sec. | |||
| 3. In Sec. 4, we discuss the desire for partial backwards | 3. In Sec. 4, we discuss the desire for partial backwards | |||
| compatibility with current use of the IPv4 Precedence field. As a | compatibility with current use of the IPv4 Precedence field. As a | |||
| solution, we introduce Class Selector Codepoints and Class Selector | solution, we introduce Class Selector Codepoints and Class Selector | |||
| Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior | Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior | |||
| standardization. Sec. 6 discusses guidelines for allocation of | standardization. Sec. 6 discusses guidelines for allocation of | |||
| codepoints. Sec. 7 covers security considerations. We present | codepoints. Sec. 7 covers security considerations. | |||
| examples of Class Selector Compliant PHB implementations in the | ||||
| Appendix. | ||||
| Nichols, et. al. Expires: February 1999 [Page 4] | ||||
| This document is a concise description of the DS field and its uses. | This document is a concise description of the DS field and its uses. | |||
| It is intended to be read along with the differentiated services | It is intended to be read along with the differentiated services | |||
| architecture [ARCH]. | architecture [ARCH]. | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| Nichols, et. al. Expires: April 1999 [Page 4] | ||||
| 2. Terminology Used in This Document | 2. Terminology Used in This Document | |||
| Behavior Aggregate: a collection of packets with the same codepoint | Behavior Aggregate: a collection of packets with the same codepoint | |||
| crossing a link in a particular direction. The terms "aggregate" and | crossing a link in a particular direction. The terms "aggregate" and | |||
| "behavior aggregate" are used interchangeably in this document. | "behavior aggregate" are used interchangeably in this document. | |||
| Classifier: an entity which selects packets based on the content of | Classifier: an entity which selects packets based on the content of | |||
| packet headers according to defined rules. | packet headers according to defined rules. | |||
| Class Selector Codepoint: any of the eight codepoints in the range | Class Selector Codepoint: any of the eight codepoints in the range | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| Recommended codepoints SHOULD map to specific, standardized PHBs. | Recommended codepoints SHOULD map to specific, standardized PHBs. | |||
| Multiple codepoints MAY map to the same PHB. | Multiple codepoints MAY map to the same PHB. | |||
| Differentiated Services Boundary: the edge of a DS domain, where | Differentiated Services Boundary: the edge of a DS domain, where | |||
| classifiers and traffic conditioners are likely to be deployed. A | classifiers and traffic conditioners are likely to be deployed. A | |||
| differentiated services boundary can be further sub-divided into | differentiated services boundary can be further sub-divided into | |||
| ingress and egress nodes, where the ingress/egress nodes are the | ingress and egress nodes, where the ingress/egress nodes are the | |||
| downstream/upstream nodes of a boundary link in a given traffic | downstream/upstream nodes of a boundary link in a given traffic | |||
| direction. A differentiated services boundary typically is found at | direction. A differentiated services boundary typically is found at | |||
| the ingress to the first-hop differentiated services-compliant router | the ingress to the first-hop differentiated services-compliant router | |||
| (or network node) a host's packets traverse, or at the egress of the | (or network node) that a host's packets traverse, or at the egress of | |||
| last-hop differentiated services-compliant router or network node | the last-hop differentiated services-compliant router or network node | |||
| packets traverse before arriving at a host. This is sometimes | that packets traverse before arriving at a host. This is sometimes | |||
| referred to as the boundary at a leaf router. A differentiated | referred to as the boundary at a leaf router. A differentiated | |||
| services boundary might be co-located with a host, subject to local | services boundary may be co-located with a host, subject to local | |||
| policy. Also DS boundary. | policy. Also DS boundary. | |||
| Differentiated Services-Compliant: in compliance with the | Differentiated Services-Compliant: in compliance with the | |||
| requirements specified in this document. | requirements specified in this document. Also DS-compliant. | |||
| Differentiated Services Domain: a contiguous portion of the Internet | Differentiated Services Domain: a contiguous portion of the Internet | |||
| over which a consistent set of differentiated services policies are | over which a consistent set of differentiated services policies are | |||
| administered in a coordinated fashion. A differentiated services | administered in a coordinated fashion. A differentiated services | |||
| domain can represent different administrative domains or autonomous | domain can represent different administrative domains or autonomous | |||
| systems, different trust regions, different network technologies | systems, different trust regions, different network technologies | |||
| (e.g., cell/frame), hosts and routers, etc. Also DS domain. | (e.g., cell/frame), hosts and routers, etc. Also DS domain. | |||
| Nichols, et. al. Expires: February 1999 [Page 5] | ||||
| Differentiated Services Field: the IPv4 header TOS octet or the | Differentiated Services Field: the IPv4 header TOS octet or the | |||
| IPv6 Traffic Class octet when interpreted in conformance with the | IPv6 Traffic Class octet when interpreted in conformance with the | |||
| definition given in this document. Also DS field. | definition given in this document. Also DS field. | |||
| Mechanism: The implementation of a per-hop behavior according to a | Mechanism: The implementation of one or more per-hop behaviors | |||
| particular algorithm. | according to a particular algorithm. | |||
| Microflow: a single instance of an application-to-application flow of | Microflow: a single instance of an application-to-application flow of | |||
| Nichols, et. al. Expires: April 1999 [Page 5] | ||||
| packets which is identified by source address, destination address, | packets which is identified by source address, destination address, | |||
| protocol id, and source port, destination port (where applicable). | protocol id, and source port, destination port (where applicable). | |||
| Per-hop Behavior (PHB): a description of the externally observable | Per-hop Behavior (PHB): a description of the externally observable | |||
| forwarding treatment applied at a differentiated services-compliant | forwarding treatment applied at a differentiated services-compliant | |||
| node to a behavior aggregate. The description of a PHB SHOULD | node to a behavior aggregate. The description of a PHB SHOULD | |||
| be sufficiently detailed to allow the construction of predictable | be sufficiently detailed to allow the construction of predictable | |||
| services. | services, as documented in [ARCH]. | |||
| Per-hop Behavior Group: a set of one or more PHBs that can only be | Per-hop Behavior Group: a set of one or more PHBs that can only be | |||
| meaningfully specified and implemented simultaneously, due to a | meaningfully specified and implemented simultaneously, due to a | |||
| common constraint applying to all PHBs in the set such as a queue | common constraint applying to all PHBs in the set such as a queue | |||
| servicing or queue management policy. Also PHB Group. | servicing or queue management policy. Also PHB Group. | |||
| Traffic Conditioning: control functions that can be applied to a | Traffic Conditioning: control functions that can be applied to a | |||
| behavior aggregate, application flow, or other operationally useful | behavior aggregate, application flow, or other operationally useful | |||
| subset of traffic, e.g., routing updates. These MAY include | subset of traffic, e.g., routing updates. These MAY include | |||
| metering, policing, shaping, and packet marking. Traffic | metering, policing, shaping, and packet marking. Traffic | |||
| conditioning is used to enforce service level agreements between | conditioning is used to enforce service level agreements between | |||
| domains and to condition traffic to receive a differentiated service | domains and to condition traffic to receive a differentiated service | |||
| within a domain by marking packets with the appropriate codepoint in | within a domain by marking packets with the appropriate codepoint in | |||
| the DS field and by monitoring and altering the temporal | the DS field and by monitoring and altering the temporal | |||
| characteristics of the aggregate where necessary. | characteristics of the aggregate where necessary. See [ARCH]. | |||
| Traffic Conditioner: an entity which performs traffic conditioning | Traffic Conditioner: an entity that performs traffic conditioning | |||
| functions and which MAY contain meters, policers, shapers, and | functions and which MAY contain meters, policers, shapers, and | |||
| markers. Traffic conditioners are typically deployed in DS boundary | markers. Traffic conditioners are typically deployed in DS boundary | |||
| nodes only. | nodes (i.e., not in interior nodes of a DS domain). | |||
| Service: a description of the overall treatment of a customer's | ||||
| traffic across a particular domain, across a set of interconnected | ||||
| DS domains, or end-to-end. Service descriptions are covered by | ||||
| administrative policy and services are constructed by applying | ||||
| traffic conditioning to create behavior aggregates which experience a | ||||
| known PHB at each node within the DS domain. Multiple services can | ||||
| be supported by a single per-hop behavior used in concert with a | ||||
| range of traffic conditioners. | ||||
| To summarize, classifiers and traffic conditioners are used to | Service: a description of the overall treatment of (a subset of) a | |||
| select which packets are to be added to behavior aggregates. | customer's traffic across a particular domain, across a set of | |||
| Aggregates receive differentiated treatment in a DS domain and | interconnected DS domains, or end-to-end. Service descriptions are | |||
| traffic conditioners MAY alter the temporal characteristics of the | covered by administrative policy and services are constructed by | |||
| aggregate to conform to some requirements. A packet's DS field is | applying traffic conditioning to create behavior aggregates which | |||
| used to designate the packet's behavior aggregate and is subsequently | experience a known PHB at each node within the DS domain. Multiple | |||
| services can be supported by a single per-hop behavior used in | ||||
| concert with a range of traffic conditioners. | ||||
| Nichols, et. al. Expires: February 1999 [Page 6] | To summarize, classifiers and traffic conditioners are used to select | |||
| used to determine which forwarding treatment the packet receives. A | which packets are to be added to behavior aggregates. Aggregates | |||
| DS field classifier which can select a differential output queue | receive differentiated treatment in a DS domain and traffic | |||
| servicing discipline (or PHB) based on the codepoint in the DS field | conditioners MAY alter the temporal characteristics of the aggregate | |||
| SHOULD be included in all network nodes in a DS domain. The | to conform to some requirements. A packet's DS field is used to | |||
| classifiers and traffic conditioners at DS boundaries are configured | designate the packet's behavior aggregate and is subsequently used to | |||
| in accordance with some service specification, a matter of | determine which forwarding treatment the packet receives. A behavior | |||
| administrative policy outside the scope of this document. | aggregate classifier which can select a PHB, for example a | |||
| differential output queue servicing discipline, based on the | ||||
| codepoint in the DS field SHOULD be included in all network nodes in | ||||
| a DS domain. The classifiers and traffic conditioners at DS | ||||
| boundaries are configured in accordance with some service | ||||
| specification, a matter of administrative policy outside the scope of | ||||
| this document. | ||||
| Nichols, et. al. Expires: April 1999 [Page 6] | ||||
| Additional differentiated services definitions are given in [ARCH]. | Additional differentiated services definitions are given in [ARCH]. | |||
| 3. Differentiated Services Field Definition | 3. Differentiated Services Field Definition | |||
| A new header field, called the DS field, is defined, which is | A replacement header field, called the DS field, is defined, which is | |||
| intended to supersede the existing definitions of the IPv4 TOS octet | intended to supersede the existing definitions of the IPv4 TOS octet | |||
| [RFC791] and the IPv6 Traffic Class octet [IPv6]. | [RFC791] and the IPv6 Traffic Class octet [IPv6]. | |||
| Six bits of the DS field are used as a codepoint (DSCP) to select the | Six bits of the DS field are used as a codepoint (DSCP) to select the | |||
| PHB a packet experiences at each node. A two-bit currently unused | PHB a packet experiences at each node. A two-bit currently unused | |||
| (CU) field is reserved and may be assigned later, e.g., for explicit | (CU) field is reserved and its definition and interpretation are | |||
| congestion notification. The value of the CU bits are ignored by | outside the scope of this document. The value of the CU bits are | |||
| differentiated services-compliant nodes when determining the per-hop | ignored by differentiated services-compliant nodes when determining | |||
| behavior to apply to a received packet. | the per-hop behavior to apply to a received packet. | |||
| The DS field structure is presented below: | The DS field structure is presented below: | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +---+---+---+---+---+---+---+---+ | +---+---+---+---+---+---+---+---+ | |||
| | DSCP | CU | | | DSCP | CU | | |||
| +---+---+---+---+---+---+---+---+ | +---+---+---+---+---+---+---+---+ | |||
| DSCP: differentiated services codepoint | DSCP: differentiated services codepoint | |||
| CU: currently unused | CU: currently unused | |||
| In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1') | ||||
| used in this document, the left-most bit signifies bit 0 of the DS | ||||
| field (as shown above), and the right-most bit signifies bit 5. | ||||
| Implementors should note that the DSCP field is six bits wide. DS- | Implementors should note that the DSCP field is six bits wide. DS- | |||
| compliant nodes MUST select PHBs by matching against the entire 6- | compliant nodes MUST select PHBs by matching against the entire 6- | |||
| bit DSCP field, e.g., by treating the value of the field as a table | bit DSCP field, e.g., by treating the value of the field as a table | |||
| index which is used to select a particular packet handling mechanism | index which is used to select a particular packet handling mechanism | |||
| which has been implemented in that device. The DSCP field is defined | which has been implemented in that device. The value of the CU field | |||
| as an unstructured field to facilitate the definition of future per- | MUST be ignored by PHB selection. The DSCP field is defined as an | |||
| hop behaviors. | unstructured field to facilitate the definition of future per-hop | |||
| behaviors. | ||||
| With some exceptions noted below, the mapping of codepoints to PHBs | With some exceptions noted below, the mapping of codepoints to PHBs | |||
| MUST be configurable. A DS-compliant node MUST support the logical | MUST be configurable. A DS-compliant node MUST support the logical | |||
| equivalent of a configurable mapping table from codepoints to PHBs. | equivalent of a configurable mapping table from codepoints to PHBs. | |||
| PHB specifications MUST include a recommended default codepoint, but | PHB specifications MUST include a recommended default codepoint, | |||
| operators MAY choose to use different codepoints, either in addition | which MUST be unique for codepoints in the standard space (see Sec. | |||
| to or in place of the recommended default. Note that if operators do | 6). Implementations should support the recommended codepoint-to-PHB | |||
| so choose, re-marking of DS fields will be necessary at | mappings in their default configuration. Operators may choose to use | |||
| administrative boundaries even if the same PHBs are implemented on | different codepoints for a PHB, either in addition to or in place of | |||
| the recommended default. Note that if operators do so choose, re- | ||||
| marking of DS fields may be necessary at administrative boundaries | ||||
| even if the same PHBs are implemented on both sides of the boundary. | ||||
| Nichols, et. al. Expires: February 1999 [Page 7] | Nichols, et. al. Expires: April 1999 [Page 7] | |||
| both sides of the boundary. See [ARCH] for further discussion of re- | See [ARCH] for further discussion of re-marking. | |||
| marking. The recommended default codepoint for a PHB MUST be unique | ||||
| for codepoints in the standard space (see Sec. 6). | ||||
| The exceptions to general configurability are for codepoints 'xxx000' | The exceptions to general configurability are for codepoints 'xxx000' | |||
| and are noted in Secs. 4.2.2 and 4.3. | and are noted in Secs. 4.2.2 and 4.3. | |||
| Packets received with an unrecognized codepoint SHOULD be forwarded | Packets received with an unrecognized codepoint SHOULD be forwarded | |||
| as if they were marked for the Default behavior (see Sec. 4). Such | as if they were marked for the Default behavior (see Sec. 4), and | |||
| packets MUST NOT cause the network node to crash. | their codepoints should not be changed. Such packets MUST NOT cause | |||
| the network node to malfunction. | ||||
| The structure of the DS field shown above is incompatible with the | The structure of the DS field shown above is incompatible with the | |||
| existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The | existing definition of the IPv4 TOS octet in [RFC791]. The | |||
| presumption is that DS domains protect themselves by deploying re- | presumption is that DS domains protect themselves by deploying re- | |||
| marking boundary nodes, as should networks using the RFC 791 | marking boundary nodes, as should networks using the RFC 791 | |||
| Precedence designations. Correct operational procedure SHOULD follow | Precedence designations. Correct operational procedure SHOULD follow | |||
| [RFC791], which states: "If the actual use of these precedence | [RFC791], which states: "If the actual use of these precedence | |||
| designations is of concern to a particular network, it is the | designations is of concern to a particular network, it is the | |||
| responsibility of that network to control the access to, and use of, | responsibility of that network to control the access to, and use of, | |||
| those precedence designations." Validating the value of the DS field | those precedence designations." Validating the value of the DS field | |||
| at DS boundaries is sensible in any case since an upstream node can | at DS boundaries is sensible in any case since an upstream node can | |||
| easily set it to any random value. DS domains which are not suitably | easily set it to any random value. DS domains that are not isolated | |||
| isolated by a re-marking boundary node may deliver unpredictable | by suitably configured boundary nodes may deliver unpredictable | |||
| service. | service. | |||
| Nodes MAY rewrite the DS field as needed to provide a desired local | Nodes MAY rewrite the DS field as needed to provide a desired local | |||
| or end-to-end service. Specifications of DS field translations at | or end-to-end service. Specifications of DS field translations at | |||
| DS boundaries are the subject of service level agreements between | DS boundaries are the subject of service level agreements between | |||
| providers and users, and are outside the scope of this document. | providers and users, and are outside the scope of this document. | |||
| Standardized PHBs allow providers to build their services from a | Standardized PHBs allow providers to build their services from a | |||
| well-known set of packet forwarding treatments that can be expected | well-known set of packet forwarding treatments that can be expected | |||
| to be present in the equipment of many vendors. | to be present in the equipment of many vendors. | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| already in widespread use (e.g., those satisfying the IPv4 Precedence | already in widespread use (e.g., those satisfying the IPv4 Precedence | |||
| queueing requirements specified in [RFC1812]), and we wish to permit | queueing requirements specified in [RFC1812]), and we wish to permit | |||
| their continued use in DS-compliant nodes. In addition, there are | their continued use in DS-compliant nodes. In addition, there are | |||
| some codepoints that correspond to historical use of the IP | some codepoints that correspond to historical use of the IP | |||
| Precedence field and we reserve these codepoints to map to PHBs that | Precedence field and we reserve these codepoints to map to PHBs that | |||
| meet the general requirements specified in Sec. 4.2.2.2, though the | meet the general requirements specified in Sec. 4.2.2.2, though the | |||
| specific differentiated services PHBs mapped to by those codepoints | specific differentiated services PHBs mapped to by those codepoints | |||
| MAY have additional specifications. | MAY have additional specifications. | |||
| No attempt is made to maintain backwards compatibility with the "DTR" | No attempt is made to maintain backwards compatibility with the "DTR" | |||
| or TOS bits of the IPv4 TOS octet, as defined in [RFC791, RFC1349]. | or TOS bits of the IPv4 TOS octet, as defined in [RFC791]. | |||
| Nichols, et. al. Expires: February 1999 [Page 8] | Nichols, et. al. Expires: April 1999 [Page 8] | |||
| 4.1 A Default PHB | 4.1 A Default PHB | |||
| A "default" PHB MUST be available in a DS-compliant node. This is | A "default" PHB MUST be available in a DS-compliant node. This is | |||
| the common, best-effort forwarding behavior available in existing | the common, best-effort forwarding behavior available in existing | |||
| routers as standardized in [RFC1812]. When no other agreements are | routers as standardized in [RFC1812]. When no other agreements are | |||
| in place, it is assumed that packets belong to this aggregate. Such | in place, it is assumed that packets belong to this aggregate. Such | |||
| packets MAY be sent into a network without adhering to any particular | packets MAY be sent into a network without adhering to any particular | |||
| rules and the network will deliver as many of these packets as | rules and the network will deliver as many of these packets as | |||
| possible and as soon as possible, subject to other resource policy | possible and as soon as possible, subject to other resource policy | |||
| constraints. A reasonable implementation of this PHB would be a | constraints. A reasonable implementation of this PHB would be a | |||
| skipping to change at page 10, line ? ¶ | skipping to change at page 10, line ? ¶ | |||
| that reserves some minimal resources (e.g, buffers, bandwidth) for | that reserves some minimal resources (e.g, buffers, bandwidth) for | |||
| Default behavior aggregates. This permits senders that are not | Default behavior aggregates. This permits senders that are not | |||
| differentiated services-aware to continue to use the network in the | differentiated services-aware to continue to use the network in the | |||
| same manner as today. The impact of the introduction of | same manner as today. The impact of the introduction of | |||
| differentiated services into a domain on the service expectations of | differentiated services into a domain on the service expectations of | |||
| its customers and peers is a complex matter involving policy | its customers and peers is a complex matter involving policy | |||
| decisions by the domain and is outside the scope of this document. | decisions by the domain and is outside the scope of this document. | |||
| The RECOMMENDED codepoint for the Default PHB is the bit pattern | The RECOMMENDED codepoint for the Default PHB is the bit pattern | |||
| '000000'; the value '000000' MUST map to a PHB that meets these | '000000'; the value '000000' MUST map to a PHB that meets these | |||
| specifications. The codepoint chosen for Default behavior is | specifications. The codepoint chosen for Default behavior is | |||
| compatible with existing practice [RFC791, RFC1349]. Where a | compatible with existing practice [RFC791]. Where a codepoint is | |||
| codepoint is not mapped to a standardized or local use PHB, it SHOULD | not mapped to a standardized or local use PHB, it SHOULD be mapped to | |||
| be mapped to the Default PHB. | the Default PHB. | |||
| A "default" PHB MUST be available in a DS-compliant node. This is | ||||
| A packet initially marked for the Default behavior MAY be re-marked | A packet initially marked for the Default behavior MAY be re-marked | |||
| with another codepoint as it passes a boundary into a DS domain so | with another codepoint as it passes a boundary into a DS domain so | |||
| that it will be forwarded using a different PHB within that domain, | that it will be forwarded using a different PHB within that domain, | |||
| possibly subject to some negotiated agreement between the peering | possibly subject to some negotiated agreement between the peering | |||
| domains. | domains. | |||
| 4.2 Once and Future IP Precedence Field Use | 4.2 Once and Future IP Precedence Field Use | |||
| We wish to maintain some form of backward compatibility with present | We wish to maintain some form of backward compatibility with present | |||
| uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. | uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. | |||
| Routers exist that use the IP Precedence field to select different | Routers exist that use the IP Precedence field to select different | |||
| per-hop forwarding treatments quite similarly to the use proposed | per-hop forwarding treatments in a similar way to the use proposed | |||
| here for the DSCP field. Thus, a simple prototype differentiated | here for the DSCP field. Thus, a simple prototype differentiated | |||
| services architecture can be quickly deployed by appropriately | services architecture can be quickly deployed by appropriately | |||
| configuring these routers. Further, IP systems today understand the | configuring these routers. Further, IP systems today understand the | |||
| location of the IP Precedence field, and thus if these bits are used | location of the IP Precedence field, and thus if these bits are used | |||
| in a similar manner as DS-compliant equipment is deployed, | in a similar manner as DS-compliant equipment is deployed, | |||
| significant failures are not likely during early deployment. In | significant failures are not likely during early deployment. In | |||
| other words, strict DS-compliance need not be ubiquitous even within | other words, strict DS-compliance need not be ubiquitous even within | |||
| a single service provider's network if bits 0-2 of the DSCP field | a single service provider's network if bits 0-2 of the DSCP field | |||
| are employed in a manner similar to, or subsuming, the deployed uses | are employed in a manner similar to, or subsuming, the deployed uses | |||
| of the IP Precedence field. | of the IP Precedence field. | |||
| Nichols, et. al. Expires: February 1999 [Page 9] | Nichols, et. al. Expires: April 1999 [Page 9] | |||
| 4.2.1 IP Precedence History and Evolution in Brief | 4.2.1 IP Precedence History and Evolution in Brief | |||
| The IP Precedence field is something of a forerunner of the DS field. | The IP Precedence field is something of a forerunner of the DS field. | |||
| IP Precedence, and the IP Precedence Field, were first defined in | IP Precedence, and the IP Precedence Field, were first defined in | |||
| [RFC791]. The values that the three-bit IP Precedence Field might | [RFC791]. The values that the three-bit IP Precedence Field might | |||
| take were assigned to various uses, including network control | take were assigned to various uses, including network control | |||
| traffic, routing traffic, and various levels of privilege. The least | traffic, routing traffic, and various levels of privilege. The least | |||
| level of privilege was deemed "routine traffic". In [RFC791], the | level of privilege was deemed "routine traffic". In [RFC791], the | |||
| notion of Precedence was defined broadly as " An independent measure | notion of Precedence was defined broadly as "An independent measure | |||
| of the importance of this datagram." Not all values of the IP | of the importance of this datagram." Not all values of the IP | |||
| Precedence field were assumed to have meaning across boundaries, for | Precedence field were assumed to have meaning across boundaries, for | |||
| instance "The Network Control precedence designation is intended to | instance "The Network Control precedence designation is intended to | |||
| be used within a network only. The actual use and control of that | be used within a network only. The actual use and control of that | |||
| designation is up to each network." [RFC791] | designation is up to each network." [RFC791] | |||
| Although early BBN IMPs implemented the Precedence feature, early | Although early BBN IMPs implemented the Precedence feature, early | |||
| commercial routers and UNIX IP forwarding code generally did not. As | commercial routers and UNIX IP forwarding code generally did not. As | |||
| networks became more complex and customer requirements grew, | networks became more complex and customer requirements grew, | |||
| commercial router vendors developed ways to implement various kinds | commercial router vendors developed ways to implement various kinds | |||
| skipping to change at page 11, line 7 ¶ | skipping to change at page 11, line 7 ¶ | |||
| map to PHBs meeting these minimum requirements. The PHBs mapped to | map to PHBs meeting these minimum requirements. The PHBs mapped to | |||
| by these codepoints MAY have a more detailed list of specifications | by these codepoints MAY have a more detailed list of specifications | |||
| in addition to the required ones stated here. Other codepoints MAY | in addition to the required ones stated here. Other codepoints MAY | |||
| map to these same PHBs. We refer to this set of codepoints as the | map to these same PHBs. We refer to this set of codepoints as the | |||
| Class Selector Codepoints, and the minimum requirements for PHBs that | Class Selector Codepoints, and the minimum requirements for PHBs that | |||
| these codepoints may map to are called the Class Selector PHB | these codepoints may map to are called the Class Selector PHB | |||
| Requirements. | Requirements. | |||
| 4.2.2.1 The Class Selector Codepoints | 4.2.2.1 The Class Selector Codepoints | |||
| A specification of the packet forwarding treatments selected by the | ||||
| The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU | The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU | |||
| subfield unspecified, are reserved as a set of Class Selector | subfield unspecified, are reserved as a set of Class Selector | |||
| Codepoints. PHBs which are mapped to by these codepoints MUST | Codepoints. PHBs which are mapped to by these codepoints MUST | |||
| satisfy the Class Selector PHB requirements in addition to preserving | satisfy the Class Selector PHB requirements in addition to preserving | |||
| the Default PHB requirement on codepoint '000000' (Sec. 4.1). | the Default PHB requirement on codepoint '000000' (Sec. 4.1). | |||
| 4.2.2.2 The Class Selector PHB Requirements | 4.2.2.2 The Class Selector PHB Requirements | |||
| We refer to a Class Selector Codepoint with a larger numerical value | We refer to a Class Selector Codepoint with a larger numerical value | |||
| than another Class Selector Codepoint as having a higher relative | than another Class Selector Codepoint as having a higher relative | |||
| order while a Class Selector Codepoint with a smaller numerical value | order while a Class Selector Codepoint with a smaller numerical value | |||
| than another Class Selector Codepoint is said to have a lower | than another Class Selector Codepoint is said to have a lower | |||
| relative order. The set of PHBs mapped to by the eight Class | relative order. The set of PHBs mapped to by the eight Class | |||
| Selector Codepoints MUST yield at least two independently forwarded | Selector Codepoints MUST yield at least two independently forwarded | |||
| classes of traffic, and PHBs selected by a Class Selector Codepoint | classes of traffic, and PHBs selected by a Class Selector Codepoint | |||
| SHOULD give packets a probability of timely forwarding that is not | SHOULD give packets a probability of timely forwarding that is not | |||
| lower than that given to packets marked with a Class Selector | lower than that given to packets marked with a Class Selector | |||
| codepoint of lower relative order, assuming roughly equivalent loads | codepoint of lower relative order, under reasonable operating | |||
| for each behavior aggregate. A discarded packet is considered to be | conditions and traffic loads. A discarded packet is considered to be | |||
| an extreme case of untimely forwarding. In addition, PHBs selected | an extreme case of untimely forwarding. In addition, PHBs selected | |||
| by codepoint '11x000' MUST give packets a preferential forwarding | by codepoints '11x000' MUST give packets a preferential forwarding | |||
| treatment by comparison to the PHB selected by codepoint '000000' to | treatment by comparison to the PHB selected by codepoint '000000' to | |||
| preserve the common usage of IP Precedence values '110' and '111' for | preserve the common usage of IP Precedence values '110' and '111' for | |||
| routing traffic. | routing traffic. | |||
| Where the relative loads of two or more Class Selector behavior | ||||
| aggregates are not roughly equivalent, the relative ordering of the | ||||
| observed forwarding behaviors is dependent on details of the PHB | ||||
| specification that are not defined here. A discarded packet is | ||||
| considered to be an extreme case of untimely forwarding. | ||||
| Further, PHBs selected by distinct Class Selector Codepoints SHOULD | Further, PHBs selected by distinct Class Selector Codepoints SHOULD | |||
| be independently forwarded; that is, packets marked with different | be independently forwarded; that is, packets marked with different | |||
| Class Selector Codepoints MAY be re-ordered. A network node MAY | Class Selector Codepoints MAY be re-ordered. A network node MAY | |||
| enforce limits on the amount of the node's resources that can be | enforce limits on the amount of the node's resources that can be | |||
| utilized by each of these PHBs. | utilized by each of these PHBs. | |||
| PHB groups whose specification satisfy these requirements are | PHB groups whose specification satisfy these requirements are | |||
| referred to as Class Selector Compliant PHBs. | referred to as Class Selector Compliant PHBs. | |||
| The Class Selector PHB Requirements on codepoint '000000' are | The Class Selector PHB Requirements on codepoint '000000' are | |||
| skipping to change at page 12, line 33 ¶ | skipping to change at page 12, line 28 ¶ | |||
| recommended codepoints. A network administrator might configure | recommended codepoints. A network administrator might configure | |||
| those routers to select the Strict Priority Queueing PHBs with | those routers to select the Strict Priority Queueing PHBs with | |||
| codepoints 'xxx000' in conformance with the requirements of this | codepoints 'xxx000' in conformance with the requirements of this | |||
| document. | document. | |||
| As a further example, another vendor might employ a CBQ mechanism in | As a further example, another vendor might employ a CBQ mechanism in | |||
| its routers. The CBQ mechanism could be used to implement the Strict | its routers. The CBQ mechanism could be used to implement the Strict | |||
| Priority Queueing PHBs as well as a set of Class Selector Compliant | Priority Queueing PHBs as well as a set of Class Selector Compliant | |||
| PHBs with a wider range of features than would be available in a set | PHBs with a wider range of features than would be available in a set | |||
| of PHBs that did no more than meet the minimum Class Selector PHB | of PHBs that did no more than meet the minimum Class Selector PHB | |||
| requirements. More examples are given in the Appendix. | requirements. | |||
| 4.3 Summary | 4.3 Summary | |||
| This document defines codepoints 'xxx000' as the Class Selector | This document defines codepoints 'xxx000' as the Class Selector | |||
| codepoints, where PHBs selected by these codepoints MUST meet the | codepoints, where PHBs selected by these codepoints MUST meet the | |||
| Class Selector PHB Requirements described in Sec. 4.2.2.2. This is | Class Selector PHB Requirements described in Sec. 4.2.2.2. This is | |||
| done to preserve a useful level of backward compatibility with | done to preserve a useful level of backward compatibility with | |||
| current uses of the IP Precedence field in the Internet without | current uses of the IP Precedence field in the Internet without | |||
| unduly limiting future flexibility. In addition, codepoint '000000' | unduly limiting future flexibility. In addition, codepoint '000000' | |||
| is used as the Default PHB value for the Internet and, as such, is | is used as the Default PHB value for the Internet and, as such, is | |||
| skipping to change at page 13, line 10 ¶ | skipping to change at page 13, line 4 ¶ | |||
| The behavioral characteristics of a PHB are to be standardized, and | The behavioral characteristics of a PHB are to be standardized, and | |||
| not the particular algorithms or the mechanisms used to implement | not the particular algorithms or the mechanisms used to implement | |||
| them. A node may have a (possibly large) set of parameters that can | them. A node may have a (possibly large) set of parameters that can | |||
| be used to control how packets are scheduled onto an output interface | be used to control how packets are scheduled onto an output interface | |||
| (e.g., N separate queues with settable priorities, queue lengths, | (e.g., N separate queues with settable priorities, queue lengths, | |||
| round-robin weights, drop algorithm, drop preference weights and | round-robin weights, drop algorithm, drop preference weights and | |||
| thresholds, etc). To illustrate the distinction between a PHB and a | thresholds, etc). To illustrate the distinction between a PHB and a | |||
| mechanism, we point out that Class Selector Compliant PHBs might be | mechanism, we point out that Class Selector Compliant PHBs might be | |||
| implemented by several mechanisms, including: strict priority | implemented by several mechanisms, including: strict priority | |||
| queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in | queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in | |||
| isolation or in combination (see Appendix). | isolation or in combination. | |||
| PHBs may be specified individually, or as a group (a single PHB is a | PHBs may be specified individually, or as a group (a single PHB is a | |||
| special case of a PHB group). A PHB group usually consists of a set | special case of a PHB group). A PHB group usually consists of a set | |||
| two or more PHBs that can only be meaningfully specified and | two or more PHBs that can only be meaningfully specified and | |||
| implemented simultaneously, due to a common constraint applying to | implemented simultaneously, due to a common constraint applying to | |||
| each PHB within the group, such as a queue servicing or queue | each PHB within the group, such as a queue servicing or queue | |||
| management policy. A PHB group specification SHOULD describe | management policy. A PHB group specification SHOULD describe | |||
| conditions under which a packet might be re-marked to select another | conditions under which a packet might be re-marked to select another | |||
| PHB within the group. It is RECOMMENDED that PHB implementations do | PHB within the group. It is RECOMMENDED that PHB implementations do | |||
| not introduce any packet re-ordering within a microflow. PHB group | not introduce any packet re-ordering within a microflow. PHB group | |||
| skipping to change at page 14, line 5 ¶ | skipping to change at page 13, line 49 ¶ | |||
| or configurations to enable service differentiation within their | or configurations to enable service differentiation within their | |||
| networks, and are free to configure the node parameters in whatever | networks, and are free to configure the node parameters in whatever | |||
| way that is appropriate for their service offerings and traffic | way that is appropriate for their service offerings and traffic | |||
| engineering objectives. Over time certain common per-hop behaviors | engineering objectives. Over time certain common per-hop behaviors | |||
| are likely to evolve (i.e., ones that are particularly useful for | are likely to evolve (i.e., ones that are particularly useful for | |||
| implementing end-to-end services) and these MAY be associated with | implementing end-to-end services) and these MAY be associated with | |||
| particular EXP/LU PHB codepoints in the DS field, allowing use across | particular EXP/LU PHB codepoints in the DS field, allowing use across | |||
| domain boundaries (see Sec. 6). These PHBs are candidates for future | domain boundaries (see Sec. 6). These PHBs are candidates for future | |||
| standardization. | standardization. | |||
| It is RECOMMENDED that standardized PHBs be specified in accordance | ||||
| with the guidelines set out in [ARCH]. | ||||
| 6. IANA Considerations | 6. IANA Considerations | |||
| The DSCP field within the DS field is capable of conveying 64 | The DSCP field within the DS field is capable of conveying 64 | |||
| distinct codepoints. The codepoint space is divided into three pools | distinct codepoints. The codepoint space is divided into three pools | |||
| for the purpose of codepoint assignment and management: a pool of 32 | for the purpose of codepoint assignment and management: a pool of 32 | |||
| RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as | RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as | |||
| defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for | defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved | |||
| experimental or Local Use (EXP/LU) as defined in [CONS], and a pool | for experimental or Local Use (EXP/LU) as defined in [CONS], and a | |||
| of 16 codepoints (Pool 3) which are initially available for | pool of 16 codepoints (Pool 3) which are initially available for | |||
| experimental or local use, but which should be preferentially | experimental or local use, but which should be preferentially | |||
| utilized for standardized assignments if Pool 1 is ever exhausted. | utilized for standardized assignments if Pool 1 is ever exhausted. | |||
| The pools are defined in the following table (where 'x' refers to | The pools are defined in the following table (where 'x' refers to | |||
| either '0' or '1'): | either '0' or '1'): | |||
| Pool Codepoint space Assignment Policy | Pool Codepoint space Assignment Policy | |||
| ---- --------------- ----------------- | ---- --------------- ----------------- | |||
| 1 xxxxx0 Standards Action | 1 xxxxx0 Standards Action | |||
| 2 xxxx11 EXP/LU | 2 xxxx11 EXP/LU | |||
| skipping to change at page 14, line 43 ¶ | skipping to change at page 14, line 39 ¶ | |||
| compatibility with IP Precedence as defined in [RFC791] and as | compatibility with IP Precedence as defined in [RFC791] and as | |||
| deployed in some current equipment. | deployed in some current equipment. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| This section considers security issues raised by the introduction of | This section considers security issues raised by the introduction of | |||
| differentiated services, primarily the potential for denial-of- | differentiated services, primarily the potential for denial-of- | |||
| service attacks, and the related potential for theft of service by | service attacks, and the related potential for theft of service by | |||
| unauthorized traffic (Section 7.1). Section 7.2 addresses the | unauthorized traffic (Section 7.1). Section 7.2 addresses the | |||
| operation of differentiated services in the presence of IPsec | operation of differentiated services in the presence of IPsec | |||
| including its interaction with IPsec tunnel mode and other tunneling | including its interaction with IPsec tunnel mode and other tunnelling | |||
| protocols. More extensive treatment of the security concerns raised | protocols. See [ARCH] for more extensive treatment of the security | |||
| by the overall differentiated services architecture are discussed in | concerns raised by the overall differentiated services architecture. | |||
| [ARCH]. | ||||
| 7.1 Theft and Denial of Service | 7.1 Theft and Denial of Service | |||
| The primary goal of differentiated services is to allow different | The primary goal of differentiated services is to allow different | |||
| levels of service to be provided for traffic streams on a common | levels of service to be provided for traffic streams on a common | |||
| network infrastructure. A variety of techniques may be used to | network infrastructure. A variety of techniques may be used to | |||
| achieve this, but the end result will be that some packets receive | achieve this, but the end result will be that some packets receive | |||
| different (e.g., better) service than others. The mapping of network | different (e.g., better) service than others. The mapping of network | |||
| traffic to the specific behaviors that result in different (e.g., | traffic to the specific behaviors that result in different (e.g., | |||
| better or worse) service is indicated primarily by the DS codepoint, | better or worse) service is indicated primarily by the DS codepoint, | |||
| and hence an adversary may be able to obtain better service by | and hence an adversary may be able to obtain better service by | |||
| modifying the codepoint to values indicating behaviors used for | modifying the codepoint to values indicating behaviors used for | |||
| enhanced services or by injecting packets with such codepoint values. | enhanced services or by injecting packets with such codepoint values. | |||
| Taken to its limits, such theft of service becomes a denial-of- | Taken to its limits, such theft of service becomes a denial-of- | |||
| service attack when the modified or injected traffic depletes the | service attack when the modified or injected traffic depletes the | |||
| resources available to forward it and other traffic streams. | resources available to forward it and other traffic streams. | |||
| The defense against this class of theft- and denial-of-service | The defense against this class of theft- and denial-of-service | |||
| attacks consists of the combination of traffic conditioning at | attacks consists of the combination of traffic conditioning at DS | |||
| network boundaries with security and integrity of the network | domain boundaries with security and integrity of the network | |||
| infrastructure within a DS domain. Network boundary nodes MUST | infrastructure within a DS domain. DS domain boundary nodes MUST | |||
| ensure that all traffic entering the domain is marked with codepoint | ensure that all traffic entering the domain is marked with codepoint | |||
| values appropriate to the traffic and the domain, remarking the | values appropriate to the traffic and the domain, remarking the | |||
| traffic with new codepoint values if necessary. These DS boundary | traffic with new codepoint values if necessary. These DS boundary | |||
| nodes are the primary line of defense against theft- and denial-of- | nodes are the primary line of defense against theft- and denial-of- | |||
| service attacks based on modified codepoints, as success of any such | service attacks based on modified codepoints, as success of any such | |||
| attack indicates that the codepoints used by the attacking traffic | attack indicates that the codepoints used by the attacking traffic | |||
| were inappropriate. An important instance of a boundary node is that | were inappropriate. An important instance of a boundary node is that | |||
| any traffic-originating node within a DS domain is the initial | any traffic-originating node within a DS domain is the initial | |||
| boundary node for that traffic. Interior nodes in a DS domain rely | boundary node for that traffic. Interior nodes in a DS domain rely | |||
| on DS codepoints to associate traffic with the forwarding PHBs, and | on DS codepoints to associate traffic with the forwarding PHBs, and | |||
| are not required to check codepoint values before using them. As a | are NOT REQUIRED to check codepoint values before using them. As a | |||
| result, the interior nodes depend on the correct operation of the DS | result, the interior nodes depend on the correct operation of the DS | |||
| domain to prevent the arrival of traffic with inappropriate | domain boundary nodes to prevent the arrival of traffic with | |||
| codepoints that would disrupt operation of the domain. | inappropriate codepoints or in excess of provisioned levels that | |||
| would disrupt operation of the domain. | ||||
| 7.2 IPsec and Tunnelling Interactions | 7.2 IPsec and Tunnelling Interactions | |||
| The IPsec protocol, as defined in [ESP, AH], does not include the IP | The IPsec protocol, as defined in [ESP, AH], does not include the IP | |||
| header's DS field in any of its cryptographic calculations (in the | header's DS field in any of its cryptographic calculations (in the | |||
| case of tunnel mode, it is the outer IP header's DS field that is not | case of tunnel mode, it is the outer IP header's DS field that is not | |||
| included). Hence modification of the DS field by a network node has | included). Hence modification of the DS field by a network node has | |||
| no effect on IPsec's end-to-end security, because it cannot cause any | no effect on IPsec's end-to-end security, because it cannot cause any | |||
| IPsec integrity check to fail. As a consequence, IPsec does not | IPsec integrity check to fail. As a consequence, IPsec does not | |||
| provide any defense against an adversary's modification of the DS | provide any defense against an adversary's modification of the DS | |||
| skipping to change at page 16, line 21 ¶ | skipping to change at page 16, line 18 ¶ | |||
| exiting the tunnel, and hence MUST ensure that the resulting traffic | exiting the tunnel, and hence MUST ensure that the resulting traffic | |||
| has appropriate DS codepoints. | has appropriate DS codepoints. | |||
| When IPsec tunnel egress decapsulation processing includes a | When IPsec tunnel egress decapsulation processing includes a | |||
| sufficiently strong cryptographic integrity check of the encapsulated | sufficiently strong cryptographic integrity check of the encapsulated | |||
| packet (where sufficiency is determined by local security policy), | packet (where sufficiency is determined by local security policy), | |||
| the tunnel egress node can safely assume that the DS field in the | the tunnel egress node can safely assume that the DS field in the | |||
| inner header has the same value as it had at the tunnel ingress node. | inner header has the same value as it had at the tunnel ingress node. | |||
| An important consequence is that otherwise insecure links within a DS | An important consequence is that otherwise insecure links within a DS | |||
| domain can be secured by a sufficiently strong IPsec tunnel. This | domain can be secured by a sufficiently strong IPsec tunnel. This | |||
| analysis and its implications apply to any tunneling protocol that | analysis and its implications apply to any tunnelling protocol that | |||
| performs integrity checks, but the level of assurance of the inner | performs integrity checks, but the level of assurance of the inner | |||
| header's DS field depends on the strength of the integrity check | header's DS field depends on the strength of the integrity check | |||
| performed by the tunneling protocol. In the absence of sufficient | performed by the tunnelling protocol. In the absence of sufficient | |||
| assurance for a tunnel that may transit nodes outside the current DS | assurance for a tunnel that may transit nodes outside the current DS | |||
| domain (or is otherwise vulnerable), the encapsulated packet MUST be | domain (or is otherwise vulnerable), the encapsulated packet MUST be | |||
| treated as if it had arrived at a boundary from outside the DS | treated as if it had arrived at a boundary from outside the DS | |||
| domain. | domain. | |||
| 8. Acknowledgements | 8. Acknowledgements | |||
| The authors would like to acknowledge the Differentiated Services | The authors would like to acknowledge the Differentiated Services | |||
| Working Group for discussions which helped shape this document. | Working Group for discussions which helped shape this document. | |||
| 9. References | 9. References | |||
| [AH] S. Kent and R. Atkinson, "IP Authentication Header", | [AH] S. Kent and R. Atkinson, "IP Authentication Header", | |||
| Internet Draft <draft-ietf-ipsec-auth-header-07.txt>, | Internet Draft <draft-ietf-ipsec-auth-header-07.txt>, | |||
| July 1998. | July 1998. | |||
| [ARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and | [ARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and | |||
| W. Weiss, "An Architecture for Differentiated Services", | W. Weiss, "An Architecture for Differentiated Services", | |||
| Internet Draft <draft-ietf-diffserv-arch-01.txt>, | Internet Draft <draft-ietf-diffserv-arch-02.txt>, | |||
| August 1998. | October 1998. | |||
| [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource | [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource | |||
| Management Models for Packet Networks", IEEE/ACM | Management Models for Packet Networks", IEEE/ACM | |||
| Transactions on Networking, Vol. 3 no. 4, pp. 365-386, | Transactions on Networking, Vol. 3 no. 4, pp. 365-386, | |||
| August 1995. | August 1995. | |||
| [CLARK] D. Clark and W. Fang, "Explicit Allocation of Best | ||||
| Effort Packet Delivery Service", | ||||
| http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf | ||||
| [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an | [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", Internet Draft | IANA Considerations Section in RFCs", Internet Draft | |||
| <draft-iesg-iana-considerations-04.txt>, May 1998. | <draft-iesg-iana-considerations-06.txt>, September 1998. | |||
| [DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing | [DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing | |||
| using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995. | using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995. | |||
| [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security | [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security | |||
| Payload (ESP)", Internet Draft | Payload (ESP)", Internet Draft | |||
| <draft-ietf-ipsec-esp-v2-06.txt>, July 1998. | <draft-ietf-ipsec-esp-v2-06.txt>, July 1998. | |||
| [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair | [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair | |||
| Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. | Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. | |||
| skipping to change at page 17, line 29 ¶ | skipping to change at page 17, line 22 ¶ | |||
| [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 | [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", Internet Draft | (IPv6) Specification", Internet Draft | |||
| <draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997. | <draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997. | |||
| [RFC791] Information Sciences Institute, "Internet Protocol", | [RFC791] Information Sciences Institute, "Internet Protocol", | |||
| Internet RFC 791, September 1981. | Internet RFC 791, September 1981. | |||
| [RFC1122] R. T. Braden, "Requirements for Internet hosts - | [RFC1122] R. T. Braden, "Requirements for Internet hosts - | |||
| communication layers", Internet RFC 1122, October 1989. | communication layers", Internet RFC 1122, October 1989. | |||
| [RFC1349] P. Almquist, "Type of Service in the Internet Protocol | ||||
| Suite", Internet RFC 1349, July 1992. | ||||
| [RFC1812] F. Baker, editor, "Requirements for IP Version 4 | [RFC1812] F. Baker, editor, "Requirements for IP Version 4 | |||
| Routers", Internet RFC 1812, June 1995. | Routers", Internet RFC 1812, June 1995. | |||
| [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate | [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate | |||
| Requirement Levels", Internet RFC 2119, March 1997. | Requirement Levels", Internet RFC 2119, March 1997. | |||
| [RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: | [RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: | |||
| A Design Methodology for Fair Queueing Algorithms", IEEE/ | A Design Methodology for Fair Queueing Algorithms", IEEE/ | |||
| ACM Trans. on Networking, April 1998. | ACM Trans. on Networking, April 1998. | |||
| Appendix. Examples of Class Selector Compliant PHB Implementations | ||||
| This appendix shows how four different mechanisms can be used to | ||||
| implement Class Selector Compliant PHBs. | ||||
| A.1 Priority Queues | ||||
| This approach employs eight queues where each of the eight codepoints | ||||
| maps to a different queue. Queues are serviced in priority order so | ||||
| that each queue, from the perspective of the next lower priority | ||||
| queue, implements a "low loss, low delay" forwarding behavior. As an | ||||
| alternative, one can employ four queues, where bits 0 and 1 of the | ||||
| codepoint are used to select the queue. Bit 2 of the codepoint is | ||||
| used as a drop preference within the queue. RED is used within the | ||||
| queues according to its usual parameters, but with in-profile traffic | ||||
| having a higher min-threshold and max-threshold than out-of-profile | ||||
| traffic, and therefore experiencing a higher probability of timely | ||||
| delivery [CLARK]. Out-of-profile traffic should consider the | ||||
| presence of lower order in-profile traffic in the calculation of drop | ||||
| probability. | ||||
| The strength of this second approach is that packet order is | ||||
| maintained within each precedence queue, but higher ordered traffic | ||||
| may be sent before lower ordered traffic (since lower ordered traffic | ||||
| within a queue may be dropped). It has a weakness, however, in that | ||||
| apart from admission control and policing, it affords lower | ||||
| precedence traffic no assurance of eventual transmission. | ||||
| A.2 Weighted Link-Share Queueing | ||||
| Like the previous example, this approach employs a queue per | ||||
| codepoint, but each queue is emptied at some non-zero rate, in round- | ||||
| robin order by means of some appropriate algorithm [HPFQA, RPS, DRR], | ||||
| rather than being given simple priority service. | ||||
| The strength of this approach is that higher ordered traffic is, on | ||||
| average, queued for a shorter duration than lower ordered traffic, | ||||
| assuming roughly equivalent relative loads for each order. It also | ||||
| avoids the lockout issue that priority queuing systems may | ||||
| experience. A counter-intuitive scenario can occur, however, if a | ||||
| high rate queue is heavily utilized while a lower rate queue is | ||||
| under-utilized; a packet directed to the lower rate queue can | ||||
| actually be better protected from loss and variation in delay when | ||||
| placed in an empty or very short queue. | ||||
| A.3 Virtual Circuit or Virtual Channel Selection | ||||
| The difference between this approach and Weighted Link-Share Queuing | ||||
| is somewhat academic. If one has a serial line to a routing | ||||
| neighbor, and manages the link using a link sharing algorithm, the | ||||
| link sharing algorithm in some sense emulates the way the line would | ||||
| behave if it were in reality a number of different lines, or if it | ||||
| were one channelized line. In a virtual circuit selection model, the | ||||
| emulation becomes reality - one deploys a set of rate-limited VCs to | ||||
| a routing neighbor, and uses them in the same way one would otherwise | ||||
| have used round-robin queues. | ||||
| The strengths and weaknesses are very similar to those of Weighted | ||||
| Link-Share Queuing, except that this allows one to capitalize on the | ||||
| capabilities of a link layer such as ATM or Frame Relay. | ||||
| A.4 Priority Buffer Management | ||||
| This approach assigns buffer occupancy thresholds for each codepoint, | ||||
| with the threshold for a higher ordered codepoint being no lower than | ||||
| the threshold for a lower ordered codepoint. Under link congestion, | ||||
| packets marked with a lower ordered codepoint are discard before | ||||
| those packets marked with a higher ordered codepoint. The | ||||
| thresholding mechanism might be deterministic, or based on average | ||||
| queue occupancies and statistical discard probability weighting | ||||
| functions [CLARK]. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Kathleen Nichols | Kathleen Nichols | |||
| Bay Networks Architecture Lab | Cisco Systems | |||
| 4401 Great America Parkway | 170 West Tasman Drive | |||
| SC01-04 | San Jose, CA 95134-1706 | |||
| Santa Clara, CA 95052-8185 | Phone: +1-408-525-4857 | |||
| Phone: +1-408-495-3252 | E-mail: kmn@cisco.com | |||
| Fax: +1-408-495-1299 | ||||
| E-mail: knichols@baynetworks.com | ||||
| Steven Blake | Steven Blake | |||
| Torrent Networking Technologies | Torrent Networking Technologies | |||
| 2221 Broadbirch Drive | 3000 Aerial Center, Suite 140 | |||
| Silver Spring, MD 20904 | Morrisville, NC 27560 | |||
| Phone: +1-301-625-1600 | Phone: +1-919-468-8466 x232 | |||
| E-mail: slblake@torrentnet.com | E-mail: slblake@torrentnet.com | |||
| Fred Baker | Fred Baker | |||
| Cisco Systems | Cisco Systems | |||
| 519 Lado Drive | 519 Lado Drive | |||
| Santa Barbara, California 93111 | Santa Barbara, CA 93111 | |||
| Phone: +1-408-526-4257 | Phone: +1-408-526-4257 | |||
| E-mail: fred@cisco.com | E-mail: fred@cisco.com | |||
| David L. Black | David L. Black | |||
| The Open Group | EMC Corporation | |||
| 11 Cambridge Center | 35 Parkwood Drive | |||
| Cambridge, MA 02142 | Hopkinton, MA 01748 | |||
| Phone: +1-617-621-7347 | Phone: +1-508-435-1000 x76140 | |||
| E-mail: d.black@opengroup.org | E-mail: black_david@emc.com | |||
| Full Copyright Statement | Full Copyright Statement | |||
| Copyright (C) The Internet Society (1998). All Rights Reserved. | Copyright (C) The Internet Society (1998). All Rights Reserved. | |||
| This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
| others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
| or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
| and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
| kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||
| End of changes. 68 change blocks. | ||||
| 224 lines changed or deleted | 139 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||