CSE 5346 Presentation MultiProtocol Label Switching

1
CSE 5346 Presentation Multi-Protocol Label
Switching

• Shyam Ramprasad
• Pradeep Kumar

2
Agenda

• RFC 3564 - Requirements for Support of
  Differentiated Services-aware MPLS Traffic
  Engineering 
• RFC 3443 - Time To Live (TTL) Processing in
  Multi-Protocol Label Switching (MPLS) Networks 
• RFC 3353 - Overview of IP Multicast in MPLS
  Environment

3
Requirements for support of Diff-Serv aware
Traffic Engineering

• DiffServ used to achieve scalable designs for
  multiple classes of traffic
• MPLS may be used on some DiffServ networks, where
  optimization is not a criterion
• For better optimization, TE may be performed on
  per-class level
• Map traffic from a DiffServ class of service to a
  separate Label Switched Path (LSP), can utilize
  resources and paths available to that class

4
Some Definitions

• Behaviour Aggregate (BA) Collection of objects
  with same codepoint crossing a link in a
  direction
• Per-Hop Behaviour (PHB) Externally observable
  forwarding behaviour
• PHB scheduling class (PSC) PHB group in which
  ordering of packets in a microflow must be
  preserved
• Ordered Aggregate (OA) Set of BAs that share an
  ordering constraint
• Traffic Aggregate (TA) Collection of packets
  with a codepoint that maps to the same PHB
• Per-Domain Behaviour (PDB) Expected treatment a
  group of packets will receive
• Traffic trunk Aggregation of traffic flows (same
  class) in an LSP

5
Mapping of traffic to LSPs

• Network may have multiple TAs.
• Several options to service them
• Not to split set of ltFEC/TAPSCgt, each Traffic
  trunk has one PSC. Used in MPLS TE mechanisms
• Split ltFEC/TAPSCgt into multiple traffic trunks
  based on class of service. Can consider
  individual traffic and engineering constraints
• Note Split can be done also for load balancing

6
Application Scenarios

• Limiting proportion of classes in a link
• Maintain relative proportion of traffic
• Guaranteed bandwidth services

7
DS-TE compatibility

• DS-TE may be used when existing practices are not
  good enough
• Impact scalability and operational practices
• There should be no interoperability issues and
  deploy DS-TE to required level of granularity

8
Bandwidth Constraints

• Bandwidth constraint model set of rules defining
  max. number of bandwidth constraints, and which
  Class type they apply to
• Refer to Bandwidth constraint as Bcb,
  0ltbltMaxBC-1
• DS-TE solution must have capability to support
  multiple BC models

9
Mapping of Traffic to LSPs

• DS-TE solution must allow operation over E-LSPs
  for single ltFEC/TAPSCgt
• Must allow operation over L-LSPs
• DS-TE solution must allow operation over E-LSPs
  for multiple ltFEC/TAPSCgt, under condition that
  multiple classes can be treated as a single
  atomic traffic trunk

10
Other requirements

• Dynamic adjustment of DiffServ PHBs
• Overbooking
• Restoration

11
Solution Evaluation

• Satisfying detailed requirements
• Flexibility
• Extendibility
• Scalability
• Backward compatibility

12
TTL Processing in MPLS networks

• Time to live in hierarchical Multi-Protocol Label
  Switching (MPLS) networks
• Need to formalize a TTL-transparent mode
  operation in an MPLS switched path
• Updates RFC 3032 MPLS Label stack encoding
• Complements RFC 3270 MPLS support of DiffServ

13
About this RFC

• New mode of operation Pipe model
• Packets transiting the LSP view the path as
  single hop (irrespective of number of
  intermediary hops)
• Currently used in multiple networks
• Configured by the network operator
• Covers other topics like uniform model,
  hierarchical LSPs, TTL processing in Penultimate
  hop popping

14
Terminology

• MPLS packets use a shim header
• MPLS label (20 bits)
• TTL (8 bits)
• Bottom of stack (1 bit)
• Experimental bits (3 bits) redefined later as
  scheduling and shaping bits
• Two models in MPLS Pipe and Uniform
• Pipe Only ingress and egress points are visible
• Uniform All traversed nodes all visible
• TTL processing incoming TTL and outgoing TTL
  processing

15
Terminology (new)

• iTTL Incoming TTL (no checks)
• oTTL Outgoing TTL default iTTL-1
• oTTL check (Check oTTLgt0)
• If false, packet not sent
• Performed only if outgoing TTL is set to oTTL

16
TTL processing in uniform model (with(out) PHP)

• LSPgt
• --Swap--(n-2)-...-swap--(n-i)---
• / (outer header)
  \
• (n-1) (n-i)
• / \
• gt---(n)--Push...............(x)..................
  ...........Pop--(n-i-1)-gt
• (I) (inner header) (E or P)
• (n) TTL value in the corresponding header
• (x) non-meaningful TTL information
• (I) LSP ingress node
• (P) LSP penultimate node
• (E) represents the LSP Egress node
• Note inner and outer TTLs are synchronized at
  tunnel ingress and egress

17
TTL processing for Short Pipe Model LSPs (without
PHP)

• LSPgt
• --Swap--(N-1)-...-swap--(N-i)---
• / (outer header)
  \
• (N)
  (N-i)
• / \
• gt--(n)--Push...............(n-1).................
  ..................Pop--(n-2)-gt
• (I) (inner header) (E)
• (N) TTL value (may have no relationship to n)
• (n) tunnelled TTL value in the encapsulated
  header
• (I) LSP ingress node
• (E) LSP egress node
• Note Forwarding at egress based on tunneled
  packet and not encapsulating packet

18
TTL Processing for Short Pipe Model (with PHP)

• LSPgt
• -Swap-(N-1)-...-swap-(N-i)-
• / (outer header) \
• (N) (N-i)
• / \
• gt--(n)--Push.............(n-1)....................
  ........Pop-(n-1)-Decr.-(n-2)-gt
• (I) (inner header) (P)
  (E)
• (N) represents the TTL value (may have no
  relationship to n)
• (n) represents the tunnelled TTL value in the
  encapsulated header
• (I) represents the LSP ingress node
• (P) represents the LSP penultimate node
• (E) represents the LSP egress node.
• LSP egress node just decrements header TTL
• At end of the LSP, TTL of the tunneled packet is
  decremented by 2

19
TTL Processing for Pipe Model LSP (without PHP)

• LSP gt
• --Swap--(N-1)-...-swap--(N-i)-----
• / (outer header) \
• (N) (N-i)
• / \
• gt--(n)--Push...............(n-1)..................
  .....................Pop--(n-2)-gt
• (I) (inner header) (E)
• (N) represents the TTL value (may have no
  relationship to n)
• (n) represents the tunnelled TTL value in the
  encapsulated header
• (I) represents the LSP ingress node
• (E) represents the LSP Egress node
• Note This model is identical to short pipe model
  (without PHP)

20
iTTL Determination

• IP packet iTTL is TTL value of the packet
• MPLS packet For push/swap/PHP, TTL value of the
  topmost incoming label
• MPLS and Pop iTTL based on tunnel type
• Pipe iTTL is TTL field of header
• Uniform iTTL is TTL of popped label
• Multiple pops iTTL of previous pop is used

21
oTTL Determination

• oTTL check performed after iTTL calculated
• IP packet oTTLiTTL-1
• MPLS 4 cases
• Swap Routed label swapped TTL is oTTL
• Swap and push Swap as above. Then tunnel ingress
  processing
• PHP Routed label is popped, do oTTL check. If
  short pipe, TTL not checked/updated. If uniform,
  TTL oTTL
• Pop Happens before routing

22
Tunnel Ingress Processing

• Each uniform model label, TTL copied from label
  below
• Pipe/Short pipe model TTL set by network
  operator (default 225).

23
Overview of IP Multicast in MPLS Environment

• Introduction
• Layer 2 Characteristics
• Taxonomy of IP Multicast Routing Protocols
• Mixed L2/L3 Forwarding in a Single Node
• Taxonomy of IP Multicast LSP triggers
• Piggy-backing
• Explicit Routing
• QoS/CoS
• Issues

24
1. Introduction
For multicast, an optimum solution is the Steiner
tree computation. Different multicast routing
protocols generate different trees.

• Framework for IP multicast deployment in MPLS
  environment
• Overview of possible issues
• Pros and cons of existing IP multicast routing
  protocols w.r.t MPLS

25
2. Layer 2 Characteristics

• MPLS can run on top of several L2 technologies
  PPP, Ethernet, ATM, FR etc.
• ATM offers high switching capabilities and QoS
  but has limitations ?
• Limited Label space
• Merging
• TTL-decrement

Impact implementation of multicast in MPLS
26
3. Taxonomy of IP Multicast RP

• Routing Protocol characteristics relevant to MPLS
  technology
• Aggregation
• Flood Prune
• Source/Shared trees
• Co-existence of Source and Shared trees
• Uni/Bi-directional Shared trees
• Encapsulated multicast data
• Loop-free-ness

27
3.1 Aggregation

• Unicast Different destinations aggregated to one
  entry in routing table one FEC and one LSP
• Multicast The granularity of multicast streams
  (, G) for shared tree and (S, G) for source tree
  .
• S Source, G multicast group
• Aggregation of multicast trees with different
  multicast destination addresses on one LSP -
  further study ?

28
3.2 Flood Prune

• A source node floods a multicast data in the
  network, the nodes which do not want to receive
  data from the multicast group send the prune
  message.
• Multicast routing protocol characteristics -
• Volatile
• - tree structure keeps changing
• - consumes lot of labels hence inefficient
• Traffic-driven
• - routers creates state only when data arrives
• - fast LSP setup is used

29
3.3 Source/Shared Trees

• IP Multicast Routing Protocols create either
• Source trees (S, G)
• - One tree per source (S) and multicast
  group (G)
• - more labels (1 per source and per group)
• Shared trees (, G)
• - One tree per multicast group
• - less labels (1 per multicast group)
• - Problem ?

Implies setting up mp2mp LSPs Merging Problem
30
3.4 Co-existence of Source/Shared trees

• Some protocols support both source and shared
  trees Ex PIM-SM
• One router can maintain both (, G) and (S, G)
  for the same group G.
• Issues ?

31
3.5 Uni/Bi-directional Shared trees

• - Bidirectional shared trees

creates a lot of merging points (M) in the nodes
(N) of the shared trees.
32
3.5 Contd

• Uni-directional shared trees

S2
S1
tunnel
tunnel
to R
N
N
N
N
N
N
N
Multicast traffic flows from 2 senders on a
unidirectional tree
Data from senders is tunneled towards the root
node R, resulting only one merging point R, the
root of the shared tree
33
3.6 Encapsulated Multicast Data

• Sources of unidirectional shared trees
  encapsulate the data towards the root node. The
  data is decapsulated at the root node.
• Encapsulation/decapsulation of multicast data
  are L3 processes
• mapping on to L2 not possible

34
3.7 Loop-free-ness

• Multicast routing protocols depending on the
  underlying unicast protocol suffer from loops
• Effect of loops much worse why ?

35
3.7 Contd
36
4. Mixed L2/L3 Fowarding

• In Unicast, traffic is either forwarded on L2 or
  L3 as shown below

L3
L3
L2
L2
37
4. Contd

• In Multicast traffic is forwarded to some
  branches on L2 and to other branches on L3

L3
L3
L3
L2
L2
L2
L3 forwarding has to take care that traffic is
not forwarded on those branches that already get
their traffic on L2 How ?
38
5. Taxonomy of IP Multicast LSP Triggers

• The creation of LSPs categorized based on
  different event triggers
• Request driven triggered by sending or
  receiving of control messages.
• Topology driven triggered by creation of
  forwarding table entries.
• Traffic driven triggered by arrival of any or
  specific data traffic corresponding to the L3
  forwarding table entry.

39
5. Contd

• Request Driven
• Triggered by the interception of outgoing or
  incoming control messages.
• Resource Reservation Messages
• RSVP Resv message can be used as a trigger to
  establish
• LSPs.
• Multicast Routing Messages
• can create both hard states and soft states.
• routing calculations to determine MRT repeated.
• Ex PIM-SM, CBT

40
5. Contd

• Topology Driven
• - LSP setup is triggered according to changes in
  the network layers routing protocol
• - labels consumed even when no traffic
• Traffic Driven
• - labels allocated only when there is traffic
• - consumes less labels

41
6. Piggy-backing

• The label advertisement is piggy-backed on the
  existing control messages. There are two
  candidates for multicasting
• - Multicast routing messages
• - RSVP Resv messages
• Has advantages and disadvantages depends on
  multicast routing protocol used, trigger
  mechanisms used etc.

42
7. Explicit Routing

• Refers to overriding of the tree established by
  the multicast routing protocol.
• Route LSP takes is defined by the ingress nodes.
• The path consists of series of hops comprising of
  traditional interfaces, an AS or and LSP
• The sequence of hops either user-defined or
  routing protocol defined.

43
7. Contd

• Without explicit routing LSR1-gtLSR3-gtLSR4-gtLSR7
• With explicit routing LSR1-gtLSR3-gtLSR5-gtLSR6-gtLSR
  7

44
8. QoS/CoS

• DiffServ
• - introduces finer stream granularities
• - sender can construct one or more trees with
  different DSCPs.
• IntServ and RSVP
• - RSVP can be used to setup multicast trees with
  QoS

45
9. Issues

• TTL field
• Independent Vs Ordered label distribution control
• Conservation Vs Liberal Label Retention mode
• Downstream Vs Upstream Label Allocation
• Explicit or Implicit Label Distribution

46
10. References

• RFC 3353 - Overview of IP Multicast in MPLS
  Environment
• RFC 3564 - Requirements for Support of
  Differentiated Services-aware MPLS Traffic
  Engineering 
• RFC 3443 - Time To Live (TTL) Processing in
  Multi-Protocol Label Switching (MPLS) Networks