CSE 5346 Presentation MultiProtocol Label Switching - PowerPoint PPT Presentation

1 / 46
About This Presentation
Title:

CSE 5346 Presentation MultiProtocol Label Switching

Description:

Behaviour Aggregate (BA): Collection of objects with same codepoint crossing a ... Per-Domain Behaviour (PDB): Expected treatment a group of packets will receive ... – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 47
Provided by: wwwcs5
Category:

less

Transcript and Presenter's Notes

Title: 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 
Write a Comment
User Comments (0)
About PowerShow.com