1 / 6

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-00.txt

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-00.txt. Seisho Yasukawa - yasukawa.seisho@lab.ntt.co.jp Adrian Farrel - adrian@olddog.co.uk. Problem Statement.

ernst
Download Presentation

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Detecting P2MP Data Plane Failuresdraft-yasukawa-mpls-p2mp-lsp-ping-00.txt Seisho Yasukawa - yasukawa.seisho@lab.ntt.co.jp Adrian Farrel - adrian@olddog.co.uk 61st IETF Washington DC November 2004

  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. 61st IETF Washington DC November 2004

  3. Solution Development Ideally any potential solutions should look to reuse existing techniques. • Obvious candidate is LSP Ping P2P LSP Ping <draft-ietf-mpls-lsp-ping-07.txt> • 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. 61st IETF Washington DC November 2004

  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 61st IETF Washington DC November 2004

  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 61st IETF Washington DC November 2004

  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 • Can’t 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? 61st IETF Washington DC November 2004

More Related