Transcript Differentiated Services

9. IP QoS Service
9.1. Introduction
The current Internet: IP Protocol
• Best-Effort Service – no Quality of Service
(QoS) guarantees are provided.
• Connectionless Service – no connection is
established prior to sending the packets. Each
packet carries the full destination address.
Routing is performed using a shortest path
algorithm, independently for each packet.
Why do we need a new protocol ?
• The emerging Multimedia applications require
QoS guarantees.
• Real-time applications require connection
oriented services.
• Other routing algorithms may be more
appropriate than the shortest path algorithm in
order to increase network efficiency and provide
QoS.
IETF* proposed solutions:
• Integrated Services (IntServ)
• Resource Reservation Protocol (RSVP)
– Disadvantage: Scalability (per-flow reservations)
• Differentiated Services (DiffServ)
– Disadvantage: No per-flow QoS guarantee
• Multiprotocol Label Switching (MPLS)
*IETF – Internet Engineering Task Force
REQUIREMENTS for IP QoS
• A network is characterized as having EDGE and CORE ROUTERS.
• Edge routers accept customer traffic, i.e., packets from any source
outside the network into the network.
• Core routers provide transit packet forwarding service between other
Core routers and/or Edge routers.
• Edge routers characterize, police, and mark customer traffic being
admitted to the network.
• Edge routers may decline requests signaled by outside sources
(Admission Control).
• Core routers differentiate traffic insofar as necessary to cope with
transient congestion within the network itself.
• Statistical multiplexing must be utilized wherever appropriate to
maximize utilizaton of core resources.
Network Architecture
9.2. Integrated Services (IntServ)
GOAL: Augment existing Best Effort Internet with a range of end-to-end
services for real-time streaming in interactive applications.
• IntServ developed an architecture requiring per-flow traffic
handling at every hop along an application’s end-to-end path
and explicit a priori signaling using RSVP (Resource Reservation
Protocol) of each flow’s requirements.
• IntServ model requires resources such as bandwidth and buffers
to be explicitly reserved for a given data flow to ensure that the
application receives its requested QoS.
• A flow is composed by a stream of packets with the same source
and destination addresses and port numbers.
• A flow descriptor is used to describe the traffic and QoS
requirements of a flow.
• Per-flow QoS guarantees are provided at the
expense of installing and maintaining flow-specific
state in each router along the flow’s path.
• Basic components of the IntServ architecture:
Setup Protocol, Traffic Control (filterspec),
flowspec and Traffic Classes.
9.2.1. Architecture Basic Components
• Setup Protocol – enables a host or an application to
request a specific amount of resources from the
network  realized by
(Resource Reservation Protocol (RSVP))
• Traffic Control (filterspec) – includes packet classifier,
packet scheduler, and admission control.
• flowspec – objects such as token bucket parameters.
• Traffic Classes – best-effort, controlled load, and
guaranteed services.
9.2.2. Setup Protocol: RSVP
• Every application is presumed to use some form of signaling
to negotiate service with an IntServ capable network.
• IntServ signaling has 2 functions:
Negotiation: When the network decides whether it
can support the applications requested service
(Admission Control)
Configuration: When the network configures the routers
along the path to support the negotiated flow
characteristics.
The applications use
RSVP: Resource Reservation Protocol.
Goals for the Design of RSVP:
• Must support both unicast and multicast traffic flows
(i.e., RSVP sessions).
• Must allow parties of a multicast session to request
different levels of QoS.
• Must be deployable on top of existing IP infrastructure.
Basics of RSVP:
• Performs resource reservations for unicast and multicast applications.
• Requests resources in one direction from a sender to a receiver (simplex
resource reservation)
• Requires the receiver to initiate and maintain the resource reservation.
• Maintains soft state at each intermediate router: A resource
reservation at a router is maintained for a limited time only, and so the
sender must periodically refresh its reservation.
• Does not require each router to be RSVP capable.
• Non-RSVP capable routers use Best Effort delivery technique.
• Provides different reservation styles so that requests may be merged in
several ways according to the applications.
• Supports both IPv4 and IPv6.
RSVP: Receiver Initiated Reservation
• Similar to “Leaf Join Case” in ATM Multicasting.
• Motivation: RSVP is primarily designed to support multiparty
conferencing with heterogeneous receivers.
• In this environment the receiver actually knows how much bandwidth
it needs.
• If the sender were to make the reservation request, then the sender
must obtain the bandwidth requirement from each receiver.
• This may cause an implosion problem for large multicast groups.
Problem: Receiver does not directly know the path taken by data packets.
Solution: Use Path messages.
RSVP
The application source transmits a “Path” message along the
routed path to the unicast or multicast destination.
– The Path message has two purposes:
* to mark the routed path in each router (store the
“path state”) between sender/receiver and
* to collect information about the QoS viability
of each router along that path.
– Upon receiving the Path message, the destination host(s)
can determine what services the network can support
(e.g., guaranteed service or controlled load) and then
generate an RSVP reservation (Resv) message.
• Resv messages are sent back towards the sender along the
reverse path.
• The Resv message carries reservation requests to the routers
along the path.
• The Resv message contains traffic and QoS objects that are
processed by the traffic control component of each router as
it follows the reverse path upstream toward the sender.
• If the router has sufficient capacity, then resources along the
path back towards the receiver are reserved for that flow. If
resources are not available, RSVP error messages are
generated and returned to the receiver.
SOFT STATE in RSVP
• RSVP Path and Resv messages are periodically sent by
senders and receivers, respectively, to refresh the
reservations performed.
• When a state is not refreshed within a certain time out,
the state is deleted.
• The type of state that is maintained by a timer is called
“Soft State” as opposed to hard state where the
establishment and teardown of a state are explicitly
controlled by signaling messages.
RESERVATION STYLES in RSVP
• Wildcard Filter Reservation
A single reservation shared by all senders. Kind of shared
pipe whose resource is the largest of the resource requests
from all receivers, independent of the number of senders.
(e.g., Audioconferencing).
• Fixed Filter Reservation
A distinct reservation is created for each sender. S_i is the
selected sender and Q_i is the resource request for sender i.
The total reservation on a link for a given session is the sum
of all Q_i’s.
• Shared Explicit Reservation
A single reservation shared by a set of explicit senders where
S_i is the selected sender and Q is the flowspec.
9.2.3. Flow Specification (flowspec)
An RSVP reservation request consists of flowspec and filterspec.
• flowspec is used to set parameters in the router’s packet scheduler.
• flowspec (Flow Specification) consists of traffic specification (Tspec)
(T for traffic) and a service request specification (Rspec) (R for
reserve).
• Tspec describes the sender’s traffic characteristics, i.e., it specifies
the traffic behavior of the flow in terms of a token bucket.
• Rspec reserves a service class which defines the requested QoS,
i.e., it specifies the requested QoS in terms of bandwidth, packet
delay or packet loss.
• flowspec is carried by RSVP messages into the network and
defines the application’s QoS requirements as a series of objects,
such as token bucket parameters.
9.2.3. Traffic Control Components (filterspec)
filterspec (Filter Specification) provides the information
required by the packet classifier to identify the packets that
belong to the flow.
• Classifier - examines the source and destination
addresses, and port number fields in each packet to
determine what class the packet belongs to.
• Scheduler - determines which packet will be served
next.
• Admission Control - determines whether a new flow
can be granted the requested QoS without affecting
other flows existing in the network.
9.2.5. Traffic Classes Components
• Best-Effort - same as in the traditional IP networks.
• Controlled Load - approximates a best-effort over an
uncongested network.
• Guaranteed Service - supports real-time traffic flows
that require a delay bound.
Controlled Load Service
• Under CL service, the packets of a given flow will
experience loss and delays comparable to a network
with a light traffic load, assuming the flow complies
with the traffic contract.
• No guarantees are provided but both loss probability
and delay are expected to be very low.
• The application provides the network with an estimate
of the traffic it will generate. This estimate is done by
specifying the data flow’s desired traffic parameters
(Tspec) to the network element.
Controlled Load Service
Tspec (Traffic Specification) Model:
• It is a refinement of the Token Bucket model.
• A source characterizes itself with the following
SENDER-Tspec (traffic characteristics) parameters:
* Token bucket rate r (bytes/sec) and size b (bytes)
* Peak data rate p
* Minimum policed unit m
* Maximum packet size M
Controlled Load Service
• Admission Control is performed in order to deliver the expected
QoS.
• Traffic flows are policed. Non-conformant packets are either
dropped or delivered when possible using the best-effort service.
• Packets larger than the agreed maximum packet size will also be
considered as nonconformant.
• Adaptive real-time applications are supposed to use the controlled
load service. These applications perform well when the network is
not heavily loaded, but suffer rapid degradation in performance as
the network load increases.
Guaranteed Service
• GS guarantees the packets will arrive within a certain
delivery time, and that they will not be discarded due to
queue overflow, provided that the flow’s traffic
complies with the traffic contract.
• GS also uses the Tspec model. The service is requested
by a sender specifying Tspec and the receiver
subsequently requesting a desired service level (Rspec).
Guaranteed Service
Rspec (Reservation Specification) Model:
• Works together with the Tspec model to guarantee a desired service
level.
• The desired service level is described using the following parameters
(R data rate and S slack term)
in addition to r,b,p,m and M used for CL service:
– Data rate R is measured in the same units as r and must be equal
to or more than r (token rate). R reflects the theoretical service
rate that, at each router, will result in a desirable delay bound.
– Slack term S is measured in microsec and reflects how far each
router is allowed to deviate from the ideal delay bound, i.e.,
the difference between the desired delay and the delay obtained
by using a reservation level R.
REMARK: Larger values for R and smaller values for S represent stricter
delay bounds.
Guaranteed Service
• Making use of TSpec and RSpec, a certain
amount of bandwidth and buffer space is
allocated at each node for each flow.
• Resources are allocated using worst-case
analysis. Upper bounds for the end-to-end
delay and the packet loss probability can be
evaluated mathematically.
SIGNALING and ADMISSION CONTROL
Sources emit regular PATH messages downstream toward
the receiver(s) for reservation
• Two message objects relevant to IntServ are carried in
PATH messages: SENDER_Tspec (describing the traffic)
and ADspec (modified at each hop to reflect the network
characteristics between source and receiver).
• ADspec informs the receiver which service classes (CL, GS
or both) are appropriate for the traffic.
• Along the way, IntServ capable routers may modify the
ADspec relevant to reflect restrictions or modifications
required by the network.
SIGNALING and ADMISSION CONTROL
Receiver(s) respond with Resv messages upstream toward
the sender
• Receiver uses the SENDER_Tspec and (possibly modified)
ADspec to determine which parameters to send back
upstream in a flowspec element.
• flowspec selects either CL or GS and carries parameters
required by the routers along the upstream path to
determine whether the request can be honored or not.
• One message object relevant to IntServ is carried in Resv
messages: flowspec (describing the receiver’s desired QoS
service to be applied to the sources’ traffic).
9.2.6. IntServ Drawbacks
• Scalability – per flow resources reservation.
• Flexibility – IntServ provides a small number of prespecified traffic classes: Guaranteed and Controlled
Load Services.
• Efficiency – The Guaranteed Service of the IntServ
model is based on the worst case analysis and thus, is
very conservative. Moreover, bandwidth and delay
requirements are coupled, causing network inefficiency.
Resource Reservation Protocol
Drawbacks
• Complicated RSVP signaling (unidirectional, frequent
refresh messages).
• The current version of RSVP lacks both adequate
security mechanisms to prevent unauthorized parties
from instigating theft-of-service attacks, and policy
control.
Looking for a New Solution…
• Because of the difficulty in implementing and deploying
IntServ and RSVP, the IETF proposed the
Differentiated Services (DiffServ) architecture, the
current most promising approach to support IP QoS.
9.3. Differentiated Services (DiffServ)
• Solves scalability and flexibility problems:
• Forces as much complexity as possible to the edge
nodes which process lower volumes of traffic and lesser
number of flows.
• Offers service per aggregate traffic, rather than per
flow. Reservations are made for a set of related flows.
• It does not require new applications or extensive router
upgrades.
• It does not define specific services or service classes, as
IntServ does.
Differentiated Services
The objective of the DiffServ
working group is to propose
a small, well-defined set of
building blocks from which
a variety of services may be
constructed.
Complexity is moved from
the core of the network to
the edge of the network.
Packet forwarding in the core
network is simple and per-aggregate rather than per-flow.
Differentiated Services
The DS byte
• The DS byte is used to specify the
coincides with the
octet in IPv4 and
forwarding treatment (or per-hopTOS
behavior)
the Traffic Class octet
in IPv6.
to be used for a packet.
The DSCP (DiffServ Code Point)
byte is used to
specify the forwarding
treatment (or per-hop
behavior) to be used
for packets
Differentiated Services
•
A DiffServ Domain is a set of contiguous DS nodes defining the same per hop
behaviors (PHBs) and under the same policy strategy.
•
A DS domain consists of DS interior, edge, and boundary nodes. A boundary
node interconnects the DS domain to other DS or non-DS-complaint nodes.
Edge and interior nodes only connect to other interior, edge, or boundary
nodes within the same DS domain.
9.3.1. Edge and Core Nodes
• Edge nodes handle a relatively small number of traffic
flows. Therefore, they can execute per-flow traffic
management.
• Edge nodes are responsible for policing and shaping.
They are also responsible for admission control, if any.
• Core nodes handle a large amount of traffic flows. They
perform per-aggregate rather than per-flow traffic
management.
9.3.2. Traffic Classification and Conditioning
• Traffic Classification consists in assigning every packet
in a traffic stream to a defined traffic class.
• A Traffic Profile specifies the temporal properties of a
traffic stream selected by a classifier, providing rules
for determining whether a particular packet is inprofile or out-of-profile.
• Traffic Conditioning is usually executed by the
boundary nodes.
9.3.3. Traffic Conditioning Components
Meter
Packets
Classifier
Marker
Shaper/Dropper
– Meter: A meter measures the temporal properties of the stream of packets
selected by the classifier against a traffic profile.
– Marker: A packet is marked by setting its DS field to a particular codepoint.
The packet now belong to a certain behavior aggregate.
– Shaper: A shaper holds (delays) some or all the packets in a traffic stream to
make the stream to become compliant to the traffic profile.
– Dropper: A dropper discards some or all the packets in a traffic stream to bring
the stream into compliance with the traffic profile.
9.3.4. Per-Hop Behavior
• The PHB defines the service a packet receives at each hop as it is
forwarded through the network. It is realized through internal
queue management and scheduling techniques.
• 5 bits of the DS byte can be used to specify the PHB. Therefore,
(2^5) = 32 PHBs can be defined. The IETF intends to standardize
only a few of them.
• Packets marked with different DS byte values should receive
different PHB and, accordingly, should experience different services
in the core network.
• Services can be differentiated using appropriate
– Scheduling
– Queue Management
9.3.5. Scheduling
• Different output queues are used
for different PHBs.
• Queues can be served according
to
– Strict priority queuing
– Weighted Round Robin
– Weighted Fair Queuing
– Virtual Clock
9.3.6. Buffer Management
When a router runs out of buffer
space packets must be dropped.
In DiffServ, dropping decisions
take the DS byte value into account.
For example if Weighted Random
Early Detection (WRED) is used:
9.3.7. IETF Per-Hop Behaviors
• The IETF DiffServ Working Group is finishing
work on two PHBs:
– Expedited Forwarding (EF)
– Assured Forwarding (AF)
Expedited Forwarding PHB
• The EF PHB was designed to support low loss, low delay, and low
jitter connections. It appears as a point-to-point virtual leased line
(VLL) service between endpoints with a peak bandwidth.
• To minimize jitter and delay, packets must spend little or no time
in router queues.
• Therefore, the EF PHB requires that the traffic be conditioned to
conform to the peak rate at the boundary, and the network of
routers be provisioned such that this peak rate is less than the
minimum packet departure rate at each router in the network.
• The EF PHB uses a single DSCP bit to indicate that the packet
should be placed in a high-priority queue on the outbound link of
each router hop.
Assured Forwarding PHB
• The AF PHB defines four relative classes of service with each service
supporting three levels of drop precedence. Twelve distinct DSCP bit
combinations define the AF classes and the drop precedence within
each class.
• When congestion is encountered at a router, packets with a higher drop
precedence will be discarded ahead of those with a lower drop
precedence.
• The four AF classes define no specific bandwidth or delay constrains
other than that AF class 1 is distinct from AF class 2, and so on.
9.3.8. DiffServ Drawbacks
• The QoS enjoyed by a flow is dependent on the
behavior of the other flows belonging to the same
aggregate.
• There is no per-flow guarantees.
9.4. Multiprotocol Label Switching (MPLS)
• MPLS is a forwarding paradigm.
• Choosing the next hop can be thought as the
composition of two functions:
– Partitioning the entire set of possible packets into a
set of Forwarding Equivalence Classes (FECs).
– Mapping each FEC to a next hop.
• In the Multiprotocol Label Switching (MPLS), the
assignment of a packet to a particular FEC is done just
once: when the packet enters the network.
Multiprotocol Label Switching
• The FEC is encoded as a short fixed length value called
label.
• When a packet is forwarded to its next hop, the label is
sent along with it.
• At subsequent hops, there is no further analysis of the
packet network layer header.
• The label is used as an index into a table which specifies
the next hop and a new label.
• The old label is replaced with the new label and the
packet is forwarded to its next hop.
9.4.1. Service Classes
• Some routers analyze a packet’s network layer header
also to determine a precedence or class of service.
• They may then apply different discard thresholds or
scheduling disciplines to different packets.
• MPLS allows (but does not require) precedence or class
of service to be fully or partially inferred from the
label. In this case, the label represents the combination
of a FEC and a precedence or class of service.
9.4.2. The Internet Architecture
• The architecture of the Internet can be broken into
four basic layers:
– Physical Layer
– Link Layer
– Network Layer
– Transport Layer.
• The OSI models has three more layers on top of the
transport layer.
• MPLS is between the link and the network layer (2.5
layer).
9.4.3. Requirements
• MPLS forwarding must simplify packet forwarding with the following
objectives:
– Lower cost of high speed forwarding.
– Improve forwarding performance.
• MPLS core technologies must be general with respect to data link
technologies. Specific optimizations for particular media may be
considered.
• MPLS core technologies must be compatible with a wide range of
routing protocols, and must be capable of operating independently of
the underlying routing protocols.
• MPLS must provide protocol mechanisms to either prevent the
formation of loops and/or contain the amount of resources that can be
consumed due to the presence of loops.
• MPLS must allow aggregate forwarding of user data. MPLS
should provide multiple levels of aggregation support.
• MPLS must support operation, administration, and maintenance
facilities at least as extensive as those supported in current IP
networks.
• MPLS core technologies must work with both unicast and
multicast streams.
• Scalability issues must be considered and analyzed.
• The MPLS protocol standards must support multipath routing
and forwarding.
• MPLS must be compatible with the IETF Integrated Services
Model, including RSVP.
• MPLS switch must coexist with existing non MPLS switch in the
same switched network.
9.4.4. MPLS Advantages
• MPLS forwarding can be done by switches which are capable of
doing label lookup and replacement, but are either not capable of
analyzing the network layer header, or are not capable of doing it
at adequate speed.
• Since a packet is assigned to a FEC when it enters the network, the
ingress router can use any information it has about the packet,
even if that information cannot be gleaned from the network layer
header.
• The considerations that determine how a packet is assigned to a
FEC can become more and more complicated, without any impact
on the routers in the core network that merely forward labeled
packets.
• Packets can be forced to follow a particular route. This allows the
support of Traffic Engineering.
9.4.5. MPLS:
Traffic Engineering: An Example
9.4.6. MPLS Impact
• MPLS has an impact on both:
– The mechanisms used to forward packets within the Internet;
– The routing protocols used to determine the path that packets should take
while transiting the Internet.
• MPLS is altering the fundamental architecture of the Internet.
• These architectural changes will enable new services based on the
existing Internet infrastructure.
• MPLS is being employed because it has an immediate and direct
benefit to the network (faster forwarding).
• However, the long-term impact of MPLS is difficult to anticipate.
• This is, in part, one of the indicators of an architectural change, as
opposed to an evolutionary change.
9.5. Research Issues:
Integrated Services
• Accounting and billing need to be integrated into the
model in a scalable way.
• Authentication of RSVP users.
• RSVP scalability problems.
• Admission control, policing, and traffic shaping
schemes need to be defined.
9.6. Research Issues: Differentiated Services
• Allocate adequate resources to each traffic at each router.
• Definition of appropriate PHBs.
• Providing QoS guarantees with the DiffServ model
(absolute DiffServ vs. relative DiffServ).
• Perform a scalable and robust admission control.
• Map QoS services between DiffServ domains with different
traffic classes.
• Provide reservations in advance; Identify and classify
traffic in order to determine the appropriate traffic
handling mechanism to be applied.
• Support Multicast.
• Map DiffServ codepoints to ATM layer.
9.7. Research Issues: MPLS
• How to guarantee end-to-end QoS in a network
composed by MPLS-capable and MPLS-non-capable
routers.
• Rerouting techniques for fault recovery.
• Loop prevention.
9.8. Conclusions
•
•
•
•
•
•
IntServ and DiffServ both have great features and drawbacks.
A combination of both taking advantage of the benefits of each looks
promising.
IntServ could be implemented on the edge nodes and DiffServ on the core
network.
A mapping IntServ/DiffServ would be necessary.
RSVP is being changed by the IETF Integrated Services over Specific Link
Layers (issll) working group to overcome its drawbacks.
RSVP and DiffServ can be combined in such a way to realize the benefits of
each.
– RSVP would be disassociated from per flow traffic handling and signaling
messages would be processed only at select nodes.
• NGI will be a heterogeneous network, i.e., different IP technologies
will coexist making impossible to deliver end-to-end QoS with the
existing technologies.
• A new technology, capable of supporting this heterogeneity, is
necessary.