Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
37 views57 pages

Ip Qos and Mpls

Download as pdf or txt
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 57

2E1623

QoS, RSVP, and MPLS

IP QoS and MPLS

Outline
IP QoS (Quality of Service) Integrated Services (int-serv)
With RSVP signalling

Differentiated Services (diff-serv) Multiprotocol Label Switching MPLS

IP QoS and MPLS

Traditional IP Networking
Vanilla flavor of IP networking: Connectionless best effort service Each packet treated independently by routers (stateless) Route lookup based on dst IP address and longest prefix match No bandwidth guarantees Delay variations introduced along the path of a packet
IP QoS and MPLS

Advanced Packet Handling


Identifying packet flows in the network classification Give special treatment to each flow higher degree of service than BE After classification packet is placed in a certain queue for an outgoing interface
More specific than the traditional route lookup (dst IP addr and LPM)

ROUTER

. .
classification scheduler

IP QoS and MPLS

Defining a Flow
To recognize flows in the network, classification information is needed This information typically includes src/dst IP addresses and src/dst port numbers Routers along the path examines both IP and transport level headers to identify the flows

A flow can be specified by any combination of these fields Src IP addr Dst IP addr Protocol field ToS field IP hdr
IP QoS and MPLS

Src port number Dst port number

Other types of classification info: Link level header information VLAN header information Other extra headers that can exist

UDP hdr

payload

Functions in IP QoS
Classification
Identifying the packets belonging to a certain traffic flow

Policing
Ensure that the flow conforms to a traffic specification

Shaping
Smoothing out packet bursts (traffic is often bursty)

Scheduling
Manage packets in queues so that they receive desired service

Admission control
Check that there are enough resources to accept a new traffic flow

IP QoS and MPLS

IP QoS
There are basically two approaches by IETF for IP QoS: Integrated services (int-serv)
QoS architecture produced by IETF in the mid 1990s End-to-end guarantees for applications Uses a signaling protocol, RSVP, to make requests for QoS Includes service class definitions

Differentiated services (diff-serv)


Introduced by IETF in the late 1990s More coarse-grained model of QoS Allocates resources on a per class basis

IP QoS and MPLS

Integrated Services (int-serv)


RFC 2210 Reservation of resources (bandwidth, buffers) for application flows
src/dst IP addr, IP protocol field, UDP/TCP port numbers

RSVP is used to signal the reservation for each flow Three service classes for applications to choose from
Guaranteed Service hard guarantee of bandwidth and delay Controlled Load lower level of service Best Effort traditional IP service

IP QoS and MPLS

Guaranteed Service
RFC 2211 Guarantees:
Bounded delay Bandwidth No loss

Guaranteed service comes at a cost Every flow using the service must be queued separately Often results in rather low network utilization

Traffic described with:


Peak rate Max packet size Burst size Token bucket rate

IP QoS and MPLS

Token Bucket
Token bucket specification is a standard way to represent the bandwidth characteristics of an application that generates data at variable rate A traffic flow is characterized by a token bucket of rate r and burst size b, if for any time interval T, it sends no more than rT + b bytes
Token generator of rate r In practice, token bucket is implemented in bytes. In order to send a packet of n bytes, n tokens are needed

Bucket (of size b)

Packets

Send if token Outgoing packets

IP QoS and MPLS

Controlled Load
RFC 2212 Lower cost compared to guaranteed service Approximation of best effort in a lightly loaded network Network elements (routers) ensure that
There are enough resources to provide the specified QoS (admission control) The flows are queued and scheduled in a way that prevents other flows from degrading with their performance (all end-to-end flows do not have to be queued separately)

IP QoS and MPLS

Resource Reservation Protocol


RSVP is a network control protocol used to express QoS.
Binds a QoS request to a flow No application data Component in IETF int-serv RSVP is also used in other scenarios
Traffic Engineering/VPN

RSVP delivers QoS reservations along a path from source to destination(s).


no routing routing protocol computes path uses soft state periodically refresh

IP QoS and MPLS

RSVP Building Blocks


RSVP must carry the following information: Classification information
Flows with QoS requirements must be recognized within the network Includes src and dst IP addr and UDP/TCP port numbers

Traffic specification (TSpecs) QoS requirements (RSpecs)


Including desired service (guaranteed or controlled load)

from hosts to all routers along the path RSVP is explicitly designed to support multicast.
IP QoS and MPLS

RSVP Model
Receiver PATH msg (TSpec) Sender

RESV msg (RSpec) Receiver

Two types of messages to set up reservations: PATH message


From a sender to one or several receivers, carrying TSpec and classification information provided by sender

RESV message
From receiver, carrying RSpec indicating QoS required by receiver

IP QoS and MPLS

RSVP Model contd


A reservation is unidirectional The messages (PATH and RESV) are intercepted and forwarded by each router along the path Each router must take actions to do the actual resource allocation at each hop Once the reservation has been established, the routers along the path recognize packets by inspecting IP and transport protocol headers The packets recognized in this way is called a reserved flow Different receivers of the packet flow can have different QoS requirements (RSpecs)
IP QoS and MPLS

Functionality
RSVP is receiver oriented protocol.
The receiver is responsible for requesting reservations.

RSVP handles heterogeneous receivers.


Hosts in the same multicast tree may have different capabilities and hence need different QoS.

RSVP adapts to changing group membership and changing routes.


RSVP maintains Soft state in routers. The only permanent state is in the end systems. Each end system sends their RSVP control messages to refresh the router state. In the absence of refresh message, RSVP state in the routers will time-out and be deleted.

RSVP is not a routing protocol.


A host sends IGMP messages to join a multicast group, but it uses RSVP to reserve resources along the delivery path(s) for that group.

IP QoS and MPLS

RSVP Soft State


RSVP maintains soft state in hosts and routers Any state will automatically expire after some time unless it is refreshed periodically Routing protocol determines path dynamically Soft state is created by PATH and RESV messages Soft state is refreshed by PATH and RESV messages Time-outs clean up reservations

IP QoS and MPLS

RSVP and Router Operation


At each node, RSVP applies a local decision procedure admission control to the QoS request. If the admission control succeeds, it sets the parameters to the classifier and the packet scheduler to obtain the desired QoS. If admission control fails at any node, RSVP returns an error indication to the application. Each router in the path capable of resource reservation will pass incoming data packets to a packet classifier and then queue these packet in the packet scheduler. The packet classifier determines the route and the QoS class for each packet. The scheduler allocates a particular outgoing link for packet transmission. The packet scheduler is responsible for negotiation with the link layer to obtain the QoS requested by RSVP. The scheduler may also negotiate a CPU time.

IP QoS and MPLS

RSVP Summary
RSVP supports multicast and unicast data delivery RSVP adapts to changing group membership and routes RSVP reserves resources for simplex data streams RSVP is receiver oriented, i.e., the receiver requests resources (note that IP multicast is receiver-oriented) RSVP maintains a soft-state in routers
supports gracefully dynamic memberships and automatically adapt to routing changes

RSVP provides several reservation models RSVP is transparent for routers that do not support RSVP

IP QoS and MPLS

Differentiated Services (diff-serv)


Many drawbacks of int-serv
End-to-end connection setup and resource reservation
practically impossible: too many flows

State per flow


costly for routers

IETF started to develop another approachdiff-servin 1998


Basic definition: RFC 2474, RFC 2475 Divide traffic into small number of classes, and allocate resources per class Use aggregatesNo per-flow state Use Service Level Agreements (SLA) as contractsNo signaling Use bits in IP headerToS fieldto mark packets with their traffic class Flows are aggregated in the network so that routers need only distinguish between a small number of aggregated flows, even if those aggregates contain millions of individual flows.

IP QoS and MPLS

Diff-Serv Architecture
DS Domain DS Domain

DS Domain

DS boundary node

DS Domains
e.g., Autonomous Systems SLAs between domains: contract for diff-serv conditioning

DS interior node

Traffic is classified, marked and policed at ingress Resources are provisioned in the network Packets are queued, forwarded and dropped according to marking

DS Boundary Nodes
Egress/Ingress

DS Interior Nodes

IP QoS and MPLS

Packet Marking and Aggregation


Each packet is marked with a DSCP (Differentiated Services Code Point) directly in the 8-bit IP ToS header field
6 bits used 64 possible code points (in practice much less is used) Code points are unique within a domain but may change at domain borders

An ingress node aggregates packets into behavior aggregates, each marked by a unique code point (DSCP) DSCP
8-bit ToS Field IP header IP payload

IP QoS and MPLS

Per Hop Behavior (PHB)


The code point is used to select a specific Per-Hop Behavior (PHB) within the domain
A PHB defines how packet should be treated by the router Forwarding behavior: e.g. scheduling, shaping, etc

Standard PHBs include


Default (no special treatment) Expedited forwarding EF (described later) Assured forwarding AF (described later)

PHB Group
A set of PHBs with similar handling E.g. one traffic class with many levels of drop priority (or drop preference)

IP QoS and MPLS

Set DSCP and do PHB


DSCP is generally set as packets cross an administrative domain

DCSP value set in packet based on local policy

PHB determined from DSCP; PHB determines QoS treatment

IP QoS and MPLS

Traffic Conditioning
in/out of profile
Packets

Classifier

Meter

Marker

Shaper/ Dropper

Typically, the ingress node performs traffic conditioning on incoming packets according to the SLA with the upstream domain The metering measures the rate of packets. Consequences:
mark packets in one PHB group to be in-profile/out-of-profile may result in shaping and dropping

IP QoS and MPLS

Traffic Conditioning contd


Metering
Token Bucket (specifies the traffic) Measure temporal properties (does traffic conform to spec) Three Color markers (RFC 2697, RFC 2698)

Policing: Shaping and dropping


Delay packets to bring a stream into conformance Drop packets (several strategies can be used)
Tail drop Random Early Discard

IP QoS and MPLS

Expedited Forwarding PHB (EF)


RFC 3246 DSCP = 101110 EF marked packets should be forwarded with minimal delay and experience low loss Specify a min-rate r and max-rate R The rate at which the traffic is served at a given output interface should be at least r over a suitably defined interval, independent of the offered load of non-EF traffic to that interface. Typically: separate queues for best effort and EF with strict priority
IP QoS and MPLS

Assured Forwarding PHB Group (AF)


RFC 2597 Four separate classes
Each class has a specific set of resources (buffers/bandwidth) and its own queue E.g. Gold, Silver, Bronze service

Three levels of drop preference in each class (green, yellow, red) In-profile packets (green) get assured QoS Out-of-profile packets get best effort sevice or are dropped Class 1
Low Drop Pref Medium Drop Pref High Drop Pref 001010 001100 001110

Class 2
010010 010100 010110

Class 3
011010 011100 011110

Class 4
100010 100100 100110

IP QoS and MPLS

Multi-Protocol label Switching


MPLS

IP QoS and MPLS

Background
In the late 1990s (1995-1997) several new techniques to simplify IP forwarding appeared Basic idea was to combine IP routing protocols with a forwarding algorithm based on a header with fixed length label instead of the longest prefix match on the destination IP address in the IP header This resulted in an IETF standardization work, called MPLS (Multiprotocol Label Switching)
Lots of RFCs regarding MPLS (overview in RFC 3031)

At the time these techniques were introduced there was a lot of debate regarding IP versus ATM, the label switching techniques were attempts to marry ATM cell forwarding with IP routing protocols
IP QoS and MPLS

MPLS Advantages
Originally, it was claimed that label switching routers (LSRs) would be much faster thanks to simplified forwarding (fixed size label versus longest prefix match) Performance argument may not be valid anymore, but Label switching makes it possible to make forwarding decisions based on more complex criterias than IP dst address, but still keeping a simple lookup
New routing services, same forwarding paradigm

Label switching can be used for traffic engineering


Route control

Label switching can be used to support VPNs


IP QoS and MPLS

Forwarding Equivalence Class (FEC)


Think of procedures used by the forwarding component as a way of partitioning the set of all possible packets a router can forward into a finite number of disjoint subsets. Such a subset is referred to as an FEC MPLS makes forwarding decision based on FEC belonging (labeling) Mapping between information in the packet headers and the entries in the forwarding table is many-to-one (grouping of packets) Example:
A set of unicast packets whose IP address matches a certain prefix and whose ToS bits are the same

FEC can be of
Coarse granularity (essential for scalability) Fine granularity (needed for flexibility)

IP QoS and MPLS

Control and Data Planes


LSR
Label distribution Control Plane (Binding Layer) LFIB MPLS packet MPLS packet IP packet Label distribution OSPF IS-IS BGP

Router
Control Plane (Routing Layer) FIB IP packet OSPF IS-IS BGP

Data Plane (Forwarding Layer)

Data Plane (Forwarding Layer)

IP QoS and MPLS

Regular IP Network

MPLS Forwarding
MPLS cloud

Regular IP Network

Add label

Remove label

Eth hdr Label hdr

IP hdr

IP payload

Label applied at ingress LSRlabel is bound to an FEC Forwarding based on label in MPLS cloud (transit LSRs) Label removed at egress LSR
IP QoS and MPLS

Label binding
A label is bound to a FECidentifying that flow Labels cannot be global or network-unique
Too complex to negotiate Too large labels

Labels are unique only between two nodes Labels change at each LSR as a packet traverses a path Labels are assigned by the downstream LSR Example of LFIB:
Incoming label Z Outgoing label V Outgoing interface if2

IP QoS and MPLS

Label Switched PathLSP


LSP IP pkt IP pkt l=x IP pkt l=z IP pkt l=y IP pkt l=v IP pkt

Two mechanisms to do path selection: Independent


Hop-by-hop Regular routing protocol to select the path

Ordered
Explicit routing Path completely specified by edge LSR

IP QoS and MPLS

Encapsulation
20-bit label 3-bit exp 1-bit stack 8-bit TTL

Eth hdr Label hdr

IP hdr

IP payload

Normally, MPLS uses a 32-bit shim header:


Label: value for table lookup in LSR TTL: Time To Live (resembles of IP TTL) Exp: experimental, several ways to support QoS has been defined Stack: indicates that the bottom of a stack of labels has been reached

Shim headers may be concatenated into stacks


IP QoS and MPLS

Label Stacking
lbl=6 lbl=3 IP pkt lbl=6 lbl=5 IP pkt lbl=7 lbl=3 IP pkt lbl=7 lbl=5 IP pkt lbl=3 IP pkt

lbl=3 IP pkt

lbl=5 IP pkt Transit Routing Domain

lbl=5 IP pkt

Used when packet forwarded through transit routing domain Push label onto stack at ingress LSR, pop label at egress LSR

IP QoS and MPLS

Label Assignment 1Independent


40

40
40

40

Label binding: Label 40 with 192.168.20.0/24

Independent control LSR assigns labels to every FEC it knows Typically, each IP address prefix will get an assigned label IP routing protocols have been used to obtain the prefixes Fast way to establish an LSP Upstream nodes will use label 40 for IP packets to 192.168.20.x

IP QoS and MPLS

Label Assignment 2Ordered

40

67

Label binding for 192.168.20.0/24

Ordered control Label assignment occur in ordered manner Initiated either by ingress or egress LSR of an LSP Used to ensure that a FEC follows a specific path (LSP) All LSRs use the same FEC as the initial advertiser Gives more control, but results in slower LSP establishment
IP QoS and MPLS

Label Distribution
MPLS includes a control component for signaling between LSRs to set up an LSPlabel distribution
Once an LSR creates or destroys a binding between a locally chosen label and an FEC, the LSR needs to inform other LSRs of that binding. This will provide other LSRs with the remote label binding information.

Label distribution can be accomplished in several ways


LDP (Label Distribution Protocol) RSVP Piggybacking on top of routing protocolse. g., BGP
BGPBorder Gateway Protocol

IP QoS and MPLS

LDP
RFC 3036 (and follow-ups) LDP operates between LSRs
Directly connected LSRs Non-adjacent LSRs

LDP peers
use LDP to exchange label and FEC mapping info

FEC is either an IP address prefix or a host address


Logical exchange Logical exchange Logical exchange

LDP
IP QoS and MPLS

LDP LSR B LSR C

LSR A

LDP Message Categories


Discovery messages
Hello msg Sent over UDP to all routers on this subnet multicast address

Session messages
Establish sessions between LDP peers Sent over TCP

Advertisement messages
Create, change, and delete label mappings Sent over TCP

Notification messages
Provide status, diagnostic, and error information Sent over TCP

IP QoS and MPLS

LDP Label Distribution


1. FEC discovered 2. Advertise 1. Request FEC binding 3. Advertise Upstream LSR Downstream LSR Upstream LSR Downstream LSR 2. FEC exists

Downstream unsolicited advertisement mode Initiated by downstream LSR peer

Downstream on demand advertisement mode Initiated by upstream LSR peer

IP QoS and MPLS

MPLS and RSVP


PATH PATH PATH

RESV

RESV

RESV

The reserved flow can be seen as a new FEC RSVP can express QoS
Each LSR can easily associate QoS resources with LSP

Only the first router needs to be concerned with which packets belong to the flow Micro-flows can be aggregated
IP QoS and MPLS

RSVP and Label Distribution


PATH, lbl req PATH, lbl req PATH, lbl req

RESV, lbl=9

RESV, lbl=5

RESV, lbl=6

RSVP well suited to distribute labels


LABEL object defined and carried in RESV message LABEL_REQUEST object defined and carried in PATH message

Downstream-on-demand label distribution

IP QoS and MPLS

RSVP Extensions for MPLS


RFC 3209, RFC 3936 Setting up LSP with or without resource reservations LSP rerouting Load balancing Constrained routing (or explicit routing)
specify route for the LSP Loose and strict routing supported

Loop detection

IP QoS and MPLS

BGP and Label Distribution


BGP is widely used for routing between autonomous systems (AS) RFC 3107 and RFC 2858 specify how to carry label information in BGP messages (BGP-4) When BGP distributes a route:
BGP Update message is sent Also distribute an MPLS label mapped to the route Label is piggybacked in the BGP Update

BGP plays an important role when MPLS is used for VPNs

IP QoS and MPLS

BGP and Label Distribution, contd


Assume BGP peers are 2 adjacent LSRs
Label distribution can be done without need for any other label distribution protocol

Assume BGP peers are not adjacent LSRs


See figure An LSP must be present for A to be able to use label L!
BGP Update, mapping Lbl Z to new route BGP peer Lbl X Lbl Y Lbl Z BGP peer

Push L, Push X

X Y Data

Y Z

Pop X, Pop L

IP QoS and MPLS

MPLS and Traffic Engineering (TE)


TE deals with network performance and supporting customers Traffic measurement Traffic control
Ensure that there is enough resources

Purpose why a provider needs traffic engineering: Parts of the network is congested and other parts underutilized Use RSVP to assign QoS In short: a provider wants to control the traffic Map traffic streams to available network resources RFC 2702
IP QoS and MPLS

MPLS TE, contd


Load distribution
Distribute traffic across parallel traffic trunks
Each trunk carries a portion of the total load

Distributed traffic across diverse paths (LSPs)


Different nodes in the network

Protection switching
Predefined secondary LSP Rebuild LSP Rebuild LSP segment

Load distribution can be done at L2 and L3! Protection switching can be done at L2 and L3!
IP QoS and MPLS

Why not Routing Protocols for TE?


Hard to claim that routing cannot be used, but: Regular plain IP routing not considered enough: Destination-based, least-cost routing not always efficient
Shortest path not always optimal path

Link metrics generally not the solution Does not take into account available bandwidth on individual links

IP QoS and MPLS

MPLS Support for Diff-serv


Ensure that packets marked with DSCPs receive appropriate QoS treatment at each LSR 2 ways to determine appropriate PHB from label header: Use the 3-bit Exp field in the label header
Sufficient if not more than 8 classes are to be supported No additional signaling needed LSP using the Exp field in this way is called an E-LSP

Use the label to convey the PHB


Can support more than eight classes Label distribution mechanisms must be enhanced Such an LSP is called an L-LSP
IP QoS and MPLS

BGP/MPLS IP VPNs
RFC 4364 VPN - Virtual Private Networks MPLS well suited for provider supported VPNs The service provider can
Bundle all traffic from one customer into one LSP. Assign QoS to the LSP via RSVP Use traffic engineering Use BGP to distribute VPN routes between edge routers

IP QoS and MPLS

BGP/MPLS IP VPNs
lbl=6 lbl=3 IP pkt lbl=6 lbl=5 IP pkt lbl=7 lbl=3 IP pkt lbl=7 lbl=5 IP pkt lbl=3 IP pkt PE Service provider VPN B CE lbl=5 IP pkt lbl=5 IP pkt Transit Routing Domain CE VPN B PE CE VPN A

CE VPN A

lbl=3 IP pkt

CECustomer Edge routers PEProvider Edge routers PEs are BGP peers and use BGP to distribute VPN routes Label stacking to provide MPLS tunnel for the VPNs Core routers unaware of VPN routes

IP QoS and MPLS

BGP/MPLS IP VPNs, contd


Site 2 VRF Table Site X VRF Table Site 2 VRF Table Site 1 CE Site 1 VPN A PE

Each VPN site must contain one or several CEs CE attached to PE(s), through attachment circuit
network interface or a VLAN ID

PE maintains one routing table per attachment circuit


VRFVPN Routing and Forwarding table.

IP QoS and MPLS

Summary
Basics about traditional best-effort IP and IP QoS Two models proposed by IETF:
Integrated services (int-serv)
Flow based end-to-end signaling

Differentiated services (diff-serv)


More coarse-grained, less complex, using service classes

Resource reservation protocol (RSVP) Multiprotocol label switching (MPLS)


Forwarding based on labels Label distribution (LDP, RSVP) Application of MPLS (Traffic Engineering, Diff-serv, VPNs)
IP QoS and MPLS

You might also like