1 / 8

Background

LSP-Ping extensions for MPLS-TP draft-nitinb-mpls-tp-lsp-ping-extensions-00 Nitin Bahadur Sami Boutros Rahul Aggarwal Eric Gray. Background.

nitsa
Download Presentation

Background

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. LSP-Ping extensions for MPLS-TP draft-nitinb-mpls-tp-lsp-ping-extensions-00Nitin Bahadur Sami Boutros Rahul Aggarwal Eric Gray

  2. Background • This draft specifies extensions to LSP-Ping so that LSP- Ping can be used to perform OAM on MPLS-TP LSPs in the absence of IP encapsulation. • LSP-Ping ping function meets the Connectivity Verification, Adjacency and Route Tracing requirements specified in [draft-ietf-mpls-tp-oam-requirements].

  3. LSP-Ping/trace-route for MPLS-TP LSPs. • Two modes of operations to run over Bidirectional MPLS-TP LSPs:- • 1- Using IP encapsulation. • Using IP/UDP header [RFC4379]. • The Reply mode MUST be via application level control channel (4). • IP/UDP response message MUST be sent on the reverse path. • IP addresses are used for identification. • 2- Using non-IP encapsulation. • Using ACH channel type in [draft-nitinb-mpls-tp-lsp-ping-bfd-procedures]. • The Reply mode MUST be via application level control channel (4). • Ingress node MAY attach a Source/destination Address TLVs for identification. • Reply message MUST be sent on the reverse path of the LSP using ACH.

  4. LSP-Ping/trace-route extensions Define New address type for Downstream Mapping TLV [RFC4379] Type # = 0 Address Type = N/A (In the absence of IP addressing). K Octets = 8 - SHOULD only perform mpls label control-plane/data-plane consistency checks. Applicable to Detailed Downstream Mapping TLV in [draft- mpls-lsp-ping-enhanced-dsmap]. *** Downstream Mapping TLV is used to get the downstream node information and to enable LSP verification along the transit nodes when performing traceroute. ***

  5. LSP-Ping/trace-route extensions without IP encapsulation • Source/Destination Address TLVs • Identify source/destination addresses as defined in [draft-ietf-mpls-tp-ach-tlv]. • Only one Source Address TLV can exist in the packet. • One or more of Destination Address TLVs MAY be included. • MEP and MIP Identifier • Identify maintenance end point (MEP) and/or maintenance intermediate point (MIP) as defined in [draft-swallow-mpls-tp-identifiers]. • Only one identifier (MEP or MIP) may be present in a packet.

  6. P2MP Considerations • Follows [draft-ietf-mpls-p2mp-lsp-ping] when IP addressing is used. • Use ACH when IP addressing is not used.

  7. Future Enhancements • Define new Target FEC stack for MPLS-TP LSP, specifying src, dst, tun-id and LSP-ID. • Define new Target FEC stack for static PW. • Define new TLV to specify the sender # of hops to be able to send the inband reply with the correct TTL. • In LSP-Ping without IP encapsulation, close on sender/destination node addresses and ME-ID/MEP-ID/MIP-ID formats.

  8. Next Steps • Looking for comments/ feedback on the document. • Would like the document to be accepted as a WG document.

More Related