NANOG36-NOTES 2006.02.13 talk 7 QoS in MPLS environments

Matthew Petach mpetach at netflight.com
Mon Feb 13 23:19:02 UTC 2006


Here's my notes from the MPLS QoS tutorial; wish I could have
been in two places at once to catch the ISPSec BOF as well.
I won't be taking notes at Eddie Deens, though, so it'll be up
to Ren's camera to capture the details for those following along
at home.  < http://nanog.multiply.com/ >

Matt



2006.02.13
QoS in MPLS networks tutorial notes.

See notes for Agenda, outline, etc. at
http://www.nanog.org/mtg-0602/sathiamurthi.html

Traffic characterizations go beyond simple DiffServ
bit distinctions
Understand traffic types and sources and nature
of traffic before

Latency,
Jitter,
Loss
three traffic parameters to be tracked that influence
choices made when applying QoS

It's all about managing finite resources
 rate control, queing, scheduling, etc.
 congestion management, admission control
 routing control traffic protection

The QoS Triangle (no, not bermuda triangle)

Identify Traffic Type
Determine QoS parameters
Apply QoS settings

2 approaches to QoS
fine-grained approach
or
combination of flows to same traffic type, to same
 source.  Needs to have same characteristics so you
 can consider them as an aggregated flow.

Best Effort is simplest QoS
Integrated services (Hard QoS)
Differentiated Services (soft QoS)

Best Effort is simple, traditional internet

Integrated services model, RFC 1633, guarantees per
flow QoS
strict bandwidth reservations.
RSVP, RFC 2055, PATH/RESV messages
Admission controls
must be configured on every router along path
Works well on small scale.  Scaling challenge with large
 numbers of flows.
 What about aggregating flows into integrated services?

DiffServ arch; RFC 2475
scales well with large flows through aggregation
creates a means for traffic conditioning  (TC)
defines per-hop behaviour (PHB)
edge nodes perform TC
  keeps core doing forwarding
tough to predict end to end behaviour
 esp with multiple domains
 how do you handle capacity planning?

Diff services arch slide with pictures of
traffic flow.

TCA prepares core for the traffic flow that
will be coming in; allows core to do per-hops
behaviour at the core.

IETF diffserv model
redefine ToS byte in IP header to differentiated services
code point (DSCP)
uses 6 bits to define behaviour into behaviour aggregates.

Class Selector (CS0 through CS 7)

classifier; selects packets based on headers.

Classification and Marking
flows have 5 parameters; IP src, dest, prececedence,
DSCP bits,

You can handle traffic metering via adjusting the
three flows.


3 parameters used by the token bucket;
committed information rate
conformed and extended burst size

Policing vs shaping.
policing drops excess traffic; it accomodates bursts;
anything beyond that gets dropped; or, can be re-marked.

Shaping smooths traffic but increases latency.
buffers packets.

policing
uses the token bucket scheme
tokens added to the bucket at the committed rate
depth of the bucket determines the burst size
packets arriving when there's enough tokens in the bucket
are conforming
packets arriving when the bucket is out of tokens are
non-conforming; either coloured, dropping, etc.

diagram of token bucket, very nice.

shaping--use the token bucket scheme as well
smooths through buffering
queued packets transmitted as tokens are available.

1 aspect is traffic conditioning at edge
2 aspect is per hop behaviour

PHB relates to resource allocation for a flow
resource allocation is typically bandwidth
 queing / scheduling mechanisms
 FIFO/WFQ/MWRR(weighted)/MDRR (deficit)
congestion avoidence
 RED (random early detection / Weighted random early drop

Queing/scheduling
needs some data mining to decide how to prioritize certain
classes of traffic.
de-queues depends on weights assigned to different flows.

Congestion avoidance technique
 when there is congestion what should happen?
 tail drop (hit max queue length)
 drop selectively but based on IP Prec/DSCP bit
Congestion control for TcP
 adaptive
 dominant transport protocol

Slide showing problem of congestion; without technique,
have uncontrolled congestion, big performance impact
due to retransmissions.

TCP traffic and congestion
congestion vs slow-start
 sender/recieever negotiate on it.
 source throttles back traffic.
 (control leverages this behaviour)

Global synchroniztion happens when many flows pass through
a congested link; each flow going through starts following
the same backoff and ramp up, leads to sawtooth curves.

RED
a congestion avoidance mechanism
works with TCP
uses packet drop probability and avg queue size
avoids global synchronization of many flows.
minimizes packet delay jitter by managing queue size

RED has minimum and maximum threshold; average queue
size is used to avoid dealing with transient bursts.
WRED combines RED with IP precedence or DSCP to
implement multiple service classes
each service class has its own min and max threshold and
 drop rate.

nice slides of lower and higher thresholds for different
traffic types.

When is WRED used?  only when TCP is bulk of traffic.
Won't help UDP or other IP

MPLS and QoS, into DiffServ
avoid vendor CLI as much as possible for the talk.
stick with techniques only.
do classification and marking at edge, then do per
hop behaviour on when to queue or drop packets within
the core.

Within the MPLS domain, do you lose all the nice
classification information?
No, you tunnel information from IP DiffServ into MPLS
DiffServ.

MPLS DiffServ
doesn't introduce new QoS architecture
uses diffserv defined for IP QoS (RFC 2745)
MPLS DiffServ is defined in RFC3270
uses MPLS shim header

show slide of diffserv scalability via aggregation
traffic enters at PE router, goes through P core,
comes out PE at other side.
MPLS scalability comes from
 aggregation of traffic on the edge
 processing of aggregate only in the core
deal with buckets only, thus can scale well.
the PE router has to put 2 labels on; next router

What's unchanged in MPLS diffserv?
traffic conditioning agreements
same classification, marking, shaping, policing still
happen at the edge
buffer management adn packet scheduling mechanisms
used to implement PHB

PHB definitions
 EF: low delay/jitter/loss
 AF: low loss
 BE: no guarantees (best effort)

what's NEW in MPLS diffserv?
Prec/DSCP field not visible to MPLS LSRs
info on diffserv must be made visible to LSR in
MPLS header using EXP field/label
how is DSCP mapped into EXP--some interation between them.
EXP is 3 bits, S is 1 bit.

Typical mapping
Expedidted forwarding: EF DSCP 6 bits to 3 bits of EXP bits.
101000 maps to 101
but then you lose bits of informatin.
IP DSCP 6 bits whle MPLS EXP = 3bits (RFC 3270)
if 8 or less PHBs are used, map DSCP to EXP directly,
with E-LSPs with preconfigured mappings
If more than 8 PHBs, needed to be mapped in label
and EXP; L-LSPs are needed

Both E-LSP and L-LSP can use LDP or RSVP for label
distribution.

MPLS: flows associated with FEC mapped to one label
DS: flows associated with class, mappable to EXP

MPLS diffserv tunneling modes
Based on RFC 3270
Modes
 uniform
 short-pipe
 pipe

how do you implement the modes?  depends on your
engineering decisions.

uniform mode
assume the entire admin domain of the SP is under single
diffserv domain
then like a requirement to keep colouring info the same
(uniform) when going from IP to IP, to MPLS, back again,
etc.

in both MPLS to MPLS and to IP cases, tehe PHB of the
topmost popped label is copied into the new top label
or the IP DSCP if no label remains.

Short pipe mode
assume an ISP network implmementing a diffserv model
assumes customers implement a different policy.

note that the policy applied outbound on egress
interface is basd on DSCP of the customer, hence the
short-pipe naming.

Pipe-mode
same as short-pipe
however, SP wants to drive the outbound
PHBs of the topmost popped label is copied to the new
top label
classification is based on mpls-exp field (EXP=0) of the
topmost received MPLS frame


MPLS TE and DiffServ
is diffserv good enough to determine end to end quality
of service?  nope.
what happens if there's no congestion, but a link
fails?
when link fails, and reroute happens across a new
link; the new link gets congested due to combined
traffic.
You may need to engineer your traffic on non-optimal
path to assure enough bandwidth will be ready for it.

So you have BW optimization and congestion management
in parallel
TE + DiffSErve
spread traffic around with more flexibility than IGP
supports.

MPLS labels can be used to engineer explicit paths
tunnels are uni-directional

How does MPLS TE work?
Explicit routing
constraint-based routing
admission control
protection capabilities
RSVP-TE to establish LSPs
ISIS and OSPF extensions to advertise link attributes

Diffserv aware TE
per-class constraint based routing
per class admission control
so best effort can go on one link, while low-latency
can be shifted along a different link.

Link BW distributed in pools of BW constraints (BC)
up to 8 BW pools
different BW pool models

Maximum Allocation Model (MAM)
Maximum Reservable Bandwidth (MRB)
BC0: 20% Best Effort (admission class 1)
BC1: 50% Premium     (admission class 2)
BC2: 30% Voice       (admission class 3)

Per class traffic engineering concept; all 3 sum to MRB
If for any reason the part of traffic hard reserved isn't
 being used, it's wasted; nobody gets to burst into it.
 No sharing of unused capacity.  But simple, independent.

DS-TE BW Pools--Russian Dolls Model (RDM)
BW pool applies to one or more classes
Global BW pool (BC0) equals MRB
BC0...BCn used for computing unreserved BW for
class n
so BC0: MRB (best effort + premium + voice)
   BC1: 50% premium + voice
   BC2: 30% Voice

Downside is higher bandwidth class may push out some
lower traffic that was flowing already.

Aggregate TE in diffserv network

DS TE and QoS
Diffserve-TE doesn't preclude the necessity of configuring
PHB QoS in the TE path;  DiffServ TE operates in conjunction
with QoS mechanisms.

Traffic engineering is a huge field; so it's hard to cover
in a short period of time.

Summary:
QoS techniques
 effective allocation of network resources
IP DiffServ
 Service Differentiation
 good starting point, bu doesn't scale that well
MPLS and DiffServ
 Builds scalable networks for service providers
DiffServ Tunnelling modes
 Scalable and flexible QoS options
 Supports Draft Tunneling Mode RFC
DiffServ TE
 provides strict point-to-point guarantees
 pipe models are your choice, how do you want to
 architect your network?  What are _your_ traffic
 needs?

When you need to drop traffic, determine how you'll
drop traffic based on DSCP bits so you can set
watermarks on the traffic; some traffic more
lenient about drops, other traffic not so lenient
about drops.

Question: Fred W. from Bechtel.
With IPv6, there's a 20 byte flow label, rather than
the 8 bit agony of mapping the v4 DSCP bits; does that
give more flexibility, more choices, are there fewer
headaches associated with v6 QoS handling?
Short answer--the presenters aren't as focused on v6
development, so they don't have a concrete answer to
give there, sorry.

That wraps up the presentation/tutorial at 1715 hours
pacific time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060213/ab57aad0/attachment.html>


More information about the NANOG mailing list