challenges and solutions for oam in point-to-multipoint mpls

OLD DOG CONSULTING

Challenges and Solutions for OAM in Point-to-Multipoint MPLS

Adrian Farrel, Old Dog Consulting Ltd.

Zafar Ali, Cisco Systems, Inc.

2OLD DOG CONSULTING

Outline

P2P LSP Ping Extending P2P LSP Ping for P2MP LSPs P2P Traceroute Traceroute for P2MP LSP Trees Pro-active Connection Verification Summary

OLD DOG CONSULTING

P2P LSP Ping: In a Nutshell

R4

LSP

MPLS Echo Reply

Use the same label stack as used by the LSP so that Echo Request flows in band of LSP under test.

The IP header destination address field of the echo request is a 127/8 address so that it is not forwarded at the destination.

Echo Reply has destination IP address/port copied from the Echo Request’s source address/port. It is returned as IP or MPLS traffic.

MPLS Echo RequestHeader50 SA DA=

127/8

SA=Source AddrDA=Destination Addr

FEC

R1

R2 R3

Header19 SA DA=127/8

FEC

Header32 SA DA=127/8 FEC

4OLD DOG CONSULTING

MPLS LSP Ping Essentials

MPLS LSP Ping messages are UDP-encapsulated

Echo Requests contain basic fields and TLVs

Most important TLV is the Target FEC Stack Identifies the LSP being tested

LDP IPv4/6 prefix RSVP IPv4/6 session and sender template VPN IPv4/6 prefix BGP labeled IPv4 prefix, etc.

OLD DOG CONSULTING

P2P LSP Ping: Detecting Broken LSP

LSP Broken

Echo Request is addressed to 127/8 address so it is not forwarded if the LSP is broken. It is delivered locally and causes an Echo Response.

If LSP is broken on a link, error is detected through lack of response.

R4

MPLS Echo Reply

MPLS Echo RequestHeader50 SA DA=

127/8

SA=Source AddrDA=Destination Addr

FEC

R1

R2 R3

Header19 SA DA=127/8

FEC

OLD DOG CONSULTING

R1

R3

LSP 1

LSP 2

R2

R4

LSP Ping is initiated from R1 through LSP1

Owing to an error on R2, all data intended for LSP 1 is switched into LSP 2. This includes the Echo Request.

R4 examines the Target FEC Stack on the received Echo Request and recognizes that it is not the intended recipient. It sends an Echo Response with an error code.

P2P LSP Ping: Detecting a Misrouted LSP

7OLD DOG CONSULTING

P2MP LSP Ping: In a Nutshell

Reuses existing LSP Ping mechanisms Echo Request messages follow the same data path that

normal MPLS packets would traverse (including packet replication)

Main differences are in LSP Identification/ Target FEC Stack

5

31

52

60

17

23

MPLS echo-req

+ P2MP LSP Identifier

R1 R2

R3

R4

R6

R7

R5

MPLS Echo Reply

P2MP LSP

8OLD DOG CONSULTING

Identifying P2MP LSPs

LSPs still identified using the Target FEC Stack

MPLS-TE LSPs identified by Session and Sender Template Just like P2P, but fields have slightly different

meanings P2MP ID used instead of Destination Address Mirrors the differences in RSVP-TE

Sub-Group ID is not used Multicast LDP LSPs identified by multicast FEC

Root address and opaque value Just as used in multicast LDP

9OLD DOG CONSULTING

Detecting a Broken P2MP LSP

Echo Request is addressed to 127/8 address so it is not forwarded if the LSP is broken. It is delivered locally and causes an Echo Response.

If LSP is broken on a link, error is detected through lack of response.

5

60

17

23

MPLS echo-req


R1 R2

R3

R4

R6

R7

R5

MPLS Echo Reply

P2MP LSP

10OLD DOG CONSULTING

Detecting a Misrouted P2MP LSP

Owing to broken LFIB or incorrect replication at R2 the Echo Request reaches R8

R8 recognizes that it is NOT an Egress for “Target (P2MP) FEC” in the Echo Request and sends an Echo Response with an error code

5

60

17

23

MPLS echo-req


R1 R2

R3

R4

R6

R7

R5

MPLS Echo Reply

P2MP LSP

R8

31

66


P2MP LSP Ping: Issues and Challenges

If you send a Ping to the whole P2MP tree you will get an Echo Response from each leaf

The number of egresses (leaves) in a P2MP tree can be tens, hundreds, or even thousands The initiator (the ingress) may become swamped The network around the initiator may be

swamped UDP rate limiting is also recommended

Lost Echo Replies lead to false negatives Other traffic may be adversely affected Solutions

Ping a single target Jitter the responses


Egress Filtering

Echo Request is in-band so still reaches all egresses Target egress is identified by P2MP Egress Identifier TLV Only the target egress sends an Echo Response

Can target one egress or whole tree

5

31

52

60

17

23

MPLS echo-req

+ P2MP LSP Identifier and Egress Identifier

R1 R2

R3

R4

R6

R7

R5

MPLS Echo Reply

P2MP LSP


Jittered Responses

Optional Procedure initiated by Ingress Jitter Range is specified by the Ingress in the Echo

Jitter TLV in the Echo Request Egress sends Echo Response at randomly selected

time within Jitter Range interval

5

31

52

60

17

23

MPLS echo-req

+ P2MP LSP Identifier and Jitter Range TLV

R1 R2

R3

R4

R6

R7

R5

MPLS Echo Reply

P2MP LSP


P2P LSP Traceroute

R4

R5

R3

R1 R2

TTL TTL=1

Traceroute is used for hop-by-hop fault localization as well as path tracing

MPLS Echo Requests are sent with increasing TTL to “probe” the LSP from upstream LSRs

Echo Request forwarded as normal if TTL > 1 When TTL expires the Echo Request is passed to the

control plane Checks that it is indeed a transit LSR for this P2P MPLS LSP Reply contains the label and interface for reaching the

downstream router, in Downstream Mapping TLVTTL=1

TTL=1


P2MP Traceroute: In a Nutshell

MPLS Echo Request

MPLS Echo Reply w/ Downstream Mapping TLVs

TTL

R1

R2

R3

R4

R6

R5

TTL=1

TTL=1 1

2 B=1, E=0

B=0, E=0

TTL=1

IP Bud NodeR7 R8

3 B=0, E=1

Similar to P2P Traceroute with the following differences Echo Request replicated onto all branches with identical

TTL A branch node may need to identify more than one

downstream interface and label Helpful to identify branch and bud nodes

Branch Node is identified by B-flag Bud Node is identified by E-flag


P2MP Traceroute : Challenges

Multiple downstream interfaces/labels Multiple Downstream Mapping TLVs already allowed

(ECMP) Scalability worse than for simple LSP Ping

Note that in IP multicast the traceroute is from destination to source

This might not be viable in MPLS since the previous MPLS hop might not be on the IP path to the ingress

Response jittering still available Egress filtering can be used

Does a transit node know that it is on the path to the target egress?

Need to correlate the echo responses at ingress (to identify branches in the P2MP tree)

New B and E flags identify branch and bud nodes Downstream Mapping TLVs help But correlating Echo Responses to construct the tree is still

hard


Egress Filtering

Egress filtering is possible in P2MP RSVP-TE An LSR only responds if it lies on the path of the P2MP LSP

to the egress identified by the P2MP Egress Identifier TLV Possible because RSVP-TE identifies the destinations

Egress filtering is NOT possible for multicast LDP A transit LSR of a multicast LDP LSP is unable to determine

whether it lies on the path to any one destination Unfiltered (full tree) traceroute is possible for all LSPs

MPLS Echo Request Egress Identifier R4

MPLS Echo Reply w/ Downstream Mapping TLV

TTL

R1

R2R3

R4

R6R5

TTL=1

TTL=1

TTL=1

TTL=1

TTL=1


Correlating Traceroute Responses

Problem is that traceroute for the whole tree will return many responses to ingress

Hard to work out which LSP hops belong where in the tree Solution has three components

Indicate branch/bud status using flags (mandatory) Indicate outgoing interface and label in Downstream

Mapping TLV (mandatory) List the destinations reachable through each outgoing

interface/label (optional and only for RSVP-TE) Achieved using new Downstream Mapping

Multipath Information

MPLS echo-req (All Egresses)

MPLS Echo Reply w/ Downstream Mapping TLVs

TTL R1

R2

R3

R4

R6

R5

TTL=1

TTL=1 1

2 B=1, E=0, {R3, R4}

B=0, E=0, {R6}

TT

L=1

IPBud Node R7

R8

3

B=0, E=1, {R7, R8}


Connection Verification Probing

A new approach to the scalability problem Particularly useful for pro-active fault detection A new Connection Verification LSP Ping message is

sent by the ingress Each destination responds to say the CV process has

been started Each destination expects to receive a new CV message

within a specific time period Non-receipt causes the destination to raise an alarm

Local action and Echo Response message Process can be enabled and disabled by ingress

Can also be applied to P2P LSPs


References

RFC 4687Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks

draft-ietf-mpls-p2mp-lsp-pingDetecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping (work in progress)

RFC 4379Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [MPLS LSP Ping]

draft-ietf-mpls-rsvp-te-p2mpExtensions to RSVP-TE for Point to Multipoint TE LSPs (work in progress)

draft-ietf-mpls-ldp-p2mpLabel Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (work in progress)

draft-swallow-mpls-mcast-cvConnectivity Verification for Multicast Label Switched Paths (work in progress)


Summary LSP Ping and Traceroute function for P2MP MPLS LSPs builds

on established P2P technology Objective is to test LSPs periodically or in response to faults

Detect and isolate faults Scalability is a big concern

LSP tree may have thousands of egresses Jittered responses eases the issue of the ingress being

swamped Egress filtering allows targeting of a single egress

Not possible for traceroute of multicast LDP LSPs Scalability and security requirements call for rate limiting, but

that can lead to false negatives New work on pro-active fault detection using Connection

Verification message Multipoint to multipoint LSPs not currently addressed


Questions?

Adrian [email protected]

Zafar [email protected]

challenges and solutions for oam in point-to-multipoint mpls

Documents

echo response

band of lsp

lsp 2r2r4lsp ping

echo request flows

received echo request

target p2mp fec

p2mp tree

broken p2mp lspecho