📄 rfc2475.txt
字号:
Mechanism a specific algorithm or operation (e.g., queueing discipline) that is implemented in a node to realize a set of one or more per- hop behaviors.Blake, et. al. Informational [Page 5] RFC 2475 Architecture for Differentiated Services December 1998 Meter a device that performs metering. Metering the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. Microflow a single instance of an application-to- application flow of packets which is identified by source address, source port, destination address, destination port and protocol id. MF Classifier a multi-field (MF) classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, DS field, protocol ID, source port and destination port. Per-Hop-Behavior (PHB) the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. PHB 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. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group. Policing the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile. Pre-mark to set the DS codepoint of a packet prior to entry into a downstream DS domain.Blake, et. al. Informational [Page 6] RFC 2475 Architecture for Differentiated Services December 1998 Provider DS domain the DS-capable provider of services to a source domain. Re-mark to change the DS codepoint of a packet, usually performed by a marker in accordance with a TCA. Service the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end. Service Level Agreement a service contract between a customer and a (SLA) service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part. Service Provisioning a policy which defines how traffic Policy conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services. Shaper a device that performs shaping. Shaping the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile. Source domain a domain which contains the node(s) originating the traffic receiving a particular service. Traffic conditioner an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers. Traffic conditioners are typically deployed in DS boundary nodes only. A traffic conditioner may re-mark a traffic stream or may discard or shape packets to alter the temporal characteristics of the stream and bring it into compliance with a traffic profile.Blake, et. al. Informational [Page 7] RFC 2475 Architecture for Differentiated Services December 1998 Traffic conditioning control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing. Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy. Traffic profile a description of the temporal properties of a traffic stream such as rate and burst size. Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier. Upstream DS domain the DS domain upstream of traffic flow on a boundary link.1.3 Requirements The history of the Internet has been one of continuous growth in the number of hosts, the number and variety of applications, and the capacity of the network infrastructure, and this growth is expected to continue for the foreseeable future. A scalable architecture for service differentiation must be able to accommodate this continued growth. The following requirements were identified and are addressed in this architecture: o should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s), o should allow decoupling of the service from the particular application in use,Blake, et. al. Informational [Page 8] RFC 2475 Architecture for Differentiated Services December 1998 o should work with existing applications without the need for application programming interface changes or host software modifications (assuming suitable deployment of classifiers, markers, and other traffic conditioning functions), o should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes, o should not depend on hop-by-hop application signaling, o should require only a small set of forwarding behaviors whose implementation complexity does not dominate the cost of a network device, and which will not introduce bottlenecks for future high- speed system implementations, o should avoid per-microflow or per-customer state within core network nodes, o should utilize only aggregated classification state within the network core, o should permit simple packet classification implementations in core network nodes (BA classifier), o should permit reasonable interoperability with non-DS-compliant network nodes, o should accommodate incremental deployment.1.4 Comparisons with Other Approaches The differentiated services architecture specified in this document can be contrasted with other existing models of service differentiation. We classify these alternative models into the following categories: relative priority marking, service marking, label switching, Integrated Services/RSVP, and static per-hop classification. Examples of the relative priority marking model include IPv4 Precedence marking as defined in [RFC791], 802.5 Token Ring priority [TR], and the default interpretation of 802.1p traffic classes [802.1p]. In this model the application, host, or proxy node selects a relative priority or "precedence" for a packet (e.g., delay or discard priority), and the network nodes along the transit path apply the appropriate priority forwarding behavior corresponding to the priority value within the packet's header. Our architecture can be considered as a refinement to this model, since we more clearlyBlake, et. al. Informational [Page 9] RFC 2475 Architecture for Differentiated Services December 1998 specify the role and importance of boundary nodes and traffic conditioners, and since our per-hop behavior model permits more general forwarding behaviors than relative delay or discard priority. An example of a service marking model is IPv4 TOS as defined in [RFC1349]. In this example each packet is marked with a request for a "type of service", which may include "minimize delay", "maximize throughput", "maximize reliability", or "minimize cost". Network nodes may select routing paths or forwarding behaviors which are suitably engineered to satisfy the service request. This model is subtly different from our architecture. Note that we do not describe the use of the DS field as an input to route selection. The TOS markings defined in [RFC1349] are very generic and do not span the range of possible service semantics. Furthermore, the service request is associated with each individual packet, whereas some service semantics may depend on the aggregate forwarding behavior of a sequence of packets. The service marking model does not easily accommodate growth in the number and range of future services (since the codepoint space is small) and involves configuration of the "TOS->forwarding behavior" association in each core network node. Standardizing service markings implies standardizing service offerings, which is outside the scope of the IETF. Note that provisions are made in the allocation of the DS codepoint space to allow for locally significant codepoints which may be used by a provider to support service marking semantics [DSFIELD]. Examples of the label switching (or virtual circuit) model include Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path at an ingress node, and packets/cells within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop. This model permits finer granularity resource allocation to traffic streams, since label values are not globally significant but are only significant on a single link; therefore resources can be reserved for the aggregate of packets/⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -