challenges and solutions for oam in point-to-multipoint mpls
DESCRIPTION
Challenges and Solutions for OAM in Point-to-Multipoint MPLS. Adrian Farrel, Old Dog Consulting Ltd. Zafar Ali, Cisco Systems, Inc. Outline. P2P LSP Ping Extending P2P LSP Ping for P2MP LSPs P2P Traceroute Traceroute for P2MP LSP Trees Pro-active Connection Verification Summary. - PowerPoint PPT PresentationTRANSCRIPT
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
+ P2MP LSP Identifier
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
+ P2MP LSP Identifier
R1 R2
R3
R4
R6
R7
R5
MPLS Echo Reply
P2MP LSP
R8
31
66
11OLD DOG CONSULTING
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
12OLD DOG CONSULTING
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
13OLD DOG CONSULTING
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
14OLD DOG CONSULTING
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
15OLD DOG CONSULTING
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
16OLD DOG CONSULTING
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
17OLD DOG CONSULTING
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
18OLD DOG CONSULTING
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}
19OLD DOG CONSULTING
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
20OLD DOG CONSULTING
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)
21OLD DOG CONSULTING
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