Introduction to Label switched Multicast : P2MP-TE & mLDP

Speakers: Rajendra Chayapathi , Cisco systems Utpal Mukhopadhyaya , Cisco systems

NANOG 49

Agenda
Motivation

Multicast Solutions
TE introduction P2MP TE Overview P2MP TE sample config LDP introduction

mLDP Overview
Reference Q and A
NANOG 49

Rajendra and Utpal

Motivation
Service Providers using MPLS infrastructure want to offer Multicast Services to their customers using the same data plane used to offer unicast services.

Simplify service/operational maintenance of MPLS core by removing PIM configuration requirements from within MPLS core. Route Multicast traffic on a non-optimal path using TE. Leverage Fast Re-route Capability (FRR) for multicast traffic.
NANOG 49

Rajendra and Utpal

Multicast Solutions
IPv4 M U L T I C A S T

IPv6 M U L T I C A S T

Native Multi mVPN cast

IPv4 M U L T I C A S T

IPv6 M U L T I C A S T

m V P N

6PE / 6 V P E

IPv4 M U L T I C A S T

IPv6 M U L T I C A S T

m V P N

6PE / 6 V P E

IPv4
GRE Based

RSVP-TE Label Based

mLDP

Native Solution

MPLS Based Solutions

NANOG 49

Rajendra and Utpal

Label based Multicast solutions Todays Topic

IPv4 M U L T I C A S T IPv6 M U L T I C A S T

Our Topic: IPv4 Multicast using RSVP-TE and mLDP

IPv4 M U L T I C A S T

IPv6 M U L T I C A S T

m V P N

6PE / 6 V P E

m V P N

6PE / 6 V P E

RSVP-TE Label Based

mLDP

MPLS Based Solutions

NANOG 49

Rajendra and Utpal

RFCs for Label Switched Multicast Solutions

P2MP RSVP-TE

1. Extensions to RSVP-TE for Point-to-Multipoint TE Label Switched Paths

RFC 4875

2. Signaling Requirements for Point-to-Multipoint TrafficEngineered MPLS Label Switched Paths

mLDP RFC 4461

1. Multicast LDP (mLDP)

Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-09.txt Apr. 30, 2010
NANOG 49

Rajendra and Utpal

TE Introduction

NANOG 49

Traffic Engineering Basics

HEADEND

MIDPOINT

TAILEND

Upstream

Tunnel Direction

Downstream

Tunnels are always uni-directional

NANOG 49

Rajendra and Utpal

Traffic Engineering Basics..

TE LSPs setup mechanism: 1. All the routers in the network build a TE topology database using IGP extension & link attributes. 2. Tunnel at the head-end makes the request for a path across the network from head to tail . The path request can be either Dynamic or Explicit. 3. Paths are signaled across the network using RSVP signaling mechanism. 4. On receipt of RSVP Signalling message, all downstream routers either accept or reject based on the requested resources availability. 5. If accepted , RESV messages carrying LABEL are sent from downstream routers towards upstream and the PATH message are forwarded towards the downstream routers. 6. When successful RESV messages reach the headend from all the downstream routers, LSP TE is set up.

NANOG 49

Rajendra and Utpal

TE LSP Setup Example

Headend
R1 TE LSP R3
TE Bandwidth Request 20 Mbps 40 80 60

Tailend
R9 R4
10 30

R2

15

Pop
32

Not enough BW
40 60 50 70

RESV message

27

R6
80 100

R7

R6

22

80

RSVP PATH: R1 R2 R6 R7 R4 R9 RSVP RESV: Returns labels and reserves bandwidth on each link Bandwidth available
Rajendra and Utpal

49 Returned label via RESV message

NANOG 49

10

P2MP TE Overview

NANOG 49

11

P2MP TE overview
RSVP-TE based LSPs are built from the head end router in MPLS core to the tail end(s) router (s) with one head end and one or more tail ends Control Plane and Forwarding Plane mechanisms for P2MP TE are the same as P2P TE No PIM required in the core. PIM is needed only at the edge of the MPLS network.

Multicast Groups (S,G) are mapped onto P2MP-TE tunnels. One or more (S, G) can be mapped onto the same P2MP Tunnel
With PIM working at edge of the MPLS network, the overall flow would look like:

PIM --> P2MP-TE --> PIM

NANOG 49

Rajendra and Utpal

12

Terminologies used in P2MP TE

Transit LSR X Branch LSR - B Source LSR S S2L Sub-LSP Tail End CE Receiver CE Source MPLS Core Leaf LSR - L

Head End

Tail End

CE Receiver

. S2L sub-LSP: The path from the source to one specific leaf. S2PL sub-LSP: The path from the source to a set of leaves.

Leaf LSR - L

B2AL sub-LSP: The path from a branch LSR to all downstream leaves. X2X sub-LSP: A component of the P2MP LSP that is a simple path that does not branch.

NANOG 49

Rajendra and Utpal

13

P2MP TE Architecture
PIM Enabled PIM Free Core PIM Enabled PIM Adjacency

Tail End PIM Adjacency S2L Sub-LSP MPLS Core

PE-West

PE-North

CE Receiver

CE Head End Source S2L Sub-LSP Mid & Branch Point

PE-South

Tail End P2MP LSP

CE

PIM Adjacency

Receiver

NANOG 49

Rajendra and Utpal

14

P2MP TE Control Plane Signalling

RSVP PATH

ID: 100 SubID: 1 ERO: PE-North RSVP PATH ID: 100 SubID: 1 ERO: P-Middle PE-North

PE-West
Path

Tail End

CE Receiver

PE-North P-Middle

CE Head End Source

RSVP

Path
PATH

ID: 100 SubID: 2 *ERO: P-Middle PE-South

PE-South

MPLS Core

Tail End
RSVP PATH

CE Receiver

ID: 100 SubID: 2 *ERO: PE-South

NANOG 49

Rajendra and Utpal

15

P2MP TE Signalling
label used 101 Is same
RSVP RESV RSVP RESV ID: 100 SubID: 1 LABEL: 201

ID: 100 SubID: 1 LABEL: 101

CE Tail End

Resv

PE-North P-Middle

Receiver

CE

Head End

Resv
RSVP RESV

PE-West

ID: 100 SubID:Core MPLS 2

PE-South

Source

LABEL: 101

Tail End
RSVP RESV

CE Receiver

ID: 100 SubID: 2

LABEL: 401

LFIB populated with labels allocated by RESV messages

Multicast state built by reusing sub-LSP labels at branches

NANOG 49

Rajendra and Utpal

16

P2MP TE Data Path

Downstream Traffic
LFIB OUT Labe I/F Label I/F l 101 s0 201 401 s1 s2 IN

Data S G

Head End S0 S1

Tail End

CE Receiver

PE-North

CE Source

PE-West

Data S G 101

S2

PE-South
MPLS Core

Tail End

CE Receiver

Branch point creates single LFIB entry from ingress

{101} {201} and {401} at branching point
NANOG 49

Rajendra and Utpal

17

RPF Check
RPF Check is done at TE Tail end routers on inbound interfaces

Since Sub LSP tail has no interface, LSP virtual interfaces (LSP-VIF) are created automatically to represent the inbound Sub LSPs
RPF check modified to use LSP-VIF for source Every Tail end router will have one LSP-VIF for the corresponding head-end router.

One LSP-VIF may represent one or more Sub LSP from the same head end

NANOG 49

Rajendra and Utpal

18

LSP-VIF at the Tail End

(S1, G1) Head End Router A

RPF Check

Source (S1,S2)

RPF Interface: Lspvif1 RPF Neighbour: Router A RPF Type: BGP NH

SubLSP A1 SubLSP A2

(S1, G1)

(S2, G2)

Tail End Routers (S2, G2)

SubLSP B1

Head End Router B

RPF Check Source (S3)

(S3, G3)
Receiver
RPF Interface: Lspvif1

(S3, G3)

RPF Neighbour: Router B

RPF Type: BGP NH

An LSP-VIF represents all Sub-LSPs from a unique head end

The LSP-VIF is used for the multicast RPF check
NANOG 49

Rajendra and Utpal

19

P2MP TE Sample Configuration

NANOG 49

20

Head End config : IOS-XR

RP/0/RP1/CPU0:ajanta#sh run interface tunnel-mte 1 interface tunnel-mte1 ipv4 unnumbered Loopback0 destination 100.0.0.1 First Tunnel destination Instance path-option 1 explicit name PE1_228_1_1_1 <= Explicit Path ! destination 100.0.0.3 Second Tunnel destination Instance path-option 1 explicit name PE2_228_2_2_2 <= Explicit Path ! explicit-path name PE1_228_1_1_1 index 1 next-address strict ipv4 unicast 1.1.1.2 index 2 next-address strict ipv4 unicast 1.2.2.2 explicit-path name PE2_228_2_2_2 index 1 next-address strict ipv4 unicast 1.1.1.2 index 2 next-address strict ipv4 unicast 1.3.3.3

NANOG 49

Rajendra and Utpal

21

TE Head End config IOS-XR

RP/0/RP1/CPU0:ajanta#sh run router ospf router ospf 1 nsr

router-id 1.1.1.1
area 0 mpls traffic-eng interface Loopback0

rsvp interface TenGigE0/2/0/0 bandwidth ! ! mpls traffic-eng interface TenGigE0/2/0/0 ! !

interface TenGigE0/2/0/0
mpls traffic-eng router-id Loopback0 !

NANOG 49

Rajendra and Utpal

22

MPLS Label First Branching

RP/0/RP1/CPU0:ajanta#show mpls forwarding p2mp Local Outgoing Label Label 21028 101 Prefix Outgoing Interface Next Hop Bytes or ID Switched 10.1.1.1 0

------ ----------- ------------------ ------------ --------------- -----------P2MP TE:1 Te0/2/0/0

Head End router Single LSP

P2MP TE branch : RP/0/RP0/CPU0:ellora#show mpls forwarding p2mp Local Outgoing Label Label 101 201 401 Prefix Outgoing Interface PO0/9/0/3 Te0/2/2/0 9.1.11.2 47.47.43.2 Next Hop Bytes or ID P2MP TE:1 P2MP TE:1 Switched 0 0

------ ----------- ------------------ ------------ --------------- ------------

Mid router Two outgoing labels

NANOG 49

Rajendra and Utpal

23

P2MP Configuration: TE Midpoint

router ospf 1 router-id 1.1.1.2 area 0 mpls traffic-eng interface Loopback0 ! interface TenGigE0/2/2/0 ! interface POS 0/9/0/0 ! ! interface TenGigE0/1/0/0 ! ! mpls traffic-eng router-id Loopback0 ! rsvp interface TenGigE0/1/0/0 bandwidth ! interface TenGigE0/2/2/0 bandwidth ! interface POS 0/9/0/0 bandwidth ! mpls traffic-eng interface TenGigE0/1/0/0 ! interface TenGigE0/2/2/0 ! interface POS 0/9/0/0

P2MP TE config is similar to P2P Midpoint router configuration. Midpoint LSR must support P2MP signaling extensions

NANOG 49

Rajendra and Utpal

24

P2MP TE Configuration: Tail End

rsvp interface TenGigE0/1/0/0 bandwidth ! mpls traffic-eng interface TenGigE0/1/0/0 !

router ospf 1 router-id 1.1.1.3 area 0 mpls traffic-eng interface Loopback0 ! interface GigabitEthernet0/1/1/2 ! ! interface TenGigE0/1/0/0 ! ! mpls traffic-eng router-id Loopback0 !

multicast-routing address-family ipv4 core-tree-protocol rsvp-te ssm range ssm interface all enable ! router igmp interface GigabitEthernet0/1/1/2 !

Configurations at P2MP TE tail need to create LSP-VIF for RPF check

NANOG 49

Rajendra and Utpal

25

P2MP TE FRR (Fast Re-route)

NANOG 49

26

P2MP TE LSP Fast Re-Route Protection

FRR configuration for P2MP TE is the same as that for P2P TE Backup tunnels are always P2P A backup tunnel can protect many TE LSPs Point-to-point Point-to-multipoint

A combination of both

NANOG 49

Rajendra and Utpal

27

P2MP TE LSP: FRR Link Protection

R4 (Tail)

Protected Link Fails

PE-North
R1 (Head)
Backup LSP

PE-West

R2

P-Middle

R3 (Tail)

PE-South

Sub-LSP: (R1, R2, R4) Backup: (R2, R3, R4)

NANOG 49

Primary Path
Backup Path
Rajendra and Utpal

28

P2MP TE FRR Link Protection Configuration

interface Tunnel-te 1 Backup Tunnel description R2 R3-> R4 Backup Tunnel ip unnumbered Loopback0 destination 100.0.0.1 Loopback address of R4 path-option 1 explicit name R2-R3-R4 Backup Path ! mpls traffic-eng interface POS0/9/0/0 backup-path tunnel-te 1 Link protection Tunnel

NANOG 49

Rajendra and Utpal

29

LDP Introduction

NANOG 49

30

Label Distribution Protocol

Defined in RFC 3035 and 3036

LDP is a protocol defined to distribute labels between two peers (called LSRs) for prefixes advertised by unicast routing protocols like OSPF, IS-IS, EIGRP, etc..
These labels help create Label Switched Paths or LSPs whose endpoints can be either the directly attached neighbors just like IP next-hop or remote neighbors (called targetted ldp peers) LDP associates a Forwarding Equivalence Class (FEC) [RFC 3031] with each LSP it creates and maps packets onto that LSP

NANOG 49

Rajendra and Utpal

31

Label Distribution Protocol Operations

Discover LDP Peers:
Discover peers by sending LDP Hello message using UDP

Establish Session and negotiate parameters

Open a reliable TCP connection (Port 646) with peers and start negotiating various LDP capabilities

Start exchanging Labels and other Parameters

Exchange prefix/FEC and label information Exchange various LDP capabilities parameters

Maintain and Manage session

NANOG 49

Rajendra and Utpal

32

LDP Messages
LDP protocol exchange various kinds of messages like Hello, Initialize, Label Mapping etc. Messages may carry additional information in the form of TLVs
Example: Label Mapping Message carries FEC TLV, Label TLV etc.

FEC TLVs carry information regarding which data packets get mapped onto LSPs

NANOG 49

Rajendra and Utpal

33

MPLS LDP Control plane

In Address Out Out Label Prefix Iface Label 16 10.2.1.1 Eth0 20 17 10.4.1.1 Eth1 21
LSP MPLS Core Eth1 CE Source Eth0
Use Label 20 for 10.2.1.1

In Address Out Out Label Prefix Iface Label 40 10.2.1.1 Eth1 16

41 10.4.1.1 Eth1 17

In Address Label Prefix 20 10.2.1.1

Out Out Iface Label Eth0 -

10.2.1.1

Eth0

CE

PE-North

PE-West
Use Label 16LSP for 10.2.1.1 And 17 for 10.4.1.1

Eth1

PE-South

Use Label 21 for 10.4.1.1

10.4.1.1

CE

Label Distribution Protocol (LDP)

(Downstream Allocation)

NANOG 49

Rajendra and Utpal

34

MPLS LDP Data forwarding

In Address Out Out Label Prefix Iface Label 16 10.2.1.1 Eth0 20 17 10.4.1.1 Eth1 21
LSP

In Address Out Out Label Prefix Iface Label 40 10.2.1.1 Eth1 16 41 10.4.1.1 Eth1 17

In Address Label Prefix 20 10.2.1.1 PE-North

10.2.1.1

Out Out Iface Label Eth0 -

Eth0

CE Data

PE-West

10.2.1.1

CE 16 10.2.1.1 Data MPLS Core 10.2.1.1 Data

Pop Labels
PE-South

Push Labels

10.4.1.1

CE

Swap Labels
Rajendra and Utpal

NANOG 49

35

mLDP Overview

NANOG 49

36

mLDP: Extension of LDP cabailities

LDP capabilities are extended to support multicast.
Addition to the original protocol to allow enhancements is supported through
draft-ietf-mpls-ldp-capabilities-04

Capabilities are advertised through LDP message TLVs during LDP Initialisation/LDP session Establishment phase

mLDP defines new FEC elements

P2MP FEC element : TLV 0x0508 MP2MP FEC Element : TLV 0x0509

NANOG 49

Rajendra and Utpal

37

mLDP FEC Element

0 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 Tree Type Address Family Root Node Address Opaque Value Length Opaque Value(s) Address Length

...

Parameters Tree Type Address Family Address Length Root Node Address Opaque Value
NANOG 49

Description P2MP, MP2MP Up, MP2MP Down Root node address format (IPv4 =1 or IPv6 = 2) Number of octets in root address (IPv4 = 4, IPv6 = 16) Host address of MP LSP root (within MPLS core) One or more TLVs uniquely identifying MP LSP within the in context of the root
Rajendra and Utpal

38

mLDP Protocol Operations:

Unlike P2MP TE where ingress LSR initiates the tree creation , in mLDP egress LSRs (receiver) initiate tree creation by looking for the root address. The root address is derived from BGP next-hop or static configuration. Each LSR in the path resolves next-hop of the root address and sends label

mLDP Signalling discovers the FEC for an LSP, and assigns multicast flow to the LSP.
Two types of signalling are used: In-Band Signalling We discuss this model here! Out-Of-Band or Overlay Signalling FEC uniquely identifies the MP LSP for both methods

NANOG 49

Rajendra and Utpal

39

mLDP Architecture
Upstream control plane signalling (towards root) PIM Enabled PIM Free Core (No Native Multicast) PIM Enabled PIM Adjacency LSP PIM Adjacency LSP MPLS Core

Tail End

PE-West

PE-North

CE Receiver

CE Head End Source Mid & Branch Point

PE-South

P2MP LSP or MP2MP LSP

Tail End

CE PIM Adjacency Receiver

Downstream Data Traffic to the recivers (away from root)

NANOG 49

Rajendra and Utpal

40

P2MP mLDP operation Control plane

TLV Label map Message Type = P2MP FEC: Root = PE-West Opaque = 200 LABEL: 101 TLV Label Map message Type = P2MP FEC: Root = PE-WEST Opaque = 200 LABEL: 201

Head End

CE
101

Tail End

PE-North P-Middle
CE

Receiver

PE-West
MPLS Core Source Tail End
TLV

PE-South

CE
Label Map Message

Receiver

Type = P2MP
FEC: Root = PE-West Opaque = 200 LABEL: 401

Downstream on demand Label allocation used

NANOG 49

Rajendra and Utpal

41

P2MP mLDP operation Data plane

Downstream Traffic

Data S G

Tail End

CE Receiver

PE-North P-Middle
CE Head End Source
Data S G 101

PE-West
MPLS Core

PE-South

Tail End

CE Receiver

PE-West sends Multicast Data Traffic (S, G) on MP-LSP Branch LSR (P-Middle) replicates and swaps out two different labels: (towards PE-North) and 101->401 (towards PE-South)
NANOG 49

101->201
42

Rajendra and Utpal

Conclusion
Currently Multicast Services offered by MPLS based Service providers
Require

enabling multicast in their MPLS core which demands non-trivial re-engineering of their existing MPLS network . Cannot leverage high availability features of unicast services such as TE-FRR.

P2MP TE and mLDP based solutions address the above limitation with MPLS based service provider.
Applications:
RSVP TE based solution has high potential for Triple Play Video services & content distribution mLDP will be more attractive for applications that demand Multipoint to Multipoint such as Telepresence etc

NANOG 49

Rajendra and Utpal

43

Reference
RSVP-TE
RFC 4461 & RFC 4875

LDP
RFC 3031 , RFC 3035 & RFC 3036 draft-ietf-mpls-ldp-capabilities-04 draft-ietf-mpls-ldp-p2mp-09.txt Apr. 30, 2010

CCO Documentation
Acknowledgement
Jeff Apcar

NANOG 49

Rajendra and Utpal

44

Q & A THANK YOU

NANOG 49

45