RFC2474 日本語訳
2474 Definition of the Differentiated Services Field (DS Field) in theIPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349) (Updated by RFC3168, RFC3260) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Nichols
Request for Comments: 2474 Cisco Systems
Obsoletes: 1455, 1349 S. Blake
Category: Standards Track Torrent Networking Technologies
F. Baker
Cisco Systems
D. Black
EMC Corporation
December 1998
Network Working Group K. Nichols Request for Comments: 2474 Cisco Systems Obsoletes: 1455, 1349 S. Blake Category: Standards Track Torrent Networking Technologies F. Baker Cisco Systems D. Black EMC Corporation December 1998
Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
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 Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:
Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:
- setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries,
or hosts),
- using those bits to determine how packets are forwarded by the
nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
- setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), - using those bits to determine how packets are forwarded by the nodes inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.
Nichols, et. al. Standards Track [Page 1] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 1] RFC 2474 Differentiated Services Field December 1998
The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.
The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.
For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].
For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].
Table of Contents
Table of Contents
1. Introduction ................................................. 3
2. Terminology Used in This Document ............................ 5
3. Differentiated Services Field Definition ..................... 7
4. Historical Codepoint Definitions and PHB Requirements ........ 9
4.1 A Default PHB ............................................. 9
4.2 Once and Future IP Precedence Field Use ................... 10
4.2.1 IP Precedence History and Evolution in Brief .......... 10
4.2.2 Subsuming IP Precedence into Class Selector .......... 11
Codepoints
4.2.2.1 The Class Selector Codepoints ..................... 11
4.2.2.2 The Class Selector PHB Requirements ............... 11
4.2.2.3 Using the Class Selector PHB Requirements ......... 12
for IP Precedence Compatibility
4.2.2.4 Example Mechanisms for Implementing Class ......... 12
Selector Compliant PHB Groups
4.3 Summary ................................................... 13
5. Per-Hop Behavior Standardization Guidelines .................. 13
6. IANA Considerations .......................................... 14
7. Security Considerations ...................................... 15
7.1 Theft and Denial of Service ............................... 15
7.2 IPsec and Tunneling Interactions .......................... 16
8. Acknowledgments .............................................. 17
9. References ................................................... 17
Authors' Addresses ............................................... 19
Full Copyright Statement ......................................... 20
1. Introduction ................................................. 3 2. Terminology Used in This Document ............................ 5 3. Differentiated Services Field Definition ..................... 7 4. Historical Codepoint Definitions and PHB Requirements ........ 9 4.1 A Default PHB ............................................. 9 4.2 Once and Future IP Precedence Field Use ................... 10 4.2.1 IP Precedence History and Evolution in Brief .......... 10 4.2.2 Subsuming IP Precedence into Class Selector .......... 11 Codepoints 4.2.2.1 The Class Selector Codepoints ..................... 11 4.2.2.2 The Class Selector PHB Requirements ............... 11 4.2.2.3 Using the Class Selector PHB Requirements ......... 12 for IP Precedence Compatibility 4.2.2.4 Example Mechanisms for Implementing Class ......... 12 Selector Compliant PHB Groups 4.3 Summary ................................................... 13 5. Per-Hop Behavior Standardization Guidelines .................. 13 6. IANA Considerations .......................................... 14 7. Security Considerations ...................................... 15 7.1 Theft and Denial of Service ............................... 15 7.2 IPsec and Tunneling Interactions .......................... 16 8. Acknowledgments .............................................. 17 9. References ................................................... 17 Authors' Addresses ............................................... 19 Full Copyright Statement ......................................... 20
Nichols, et. al. Standards Track [Page 2] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 2] RFC 2474 Differentiated Services Field December 1998
1. Introduction
1. Introduction
Differentiated services are intended to provide a framework and building blocks to enable deployment of scalable service discrimination in the Internet. The differentiated services approach aims to speed deployment by separating the architecture into two major components, one of which is fairly well-understood and the 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 made to separate the forwarding and routing components. Packet forwarding is the relatively simple task that needs to be performed on a per-packet basis as quickly as possible. Forwarding uses the packet header to find an entry in a routing table that determines the packet's output interface. Routing sets the entries in that table and may need to reflect a range of transit and other policies as well as to keep track of route failures. Routing tables are maintained as a background process to the forwarding task. Further, routing is the more complex task and it has continued to evolve over the past 20 years.
Differentiated services are intended to provide a framework and building blocks to enable deployment of scalable service discrimination in the Internet. The differentiated services approach aims to speed deployment by separating the architecture into two major components, one of which is fairly well-understood and the 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 made to separate the forwarding and routing components. Packet forwarding is the relatively simple task that needs to be performed on a per-packet basis as quickly as possible. Forwarding uses the packet header to find an entry in a routing table that determines the packet's output interface. Routing sets the entries in that table and may need to reflect a range of transit and other policies as well as to keep track of route failures. Routing tables are maintained as a background process to the forwarding task. Further, routing is the more complex task and it has continued to evolve over the past 20 years.
Analogously, the differentiated services architecture contains two main components. One is the fairly well-understood behavior in the forwarding path and the other is the more complex and still emerging background policy and allocation component that configures parameters used in the forwarding path. The forwarding path behaviors include the differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines. These per-hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets no matter how we construct end-to-end or intra-domain services. Our focus is on the general semantics of the behaviors rather than the specific mechanisms used to implement them since these behaviors will evolve less rapidly than the mechanisms.
Analogously, the differentiated services architecture contains two main components. One is the fairly well-understood behavior in the forwarding path and the other is the more complex and still emerging background policy and allocation component that configures parameters used in the forwarding path. The forwarding path behaviors include the differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines. These per-hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets no matter how we construct end-to-end or intra-domain services. Our focus is on the general semantics of the behaviors rather than the specific mechanisms used to implement them since these behaviors will evolve less rapidly than the mechanisms.
Per-hop behaviors and mechanisms to select them on a per-packet basis can be deployed in network nodes today and it is this aspect of the differentiated services architecture that is being addressed first. In addition, the forwarding path may require that some monitoring, policing, and shaping be done on the network traffic designated for "special" treatment in order to enforce requirements associated with the delivery of the special treatment. Mechanisms for this kind of traffic conditioning are also fairly well-understood. The wide deployment of such traffic conditioners is also important to enable the construction of services, though their actual use in constructing services may evolve over time.
Per-hop behaviors and mechanisms to select them on a per-packet basis can be deployed in network nodes today and it is this aspect of the differentiated services architecture that is being addressed first. In addition, the forwarding path may require that some monitoring, policing, and shaping be done on the network traffic designated for "special" treatment in order to enforce requirements associated with the delivery of the special treatment. Mechanisms for this kind of traffic conditioning are also fairly well-understood. The wide deployment of such traffic conditioners is also important to enable the construction of services, though their actual use in constructing services may evolve over time.
Nichols, et. al. Standards Track [Page 3] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 3] RFC 2474 Differentiated Services Field December 1998
The configuration of network elements with respect to which packets get special treatment and what kinds of rules are to be applied to the use of resources is much less well-understood. Nevertheless, it is possible to deploy useful differentiated services in networks by using simple policies and static configurations. As described in [ARCH], there are a number of ways to compose per-hop behaviors and traffic conditioners to create services. In the process, additional experience is gained that will guide more complex policies and allocations. The basic behaviors in the forwarding path can remain the same while this component of the architecture evolves. Experiences with the construction of such services will continue for some time, thus we avoid standardizing this construction as it is premature. Further, much of the details of service construction are covered by legal agreements between different business entities and we avoid this as it is very much outside the scope of the IETF.
The configuration of network elements with respect to which packets get special treatment and what kinds of rules are to be applied to the use of resources is much less well-understood. Nevertheless, it is possible to deploy useful differentiated services in networks by using simple policies and static configurations. As described in [ARCH], there are a number of ways to compose per-hop behaviors and traffic conditioners to create services. In the process, additional experience is gained that will guide more complex policies and allocations. The basic behaviors in the forwarding path can remain the same while this component of the architecture evolves. Experiences with the construction of such services will continue for some time, thus we avoid standardizing this construction as it is premature. Further, much of the details of service construction are covered by legal agreements between different business entities and we avoid this as it is very much outside the scope of the IETF.
This document concentrates on the forwarding path component. In the packet forwarding path, differentiated services are realized by mapping the codepoint contained in a field in the IP packet header to a particular forwarding treatment, or per-hop behavior (PHB), at each network node along its path. The codepoints may be chosen from a set of mandatory values defined later in this document, from a set of recommended values to be defined in future documents, or may have purely local meaning. PHBs are expected to be implemented by employing a range of queue service and/or queue management disciplines on a network node's output interface queue: for example weighted round-robin (WRR) queue servicing or drop-preference queue management.
This document concentrates on the forwarding path component. In the packet forwarding path, differentiated services are realized by mapping the codepoint contained in a field in the IP packet header to a particular forwarding treatment, or per-hop behavior (PHB), at each network node along its path. The codepoints may be chosen from a set of mandatory values defined later in this document, from a set of recommended values to be defined in future documents, or may have purely local meaning. PHBs are expected to be implemented by employing a range of queue service and/or queue management disciplines on a network node's output interface queue: for example weighted round-robin (WRR) queue servicing or drop-preference queue management.
Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first-hop router or source host) and administrative boundaries. Traffic conditioners may include the primitives of marking, metering, policing and shaping (these mechanisms are described in [ARCH]). Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them.
Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first-hop router or source host) and administrative boundaries. Traffic conditioners may include the primitives of marking, metering, policing and shaping (these mechanisms are described in [ARCH]). Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them.
Terminology used in this memo is defined in Sec. 2. The differentiated services field definition (DS field) is given in Sec. 3. In Sec. 4, we discuss the desire for partial backwards compatibility with current use of the IPv4 Precedence field. As a solution, we introduce Class Selector Codepoints and Class Selector
Terminology used in this memo is defined in Sec. 2. The differentiated services field definition (DS field) is given in Sec. 3. In Sec. 4, we discuss the desire for partial backwards compatibility with current use of the IPv4 Precedence field. As a solution, we introduce Class Selector Codepoints and Class Selector
Nichols, et. al. Standards Track [Page 4] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 4] RFC 2474 Differentiated Services Field December 1998
Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior standardization. Sec. 6 discusses guidelines for allocation of codepoints. Sec. 7 covers security considerations.
Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior standardization. Sec. 6 discusses guidelines for allocation of codepoints. Sec. 7 covers security considerations.
This document is a concise description of the DS field and its uses. It is intended to be read along with the differentiated services architecture [ARCH].
This document is a concise description of the DS field and its uses. It is intended to be read along with the differentiated services architecture [ARCH].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Terminology Used in This Document
2. Terminology Used in This Document
Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document.
Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document.
Classifier: an entity which selects packets based on the content of packet headers according to defined rules.
Classifier: an entity which selects packets based on the content of packet headers according to defined rules.
Class Selector Codepoint: any of the eight codepoints in the range ' xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints are discussed in Sec. 4.2.2.
Class Selector Codepoint: any of the eight codepoints in the range ' xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints are discussed in Sec. 4.2.2.
Class Selector Compliant PHB: a per-hop behavior satisfying the Class Selector PHB Requirements specified in Sec. 4.2.2.2.
Class Selector Compliant PHB: a per-hop behavior satisfying the Class Selector PHB Requirements specified in Sec. 4.2.2.2.
Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. Multiple codepoints MAY map to the same PHB.
Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. Multiple codepoints MAY map to the same PHB.
Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary.
Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary.
Differentiated Services-Compliant: in compliance with the requirements specified in this document. Also DS-compliant.
Differentiated Services-Compliant: in compliance with the requirements specified in this document. Also DS-compliant.
Nichols, et. al. Standards Track [Page 5] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 5] RFC 2474 Differentiated Services Field December 1998
Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain.
Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain.
Differentiated Services Field: the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in this document. Also DS field.
Differentiated Services Field: the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in this document. Also DS field.
Mechanism: The implementation of one or more per-hop behaviors according to a particular algorithm.
Mechanism: The implementation of one or more per-hop behaviors according to a particular algorithm.
Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable).
Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable).
Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate. The description of a PHB SHOULD be sufficiently detailed to allow the construction of predictable services, as documented in [ARCH].
Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate. The description of a PHB SHOULD be sufficiently detailed to allow the construction of predictable services, as documented in [ARCH].
Per-hop Behavior Group: a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. Also PHB Group.
Per-hop Behavior Group: a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. Also PHB Group.
Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between domains and to condition traffic to receive a differentiated service within a domain by marking packets with the appropriate codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where necessary. See [ARCH].
Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between domains and to condition traffic to receive a differentiated service within a domain by marking packets with the appropriate codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where necessary. See [ARCH].
Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain).
Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain).
Service: a description of the overall treatment of (a subset 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
Service: a description of the overall treatment of (a subset 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
Nichols, et. al. Standards Track [Page 6] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 6] RFC 2474 Differentiated Services Field December 1998
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.
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 select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives. A behavior 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.
To summarize, classifiers and traffic conditioners are used to select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives. A behavior 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.
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 replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6].
A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6].
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 (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet.
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 (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining 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
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint
CU: currently unused
DSCP: differentiated services codepoint CU: currently unused
Nichols, et. al. Standards Track [Page 7] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 7] RFC 2474 Differentiated Services Field December 1998
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.
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- 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 index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors.
Implementors should note that the DSCP field is six bits wide. DS- 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 index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors.
With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use 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.
With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use 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.
See [ARCH] for further discussion of re-marking.
See [ARCH] for further discussion of re-marking.
The exceptions to general configurability are for codepoints 'xxx000' and are noted in Secs. 4.2.2 and 4.3.
The exceptions to general configurability are for codepoints 'xxx000' and are noted in Secs. 4.2.2 and 4.3.
Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction.
Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and 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 existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service.
The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service.
Nichols, et. al. Standards Track [Page 8] RFC 2474 Differentiated Services Field December 1998
Nichols, et. al. Standards Track [Page 8] RFC 2474 Differentiated Services Field December 1998
Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors.
Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors.
4. Historical Codepoint Definitions and PHB Requirements
4. Historical Codepoint Definitions and PHB Requirements
The DS field will have a limited backwards compatibility with current practice, as described in this section. Backwards compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queueing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant nodes. In addition, there are some codepoints that correspond to historical use of the IP 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 specific differentiated services PHBs mapped to by those codepoints MAY have additional specifications.
The DS field will have a limited backwards compatibility with current practice, as described in this section. Backwards compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queueing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant nodes. In addition, there are some codepoints that correspond to historical use of the IP 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 specific differentiated services PHBs mapped to by those codepoints MAY have additional specifications.
No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
4.1 A Default PHB
4.1 A Default PHB
A "default" PHB MUST be available in a DS-compliant node. This is the common, best-effort forwarding behavior available in existing routers as standardized in [RFC1812]. When no other agreements are in place, it is assumed that packets belong to this aggregate. Such packets MAY be sent into a network without adhering to any particular rules and the network will deliver as many of these packets as possible and as soon as possible, subject to other resource policy constraints. A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not required to satisfy another PHB. A reasonable policy for constructing services would ensure that the aggregate was not "starved". This could be enforced by a mechanism in each node that reserves some minimal resources (e.g, buffers, bandwidth) for Default behavior aggregates. This permits senders that are not differentiated services-aware to continue to use the network in the same manner as today. The impact of the introduction of differentiated services into a domain on the service expectations of its customers and peers is a complex matter involving policy decisions by the domain and is outside the scope of this document. The RECOMMENDED codepoint for the Default PHB is the bit pattern ' 000000'; the value '000000' MUST map to a PHB that meets these
「デフォルト」PHB MUST、DS対応することのノードで利用可能であってください。 これは[RFC1812]で標準化されるように既存のルータで利用可能な一般的で、ベストエフォート型の推進の振舞いです。 他の協定が全く適所にないとき、パケットがこの集合に属すと思われます。 どんな特定の規則も固く守らないで、そのようなパケットをネットワークに送るかもしれません、そして、ネットワークはできるだけ早く、他のリソース方針規制を条件としてこれらのできるだけ多くのパケットを提供するでしょう。 このPHBの妥当な実装は出力リンクが別のPHBを満たす必要はないときはいつも、この集合のパケットを送る待ち行列規律でしょう。 サービスを構成するための合理的な方針は、集合が「飢えなかったこと」を確実にするでしょう。 メカニズムはDefault振舞い集合のためのいくつかの最小量のリソース(e.g、バッファ、帯域幅)を予約する各ノードでこれを実施できました。 これは、サービス意識していた状態で差別化されない送付者が、今日と同じ方法でネットワークを使用し続けているのを許容します。 その顧客と同輩へのサービス期待のドメインに対する差別化されたサービスの導入の影響は、ドメインで政策決定にかかわる複雑な問題であり、このドキュメントの範囲の外にあります。 Default PHBのためのRECOMMENDED codepointはビット・パターン'000000'です。 '000000'がこれらに会うPHBに写像しなければならない値
Nichols, et. al. Standards Track [Page 9] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[9ページ]RFC2474は分野1998年12月にサービスを差別化しました。
specifications. The codepoint chosen for Default behavior is compatible with existing practice [RFC791]. Where a codepoint is not mapped to a standardized or local use PHB, it SHOULD be mapped to the Default PHB.
仕様。 Defaultの振舞いに選ばれたcodepointは既存の習慣[RFC791]と互換性があります。 codepointがどこにあるかが標準化されたか地方の使用にPHBを写像しないで、それはSHOULDです。Default PHBに写像されます。
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 that it will be forwarded using a different PHB within that domain, possibly subject to some negotiated agreement between the peering domains.
初めはDefaultの振舞いのためにマークされたパケットは、そのドメインの中でことによるとじっと見るドメインの間の何らかの交渉された協定を条件として異なったPHBを使用することでそれを進めるようにDSドメインに境界を向かわせるような別のcodepointで述べるかもしれません。
4.2 Once and Future IP Precedence Field Use
4.2 過去と将来のIP先行分野使用
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. Routers exist that use the IP Precedence field to select different per-hop forwarding treatments in a similar way to the use proposed here for the DSCP field. Thus, a simple prototype differentiated services architecture can be quickly deployed by appropriately configuring these routers. Further, IP systems today understand the location of the IP Precedence field, and thus if these bits are used in a similar manner as DS-compliant equipment is deployed, significant failures are not likely during early deployment. In 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 are employed in a manner similar to, or subsuming, the deployed uses of the IP Precedence field.
IP Precedence Fieldの現在の用途との何らかのフォームの後方の互換性を維持したいと思います: IPv4 TOS八重奏のビット0-2。 ここでDSCP分野に提案された使用への同様の方法で1ホップあたりの異なった推進処理を選択するのにIP Precedence分野を使用するルータが存在しています。 したがって、適切にこれらのルータを構成することによって、すぐに簡単なプロトタイプ差別化されたサービスアーキテクチャを配布することができます。 さらに、IPシステムは今日IP Precedence分野の位置を理解しています、そして、その結果、DS対応することの設備が配布されるときこれらのビットが同じように使用されるなら、重要な失敗は早めの展開の間、ありそうではありません。 言い換えれば、厳しいDS-承諾は分野が方法で同様の状態で使われるか、または包括しているDSCPのビット0-2であるならただ一つのサービスプロバイダーのネットワークの中にさえ遍在している必要はありません、IP Precedence分野の配布している用途。
4.2.1 IP Precedence History and Evolution in Brief
4.2.1 IP先行歴史と要するに、発展
The IP Precedence field is something of a forerunner of the DS field. IP Precedence, and the IP Precedence Field, were first defined in [RFC791]. The values that the three-bit IP Precedence Field might take were assigned to various uses, including network control traffic, routing traffic, and various levels of privilege. The least level of privilege was deemed "routine traffic". In [RFC791], the notion of Precedence was defined broadly as "An independent measure of the importance of this datagram." Not all values of the IP Precedence field were assumed to have meaning across boundaries, for instance "The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network." [RFC791]
IP Precedence分野はDS分野のある種の前触れです。 IP Precedence、およびIP Precedence Fieldは最初に、[RFC791]で定義されました。 3ビットのIP Precedence Fieldが取るかもしれない値は様々な用途に割り当てられました、ネットワーク制御トラフィック(ルーティングトラフィック、および様々なレベルの特権)を含んでいて 最少のレベルの名誉は「通常のトラフィック」であると考えられました。 [RFC791]では、Precedenceの概念は「このデータグラムの重要性の独立している基準」と広く定義されました。 IP Precedence分野のすべての値が境界の向こう側に意味を持っていると思われたというわけではなくて、例えば、「ネットワークだけの中でNetwork Control先行名称が使用されることを意図します」。 「その名称の実際の使用とコントロールは各ネットワークまで達しています。」 [RFC791]
Although early BBN IMPs implemented the Precedence feature, early commercial routers and UNIX IP forwarding code generally did not. As networks became more complex and customer requirements grew, commercial router vendors developed ways to implement various kinds of queueing services including priority queueing, which were
前のBBN IMPsはPrecedenceの特徴を実装しましたが、早めの商業ルータと一般に、コードを進めるUNIX IPは実装したというわけではありません。 ネットワークが、より複雑になって、顧客の要求が成長して、商業ルータベンダーが優先権待ち行列を含む様々な種類の待ち行列サービスを実装する方法を開発したように、どれがありましたか?
Nichols, et. al. Standards Track [Page 10] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[10ページ]RFC2474は分野1998年12月にサービスを差別化しました。
generally based on policies encoded in filters in the routers, which examined IP addresses, IP protocol numbers, TCP or UDP ports, and other header fields. IP Precedence was and is among the options such filters can examine.
一般にフィルタでIPアドレス、IPプロトコル番号、TCPまたはUDPポートを調べたルータでコード化された方針と他のヘッダーフィールドに基づいて。 IP Precedenceはあって、そのようなフィルタが調べることができるオプションの中にあります。
In short, IP Precedence is widely deployed and widely used, if not in exactly the manner intended in [RFC791]. This was recognized in [RFC1122], which states that while the use of the IP Precedence field is valid, the specific assignment of the priorities in [RFC791] were merely historical.
要するに、IP Precedenceは広く配布されて、広く使用されるか、または[RFC791]でまさに方法で意図します。 これは[RFC1122]で認識されました。(それは、IP Precedence分野の使用が有効ですが、[RFC791]のプライオリティの特定の課題が単に歴史的であると述べます)。
4.2.2 Subsuming IP Precedence into Class Selector Codepoints
4.2.2 クラスセレクタCodepointsにIP先行を包括すること。
A specification of the packet forwarding treatments selected by the IP Precedence field today would have to be quite general; probably not specific enough to build predictable services from in the differentiated services framework. To preserve partial backwards compatibility with known current uses of the IP Precedence field without sacrificing future flexibility, we have taken the approach of describing minimum requirements on a set of PHBs that are compatible with most of the deployed forwarding treatments selected by the IP Precedence field. In addition, we give a set of codepoints that MUST map to PHBs meeting these minimum requirements. The PHBs mapped to by these codepoints MAY have a more detailed list of specifications 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 Class Selector Codepoints, and the minimum requirements for PHBs that these codepoints may map to are called the Class Selector PHB Requirements.
今日IP Precedence分野によって選択されているパケット推進処理の仕様はかなり一般的でなければならないでしょう。 たぶん差別化されたサービスフレームワークで予測できるサービスを組み込むくらいには特定ではありません。 保護区後方に部分的に、未来を犠牲にしないで、IP Precedenceの知られている現在の用途との互換性は柔軟性をさばいて、私たちはIP Precedence分野によって選択される配布している推進処理の大部分と互換性があるPHBsの1セットにおける最小の要件について説明するアプローチを取りました。 さらに、私たちはこれらの必要最小限をPHBsミーティングに写像しなければならないcodepointsの1セットに与えます。 これらのcodepoints5月までに、より詳細なリストを持つためにここに述べられた必要なものに加えた仕様について写像されたPHBs。 これらの同じPHBsへの他のcodepoints5月の地図。 私たちがClass Selector Codepointsとしてのcodepointsのこのセット、およびこれらのcodepointsが写像するかもしれないPHBsのための必要最小限を参照する、Class Selector PHB Requirementsと呼ばれます。
4.2.2.1 The Class Selector Codepoints
4.2.2.1 クラスセレクタCodepoints
A specification of the packet forwarding treatments selected by the The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU subfield unspecified, are reserved as a set of Class Selector Codepoints. PHBs which are mapped to by these codepoints MUST satisfy the Class Selector PHB requirements in addition to preserving the Default PHB requirement on codepoint '000000' (Sec. 4.1).
'xxx000'のDS分野値によって選択されたパケット推進処理の仕様|'xx'かDSCPは'xxx000'とCU部分体と不特定の状態で等しく、Class Selector Codepointsの1セットとして予約されます。 PHBs、どれ、codepoint'000000'に関するDefault PHB要件を保存することに加えてcodepointsがClass Selector PHB要件を満たさなければならないこれらで、写像されるか。(秒 4.1).
4.2.2.2 The Class Selector PHB Requirements
4.2.2.2 クラスセレクタPHB要件
We refer to a Class Selector Codepoint with a larger numerical value than another Class Selector Codepoint as having a higher relative order while a Class Selector Codepoint with a smaller numerical value than another Class Selector Codepoint is said to have a lower relative order. The set of PHBs mapped to by the eight Class Selector Codepoints MUST yield at least two independently forwarded classes of traffic, and PHBs selected by a Class Selector Codepoint
私たちは別のClass Selector Codepointより大きい数値で別のClass Selector Codepointより小さい数値があるClass Selector Codepointが低い相対オーダを持っていると言われている間、より高い相対オーダを持っているとClass Selector Codepointを呼びます。 PHBsのセットが写像した、8時までには、Class Selector Codepointsは少なくとも2つの独自に進められたクラスのトラフィック、およびClass Selector Codepointによって選択されたPHBsをもたらさなければなりません。
Nichols, et. al. Standards Track [Page 11] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[11ページ]RFC2474は分野1998年12月にサービスを差別化しました。
SHOULD give packets a probability of timely forwarding that is not lower than that given to packets marked with a Class Selector codepoint of lower relative order, under reasonable operating conditions and traffic loads. A discarded packet is considered to be an extreme case of untimely forwarding. In addition, PHBs selected by codepoints '11x000' MUST give packets a preferential forwarding treatment by comparison to the PHB selected by codepoint '000000' to preserve the common usage of IP Precedence values '110' and '111' for routing traffic.
SHOULDは低い相対オーダのClass Selector codepointと共にマークされたパケットに与えられたそれほど低くないタイムリーな推進の確率をパケットに与えます、妥当な運転条件とトラヒック負荷の下で。 捨てられたパケットはタイミングの悪い推進の極端なケースであると考えられます。 さらに、codepoints'11×000'によって選択されたPHBsはPHBとの比較による優先の推進処理がcodepoint'000000'でルーティングトラフィックのためにIP Precedence値'110'と'111'の一般的な用法を保存するのを選択したパケットを与えなければなりません。
Further, PHBs selected by distinct Class Selector Codepoints SHOULD be independently forwarded; that is, packets marked with different Class Selector Codepoints MAY be re-ordered. A network node MAY enforce limits on the amount of the node's resources that can be utilized by each of these PHBs.
さらに、進めて、異なったClass Selector Codepoints SHOULDによって選択されたPHBsは独自にそうです。 すなわち、異なったClass Selector Codepointsと共にマークされたパケットは再命令されるかもしれません。 ネットワーク・ノードは限界にそれぞれのこれらのPHBsが利用できるノードのリソースの量に押しつけるかもしれません。
PHB groups whose specification satisfy these requirements are referred to as Class Selector Compliant PHBs.
仕様がこれらの要件を満たすPHBグループはClass Selector Compliant PHBsと呼ばれます。
The Class Selector PHB Requirements on codepoint '000000' are compatible with those listed for the Default PHB in Sec. 4.1.
codepoint'000000'の上のClass Selector PHB RequirementsはSecのDefault PHBのために記載されているそれらと互換性があります。 4.1.
4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence
Compatibility
4.2.2.3 IP先行の互換性のためのクラスセレクタPHB要件を使用すること。
A DS-compliant network node can be deployed with a set of one or more Class Selector Compliant PHB groups. This document states that the set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is also possible to map multiple codepoints to the same PHB, the vendor or the network administrator MAY configure the network node to map codepoints to PHBs irrespective of bits 3-5 of the DSCP field to yield a network that is compatible with historical IP Precedence use. Thus, for example, codepoint '011010' would map to the same PHB as codepoint '011000'.
1つ以上のClass Selector Compliant PHBグループのセットでDS対応することのネットワーク・ノードを配布することができます。 このドキュメントは、codepoints'xxx000'のセットがPHBsの1セットをそのようなものに写像しなければならないと述べます。 また、複数のcodepointsを同じPHBに写像するのも可能であるので、ベンダーかネットワーク管理者がDSCP分野のビット3-5の如何にかかわらず歴史的なIP Precedence使用と互換性があるネットワークをもたらすためにcodepointsをPHBsに写像するためにネットワーク・ノードを構成するかもしれません。 その結果例えば'011010'がcodepoint'011000'と同じPHBに写像するcodepoint。
4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant
PHB Groups
4.2.2.4 クラスのセレクタ対応することのPHBグループを実装するための例のメカニズム
Class Selector Compliant PHBs can be realized by a variety of mechanisms, including strict priority queueing, weighted fair queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based Queuing [CBQ]. The distinction between PHBs and mechanisms is described in more detail in Sec. 5.
さまざまなメカニズムでクラスSelector Compliant PHBsを実感できます、厳しい優先権待ち行列、荷重している公正な待ち行列(WFQ)、WRR、または異形[RPS、HPFQA、DRR]、またはベースのClass Queuing[CBQ]を含んでいて。 PHBsとメカニズムの区別はさらに詳細にSecで説明されます。 5.
It is important to note that these mechanisms might be available through other PHBs (standardized or not) that are available in a particular vendor's equipment. For example, future documents may standardize a Strict Priority Queueing PHB group for a set of
これらのメカニズムが他の特定のベンダーの設備で利用可能なPHBs(標準化される)を通して利用可能であるかもしれないことに注意するのは重要です。 例えば、ドキュメントがセットのためのStrict Priority Queueing PHBグループを標準化するかもしれない未来
Nichols, et. al. Standards Track [Page 12] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[12ページ]RFC2474は分野1998年12月にサービスを差別化しました。
recommended codepoints. A network administrator might configure those routers to select the Strict Priority Queueing PHBs with codepoints 'xxx000' in conformance with the requirements of this document.
お勧めのcodepoints。 ネットワーク管理者は、このドキュメントの要件で順応でcodepoints'xxx000'があるStrict Priority Queueing PHBsを選択するためにそれらのルータを構成するかもしれません。
As a further example, another vendor might employ a CBQ mechanism in its routers. The CBQ mechanism could be used to implement the Strict 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 of PHBs that did no more than meet the minimum Class Selector PHB requirements.
さらなる例として、別のベンダーはルータでCBQメカニズムを使うかもしれません。 会っただけであるPHBsの1セットにおける、利用可能であるだろうより広い範囲の特徴があるClass Selector Compliant PHBsの1セットと同様にStrict Priority Queueing PHBsが最小のClass Selector PHB要件であると実装するのにCBQメカニズムを使用できました。
4.3 Summary
4.3 概要
This document defines codepoints 'xxx000' as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the Class Selector PHB Requirements described in Sec. 4.2.2.2. This is done to preserve a useful level of backward compatibility with current uses of the IP Precedence field in the Internet without unduly limiting future flexibility. In addition, codepoint '000000' is used as the Default PHB value for the Internet and, as such, is not configurable. The remaining seven non-zero Class Selector codepoints are configurable only to the extent that they map to PHBs that meet the requirements in Sec. 4.2.2.2.
このドキュメントはcodepoints'xxx000'をClass Selector codepointsと定義します。そこで、これらのcodepointsによって選択されたPHBsはSecで説明されたClass Selector PHB Requirementsに会わなければなりません。 4.2.2.2. 将来の柔軟性を過度に制限しないでインターネットのIP Precedence分野の現在の用途との役に立つレベルの後方の互換性を保存するためにこれをします。 さらに、codepoint'000000'はDefault PHBがインターネットに評価するように使用されていて、そういうものとして構成可能ではありません。 7残っている非ゼロClass Selector codepointsが彼らがSecで条件を満たすPHBsに写像する範囲だけに構成可能です。 4.2.2.2.
5. Per-Hop Behavior Standardization Guidelines
5. 1ホップあたりの振舞い標準化ガイドライン
The behavioral characteristics of a PHB are to be standardized, and not the particular algorithms or the mechanisms used to implement 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 (e.g., N separate queues with settable priorities, queue lengths, round-robin weights, drop algorithm, drop preference weights and thresholds, etc). To illustrate the distinction between a PHB and a mechanism, we point out that Class Selector Compliant PHBs might be implemented by several mechanisms, including: strict priority queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in isolation or in combination.
それらをPHBの行動の特性が標準化されることであり、いずれの特定のアルゴリズムもメカニズムも以前はよく実装していませんでした。 ノードには、パケットがどう出力インタフェースに予定されているかを(例えば、「舗装用敷石-可能」プライオリティがあるN別々の待ち行列、待ち行列の長さ、連続重り(低下アルゴリズム)は好みの重りと敷居などを下げます)制御するのに使用できる(ことによると大きい)のセットのパラメタがあるかもしれません。 PHBとメカニズムの区別を例証するために、私たちは、Class Selector Compliant PHBsが数個のメカニズムによって実装されるかもしれないと指摘します、である: 分離してか組み合わせにおける厳しい優先権の待ち行列、WFQ、WRR、異形[HPFQA、RPS、DRR]、またはCBQ[CBQ]。
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 of two or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to each PHB within the group, such as a queue servicing or queue management policy. A PHB group specification SHOULD describe conditions under which a packet might be re-marked to select another PHB within the group. It is RECOMMENDED that PHB implementations do not introduce any packet re-ordering within a microflow. PHB group
PHBsは個別かグループとして指定されるかもしれません(独身のPHBはPHBグループの特別なケースです)。 通常、PHBグループは同時に意味深長に指定して、実装することができない2PHBsのしか1セットから成ります、グループの中の各PHBに適用される一般的な規制のため、待ち行列整備点検や待ち行列経営政策のように。 PHBグループ仕様SHOULDはパケットがグループの中で別のPHBを選択するために述べるかもしれない状態について説明します。 PHB実装がmicroflowの中でどんなパケット再注文も導入しないのは、RECOMMENDEDです。 PHBグループ
Nichols, et. al. Standards Track [Page 13] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[13ページ]RFC2474は分野1998年12月にサービスを差別化しました。
specifications MUST identify any possible packet re-ordering implications which may occur for each individual PHB, and which may occur if different packets within a microflow are marked for different PHBs within the group.
仕様はそれぞれの個々のPHBのために起こるかもしれなくて、microflowの中の異なったパケットが異なったPHBsのためにグループの中でマークされるなら起こるどんな可能なパケット再注文含意も特定しなければなりません。
Only those per-hop behaviors that are not described by an existing PHB standard, and have been implemented, deployed, and shown to be useful, SHOULD be standardized. Since current experience with differentiated services is quite limited, it is premature to hypothesize the exact specification of these per-hop behaviors.
それらの1ホップあたりの振舞いだけが、SHOULDが標準化されるのを既存のPHB規格によって説明されて、配布されて、実装されて、役に立つように示していません。 差別化されたサービスの現在の経験がかなり限られているので、これらの1ホップあたりの振舞いの正確な仕様を仮定するのは時期尚早です。
Each standardized PHB MUST have an associated RECOMMENDED codepoint,
allocated out of a space of 32 codepoints (see Sec. 6). This
specification has left room in the codepoint space to allow for
evolution, thus the defined space ('xxx000') is intentionally sparse.
それぞれの標準化されたPHB MUSTは32codepointsのスペースから割り当てられた関連RECOMMENDED codepointを持っています。(Secを見てください。 6). この仕様には発展を考慮するcodepointスペースの余地がありました、その結果、定義されたスペース('xxx000')は故意にまばらです。
Network equipment vendors are free to offer whatever parameters and capabilities are deemed useful or marketable. When a particular, standardized PHB is implemented in a node, a vendor MAY use any algorithm that satisfies the definition of the PHB according to the standard. The node's capabilities and its particular configuration determine the different ways that packets can be treated.
ネットワーク装置ベンダーは自由に役に立つか、または市場向きであると考えられるどんなパラメタと能力も提供できます。 特定の、そして、標準化されたPHBがノードで実装されるとき、ベンダーは規格に従ってPHBの定義を満たすどんなアルゴリズムも使用するかもしれません。 ノードの能力とその特定の構成はパケットを扱うことができる異なった方法を決定します。
Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives. Over time certain common per-hop behaviors are likely to evolve (i.e., ones that are particularly useful for implementing end-to-end services) and these MAY be associated with particular EXP/LU PHB codepoints in the DS field, allowing use across domain boundaries (see Sec. 6). These PHBs are candidates for future standardization.
サービスプロバイダーは、それらのネットワークの中でサービス分化を可能にするのに同じノードメカニズムか構成を使用するのが必要でなく、自由にいかなるそれらのサービス提供と交通工学目的に、適切な方法でもノードパラメタを構成できます。 1ホップあたりの一般的な振舞いが(すなわち、特に終わりから終わりに対するサービスを実装することの役に立つもの)を発展しそうであって、これらが発展するかもしれないのを確信している時間、DS分野の特定のEXP/LU PHB codepointsに関連してください、ドメイン境界の向こう側に使用を許して(Secを見てください。 6). これらのPHBsは今後の標準化の候補です。
It is RECOMMENDED that standardized PHBs be specified in accordance with the guidelines set out in [ARCH].
[ARCH]に設定されるガイドラインによると、標準化されたPHBsが指定されるのは、RECOMMENDEDです。
6. IANA Considerations
6. IANA問題
The DSCP field within the DS field is capable of conveying 64 distinct codepoints. The codepoint space is divided into three pools for the purpose of codepoint assignment and management: a pool of 32 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 experimental or Local Use (EXP/LU) as defined in [CONS], and a pool of 16 codepoints (Pool 3) which are initially available for experimental or local use, but which should be preferentially
DS分野の中のDSCP分野は64の異なったcodepointsを運ぶことができます。 codepointスペースはcodepoint課題と管理の目的のために3つのプールに分割されます: [コンズ]で定義されるようにStandards Actionによって割り当てられる、32RECOMMENDED codepoints(プール1)のプール、実験的であるかLocal Use(EXP/LU)のために[コンズ]で定義されるように予約されるべき16codepoints(プール2)のプール、および初めは、実験的であるか地方の使用に利用可能ですが、優先的にそうであるべきである16codepoints(プール3)のプール
Nichols, et. al. Standards Track [Page 14] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[14ページ]RFC2474は分野1998年12月にサービスを差別化しました。
utilized for standardized assignments if Pool 1 is ever exhausted. The pools are defined in the following table (where 'x' refers to either '0' or '1'):
Pool1が今までに消耗しているなら、標準化された課題に利用されます。 プールは以下のテーブル('x'が'0'か'1'について言及するところ)で定義されます:
Pool Codepoint space Assignment Policy ---- --------------- -----------------
プールのCodepointスペースAssignment Policy---- --------------- -----------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)
1 xxxxx0 Standards Action2xxxx11 EXP/LU3xxxx01 EXP/LU(*)
(*) may be utilized for future Standards Action allocations as
necessary
(*)は必要に応じて今後のStandards Action配分に利用されるかもしれません。
This document assigns eight RECOMMENDED codepoints ('xxx000') which
are drawn from Pool 1 above. These codepoints MUST be mapped, not to
specific PHBs, but to PHBs that meet "at least" the requirements set
forth in Sec. 4.2.2.2 to provide a minimal level of backwards
compatibility with IP Precedence as defined in [RFC791] and as
deployed in some current equipment.
このドキュメントは上でPool1から得られる8RECOMMENDED codepoints('xxx000')を割り当てます。 特定のPHBsではなく、「少なくとも」Secに詳しく説明された必要条件を満たすPHBsにこれらのcodepointsを写像しなければなりません。 4.2.2.2、[RFC791]で定義されるIP Precedence、何らかの現在の設備で配布されるように最小量のレベルの遅れている互換性を提供するために。
7. Security Considerations
7. セキュリティ問題
This section considers security issues raised by the introduction of differentiated services, primarily the potential for denial-of- service attacks, and the related potential for theft of service by unauthorized traffic (Section 7.1). Section 7.2 addresses the operation of differentiated services in the presence of IPsec including its interaction with IPsec tunnel mode and other tunnelling protocols. See [ARCH] for more extensive treatment of the security concerns raised by the overall differentiated services architecture.
このセクションが、セキュリティが差別化されたサービスの導入で提起された問題、主として否定の可能性であると考える、-、-権限のないトラフィック(セクション7.1)で攻撃、およびサービスの窃盗の関連する可能性を修理してください。 セクション7.2はIPsecトンネルモードと他のトンネルプロトコルとの相互作用を含むIPsecの面前で差別化されたサービスの操作を扱います。 安全上の配慮の、より大規模な処理のための[ARCH]が総合的な差別化されたサービスアーキテクチャによって上げられるのを見てください。
7.1 Theft and Denial of Service
7.1 窃盗とサービス妨害
The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better) service than others. The mapping of network traffic to the specific behaviors that result in different (e.g., better or worse) service is indicated primarily by the DS codepoint, and hence an adversary may be able to obtain better service by modifying the codepoint to values indicating behaviors used for enhanced services or by injecting packets with such codepoint values. Taken to its limits, such theft-of-service becomes a denial-of- service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams.
差別化されたサービスのプライマリ目標は異なったレベルのサービスが一般的なネットワークインフラでトラフィックストリームに提供されるのを許容することです。 さまざまなテクニックがこれを達成するのに使用されるかもしれませんが、結末はいくつかのパケットが他のものと異なった(例えば、より良い)サービスを受けるということでしょう。 異なった(例えば、より良いか、より悪い)サービスをもたらす特異的行動へのネットワークトラフィックに関するマッピングは主としてDS codepointによって示されます、そして、したがって、敵は高度サービスに使用される振舞いを示す値にcodepointを変更するか、またはそのようなcodepoint値をパケットに注射することによって、より良いサービスを得ることができるかもしれません。 限界に取ります、そのようなサービスの窃盗は-変更されたか注入されたトラフィックがそれと他のトラフィックを進めるために利用可能なリソースを使い果たすとき、サービスでは、攻撃が流れるという否定になります。
Nichols, et. al. Standards Track [Page 15] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[15ページ]RFC2474は分野1998年12月にサービスを差別化しました。
The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate. An important instance of a boundary node is that any traffic-originating node within a DS domain is the initial boundary node for that traffic. Interior nodes in a DS domain rely on DS codepoints to associate traffic with the forwarding PHBs, and are NOT REQUIRED to check codepoint values before using them. As a result, the interior nodes depend on the correct operation of the DS domain boundary nodes to prevent the arrival of traffic with inappropriate codepoints or in excess of provisioned levels that would disrupt operation of the domain.
このクラスの窃盗とサービス不能攻撃に対するディフェンスはDSドメインの中でDSドメイン境界でネットワークインフラのセキュリティと保全でトラフィック調節の組み合わせから成ります。 DSドメイン境界ノードは、ドメインに入るすべてのトラフィックがトラフィックとドメインに適切なcodepoint値でマークされるのを確実にしなければなりません、必要なら、新しいcodepoint値でトラフィックを述べさせて。 どんなそのような攻撃の成功も、攻撃トラフィックによって使用されるcodepointsが不適当であったのを示すとき、これらのDS境界ノードは窃盗と-サービスでは、攻撃が変更されたcodepointsを基礎づけたという否定に対するプライマリ防衛線です。 境界ノードの重要なインスタンスはDSドメインの中のどんなトラフィックを溯源するノードもそのトラフィックのための初期の境界ノードであるということです。 DSドメインの内部のノードは、推進PHBsにトラフィックを関連づけるためにDS codepointsを当てにして、それらを使用する前にcodepoint値をチェックするNOT REQUIREDです。 その結果、内部のノードは、不適当なcodepointsかドメインの操作を中断する食糧を供給されたレベルを超えてトラフィックの到着を防ぐためにDSドメイン境界ノードの正しい操作によります。
7.2 IPsec and Tunnelling Interactions
7.2 IPsecとトンネル相互作用
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 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 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 provide any defense against an adversary's modification of the DS field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security.
[超能力、AH]で定義されるIPsecプロトコルは暗号の計算のいずれにもIPヘッダーのDS分野を含んでいません(トンネルモードの場合では、それは外側のIPヘッダーの含まれていないDS分野です)。 したがって、ネットワーク・ノードによるDS分野の変更は終わりから終わりへのIPsecのセキュリティで効き目がありません、それがどんなIPsec保全チェックにも失敗できないので。 結果として、IPsecは敵のDS分野(すなわち、介入者攻撃)の変更に対してどんなディフェンスも提供しません、また、敵の変更が終わりから終わりへのIPsecのセキュリティで効き目がないとき。
IPsec's tunnel mode provides security for the encapsulated IP header's DS field. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is hosted (in whole or in part) on a differentiated services network, the intermediate network nodes operate on the DS field in the outer header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the packet (if required) using the inner header. The IPsec protocol REQUIRES that the inner header's DS field not be changed by this decapsulation processing to ensure that modifications to the DS field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint. This document makes no change to that requirement. If the inner IP header has not been processed by a DS boundary node for the tunnel egress node's DS
IPsecのトンネルモードはカプセル化されたIPヘッダーのDS分野にセキュリティを提供します。 トンネルモードIPsecパケットは2個のIPヘッダーを含んでいます: トンネルイングレスノードを供給された外側のヘッダーとパケットの一次資料によって供給されたカプセル化された内側のヘッダー。 IPsecトンネルが差別化されたサービスネットワークで接待されるとき(全体か一部)、中間ネットワークノードは外側のヘッダーのDSフィールドを作動させます。 トンネル出口ノードでは、IPsec処理は、内側のヘッダーを使用することで外側のヘッダーを取り除いて、(必要なら、)パケットを進めるのを含んでいます。 IPsecは、IPsecトンネル終点の向こう側に窃盗かサービス不能攻撃に着手するのにDS分野への変更を使用できないのを保証するためにこの被膜剥離術処理で変えた状態で内側のヘッダーのDS分野がないREQUIRESについて議定書の中で述べます。 このドキュメントはその要件への変更を全く行いません。 内側のIPヘッダーがトンネル出口ノードのDSのためのDS境界ノードによって処理されていないなら
Nichols, et. al. Standards Track [Page 16] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[16ページ]RFC2474は分野1998年12月にサービスを差別化しました。
domain, the tunnel egress node is the boundary node for traffic exiting the tunnel, and hence MUST ensure that the resulting traffic has appropriate DS codepoints.
ドメイン、トンネル出口ノードはトンネルを出るトラフィックのための境界ノードであり、したがって、結果として起こるトラフィックには適切なDS codepointsがあるのを確実にしなければなりません。
When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), 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. An important consequence is that otherwise insecure links within a DS domain can be secured by a sufficiently strong IPsec tunnel. This analysis and its implications apply to any tunnelling protocol that performs integrity checks, but the level of assurance of the inner header's DS field depends on the strength of the integrity check performed by the tunnelling protocol. In the absence of sufficient assurance for a tunnel that may transit nodes outside the current DS domain (or is otherwise vulnerable), the encapsulated packet MUST be treated as if it had arrived at a boundary from outside the DS domain.
IPsecトンネル出口被膜剥離術処理がカプセル化されたパケット(十分がローカルの安全保障政策で決定するところ)の十分強い暗号の保全チェックを含んでいると、トンネル出口ノードは、内側のヘッダーのDS分野がそれが持っていたようにトンネルイングレスノードに同じ値を持っていると安全に仮定できます。 重要な結果は十分堅固なIPsecトンネルでDSドメインの中のそうでなければ、不安定なリンクを固定できるということです。 この分析とその含意は保全チェックを実行するどんなトンネルプロトコルにも適用されますが、内側のヘッダーのDS分野の保証のレベルはトンネルプロトコルによって実行された保全チェックの強さに依存します。 現在のDSドメイン(または、そうでなければ、被害を受け易い)の外にノードを通過するかもしれないトンネルのための十分な保証がないとき、まるでDSドメインの外から境界に到着したかのようにカプセル化されたパケットを扱わなければなりません。
8. Acknowledgements
8. 承認
The authors would like to acknowledge the Differentiated Services Working Group for discussions which helped shape this document.
作者はこのドキュメントを形成するのを助けた議論のためにDifferentiated Services作業部会を承認したがっています。
9. References
9. 参照
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[アーチ形に曲げます] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CBQ] S.フロイドとV.ジェーコブソン、「リンク共有と資源管理はパケット網のためにモデル化します」、Networkingの上のIEEE/ACM Transactions、Vol.3No.4、ページ 365-386と、1995年8月。
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[コンズ]NartenとT.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、RFC2434、1998年10月。
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
「[DRR] 赤字を使用するM.ShreedharとG.Varghese、効率的な公正な待ち行列がロビンを一周する」、Proc。 ACM SIGCOMM95、1995。
Nichols, et. al. Standards Track [Page 17] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[17ページ]RFC2474は分野1998年12月にサービスを差別化しました。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[HPFQA] J.ベネットとホイ・チャン、「階層的なパケット公正な待ち行列アルゴリズム」、Proc。 1996年8月のACM SIGCOMM96。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、エディタ、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エディタ、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A
Design Methodology for Fair Queueing Algorithms", IEEE/
ACM Trans. on Networking, April 1998.
[RPS] D.StiliadisとA.バルマー、「レート比例しているサーバ:」 「公正な待ち行列アルゴリズムのためのデザイン方法論」、IEEE/ ACM、移-. ネットワーク、1998年4月に。
Nichols, et. al. Standards Track [Page 18] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[18ページ]RFC2474は分野1998年12月にサービスを微分しました。
Authors' Addresses
作者のアドレス
Kathleen Nichols Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
西タスマン・Driveサンノゼ、キャサリーンニコルズシスコシステムズ170カリフォルニア95134-1706
Phone: +1-408-525-4857 EMail: kmn@cisco.com
以下に電話をしてください。 +1-408-525-4857 メールしてください: kmn@cisco.com
Steven Blake Torrent Networking Technologies 3000 Aerial Center, Suite 140 Morrisville, NC 27560
スティーブンブレーク急流ネットワーク・テクノロジー3000の空中センター、140Morrisville、Suite NC 27560
Phone: +1-919-468-8466 x232 EMail: slblake@torrentnet.com
以下に電話をしてください。 +1-919-468-8466 x232 EMail: slblake@torrentnet.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
フレッドベイカーシスコシステムズ519のLado Driveサンタバーバラ、カリフォルニア 93111
Phone: +1-408-526-4257 EMail: fred@cisco.com
以下に電話をしてください。 +1-408-526-4257 メールしてください: fred@cisco.com
David L. Black EMC Corporation 35 Parkwood Drive Hopkinton, MA 01748
デヴィッド・L.の黒いEMC社35のParkwood Driveホプキントン、MA 01748
Phone: +1-508-435-1000 x76140 EMail: black_david@emc.com
以下に電話をしてください。 +1-508-435-1000 x76140 EMail: black_david@emc.com
Nichols, et. al. Standards Track [Page 19] RFC 2474 Differentiated Services Field December 1998
etニコルズ、アル。 標準化過程[19ページ]RFC2474は分野1998年12月にサービスを微分しました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Nichols, et. al. Standards Track [Page 20]
etニコルズ、アル。 標準化過程[20ページ]
一覧
スポンサーリンク
