Detecting P2MP Data Plane Failures draftyasukawamplsp2mplspping00.txt - PowerPoint PPT Presentation
1 / 6
Title:
Detecting P2MP Data Plane Failures draftyasukawamplsp2mplspping00.txt
Description:
Recent proposals have extended the scope of MPLS TE LSPs to ... DOS attacks. Handling simultaneous query responses. 61st IETF Washington DC November 2004 ... – PowerPoint PPT presentation
Number of Views:33
Avg rating:3.0/5.0
Title: Detecting P2MP Data Plane Failures draftyasukawamplsp2mplspping00.txt
1
Detecting P2MP Data Plane Failuresdraft-yasukawa-
mpls-p2mp-lsp-ping-00.txt
- Seisho Yasukawa - yasukawa.seisho_at_lab.ntt.co.jp
Adrian Farrel - adrian_at_olddog.co.uk
2
Problem Statement
- Recent proposals have extended the scope of MPLS
TE LSPs to encompass P2MP TE LSPs. There is a
requirement for simple and efficient mechanisms
to detect data plane failures in P2MP MPLS LSPs. - Requirements include
- Verification of reception at recipients.
- Discovering point-to-multipoint tree topology.
- Ping/Trace from ingress/egress.
- Whole tree (source-to-recipient)
- Individual recipients
- Issues to overcome include
- Tracing in a tree context.
- Ping/Trace from receiver to source may not be
viable. - Scalability.
3
Solution Development
- Ideally any potential solutions should look to
reuse existing techniques. - Obvious candidate is LSP Ping
- P2P LSP Ping ltdraft-ietf-mpls-lsp-ping-07.txtgt
- Ping to verify the LSP connectivity.
- Traceroute to identify LSP paths as well as fault
isolation. - Return codes to indicate possible errors.
- Adapting P2P LSP Ping for P2MP networks
- Scaling ping
- Handling multiple recipient echo replies.
- Ability to target specific recipients.
- Scaling trace
- Tracing across point-to-multipoint tree
topologies. - Displaying transit and branching routers.
- Security bandwidth handling
- DOS attacks.
- Handling simultaneous query responses.
4
Proposed Solution
- Heavy re-use of LSP Ping
- Need to identify the LSP
- LSP Ping has RSVP Session sub-TLV
- We need to identify a P2MP LSP
- Introduce RSVP P2MP Session sub-TLV
- Ingress can control ping/trace of whole tree or
individual recipients - Necessary to protect the ingress from being
swamped - Introduce P2MP Egress Identifier sub-TLV (of FEC
Stack TLV) - P2MP LSP Ping
- Echo request cannot be filtered based on
identified recipient - Echo response only from targeted recipient
- P2MP LSP traceroute
- Echo request cannot be filtered based on
identified recipient - Only LSRs on the path to identified recipients
respond
5
Other Features
- Branch and bud (drop-and-continue) flags added to
Downstream Mapping TLV - Coordination of responses
- Problem is that traceroute for the whole tree
will return many responses - Many possible solutions for coordination
- We have chosen to list the recipients on each
branch - Helps build up a picture of the tree early
- Helps understand the tree when there are multiple
faults - Achieved using new Downstream Mapping Multipath
Information
6
Issues Questions
- Is this the right approach, what are the
alternatives? - Base on LSP Ping or develop new protocol?
- Ping/Trace from the recipient to the source
- Easier to navigate the tree
- Not obvious for operational use
- Cant build the whole tree
- How to handle scaling?
- Control simultaneous echo responses using
identified recipient - An option would be to use jittered responses
- Additional Requirements?
- Targeting specific groups of receivers?
- Specifying Ping/Trace source nodes?
- What should happen to this draft?
- Merge with existing MPLS LSP Ping or create new
draft? - Something the MPLS WG should be working on?
Recommended
CrystalGraphics Presentations
