An Architecture for Differentiated Services

RFC 2475

Introduction

Diffserv architecture is to implement scalable service in the InternetA Service defines some significant characteristics of packet transmission such as : throughput, delay, jitter, loss

Service differentiation is desired to accommodate heterogeneous app. requirements and user expectations

IntroductionDiffserv architecture is compose of a number of functional elements implemented in network nodes: A small set of per-hop forwarding behavior Packet classification functions Traffic conditioning functions

Complex classification and conditioning functions are only at boundary nodes achieves scalability

Requirements

Accommodate a wide variety of services and provisioning policiesAllow decoupling of the service form the particular app. in useWork with existing app. without the need for the changes of the app.Decouple traffic conditioning and service provisioning functions form forwarding behaviors within core nodes

RequirementsShould not depend on hop-by-hop app. signalingRequire only a small set of forwarding behaviorsAvoid per-microflow or per-customer state within core network nodesUtilize only aggregated classification state within core network nodes

Requirements

Permit simple packet classification implementations in core network nodesPermit reasonable interoperability with non-DS-compliant network nodesAccommodate incremental deployment

Diffserv Architectural Model

The simple model is: Traffic entering a network is classified

and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates

Behavior aggregate is identified by a single DS codepointPackets are forwarded according to the per-hop behavior associated with the DS codepoint in the core network

Diffserv Domain

DS boundary nodes classify and possibly condition ingress

traffic

DS interior nodes Select the forwarding behavior for

packets based on their DS codepoint

Diffserv Domain

Ingress and Egress nodes

DS boundary nodes act both as a DS ingress node and as a DS egress node for different directions of trafficDS ingress node is responsible for ensuring that the traffic entering the

DS domain conforms to the TCA

DS egress node perform traffic conditioning functions

on traffic forwarded to another domain

Diffserv RegionA set of one or more contiguous DS domainsTo permit services which span across the domains, the peering DS domains must each establish a peering SLASeveral DS domains within a DS region— Adopt a common service provisioning policy Support a common set of PHB groups and

codepoint mappings

Traffic classification and conditioning

Packet classification policy Identify the subset of traffic

Traffic conditioning performs: Metering Shaping Policing Remarking

Classifiers

Select packets in a traffic stream based on the content of some portion of the packet headerTwo types of classifiers— BA (Behavior Aggregate) classifier

Classify the packets based on codepoint only

MF (Multi-Field) classifier Classify the packets based on the value of

a combination of one or more header fields

Traffic profiles

Specifies the temporal properties of a traffic stream selected by a classifierProvides rules for determining whether a particular packet is in-profile or out-of-profileExample: codepoint=X, use token-bucket r, b r—rate ; b—burst size

Traffic conditionersA traffic conditioner may contain the following elements: Meter Marker Shaper Dropper

A traffic stream is selected by a classifierClassifier steers the packets to a logical instance of a traffic conditioner

Logical view of classifier and conditioner

Classifier

Meter

MarkerShaper/ DropperPackets

Traffic conditioners

Meters measure the temporal properties of

the stream of packets passes state information to other

conditioning functions

Markers Set the DS field of a packet to a

particular codepoint re-marked the packets

Traffic conditioners

Shapers Delay packets in a traffic stream Discard packets when the buffer is full

Droppers Discard packets in a traffic stream Can be implemented by set the

shaper buffer size to zero

Location of traffic conditioners

Within the source domain Marking packets close to the traffic

source

At the boundary of a DS domain Ingress and egress nodes

In non-DS-capable domainsIn interior DS nodes More restrictive access policies may

be enforced on a transoceanic link

Per-Hop Behaviors

The externally observable behavior of a DS node applied to a particular DS behavior aggregatePHBs are implemented in nodes by means of some buffer management and packet scheduling mechanismsA PHB is selected at a node by a mapping of the DS codepoint

Resource Allocation

Traffic conditioners can further control the usage of resources through— Enforcement of TCAs Operational feedback from the nodes

and traffic conditioners in the domain

PHB Specification Guidelines

Help foster implementation consistencyA PHB group must satisfy the guidelinesPreserve the integrity of this architectureThere are totally 15 guidelines in the RFC 2475

Non-Diffserv-Compliant Nodes

Does not interpret the DS field as specified in [DSFIELD]Dose not implement some or all of the PHB standardized PHBsDue to the capabilities or configuration of the nodeA special case of a non-DS-compliant node is the legacy node

Non-Diffserv-Compliant Nodes

The use of non-DS-compliant nodes within a DS domain Impossible to offer low-delay, low-loss,

or provisioned bandwidth services The use of a legacy node may be an

acceptable alternative The legacy node may or may not

interpret bits 3-5 in accordance with RFC1349 Result in unpredictable forwarding results

Non-Diffserv-Compliant Nodes

The behavior of services which traverse non-DS-capable domains Limit the ability to consistently deliver

some types of services across the domain

A DS domain and a non-DS-capable domain may negotiate an agreement

A traffic stream form no-DS-capable domain to DS domain should be conditioned according to the appropriate SLA or policy

Multicast considerations

Multicast packets may simultaneously take multiple paths through some segments of the domainConsume more network resources than unicast packetsMulticast group membership is dynamic Difficult to predict in advance the

amount of network resources

Multicast considerations

The selection of the DS codepoint for a multicast packet arriving at a DS ingress nodePacket may exit the DS domain at multiple DS egress nodesThe service guarantees for unicast traffic may be impacted

Multicast considerations

One means for addressing this problem: Establish a particular set of

codepoints for multicast packets Implement the necessary

classification and traffic conditioning mechanisms in the DS egress nodes

Provide preferential isolation for unicast traffic

Security Considerations

Theft and Denial of Service An adversary may be able to obtain

better service by modifying the DS field to codepoint

The theft of service becomes denial-of-service when it depletes the resources

Traffic conditioning at DS boundary nodes bust be along with security and integrity

IPsec and Tunneling Interactions

IPsec’s tunnel mode provides security for the encapsulated IP header’s DS fieldA tunnel mode IPsec packet contains 2 IP headers: Outer header supplied by the tunnel

ingress node Encapsulated inner header supplied by

the original source of the packet

IPsec and Tunneling Interactions

At the tunnel egress node, IPsec processing includes: Stripping the outer header Forwarding the packet using the inner

header

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