--- 1/draft-ietf-mpls-p2mp-lsp-ping-11.txt 2010-10-19 03:16:14.000000000 +0200 +++ 2/draft-ietf-mpls-p2mp-lsp-ping-12.txt 2010-10-19 03:16:14.000000000 +0200 @@ -1,21 +1,22 @@ Network Working Group S. Saxena, Ed. Internet-Draft Cisco Systems, Inc. Intended Status: Standards Track A. Farrel Updates: 4379 (if approved) Old Dog Consulting -Created: October 08, 2010 S. Yasukawa -Expires: April 08, 2010 NTT Corporation +Expires: April 17, 2011 S. Yasukawa + NTT Corporation + October 18, 2010 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping - draft-ietf-mpls-p2mp-lsp-ping-11.txt + draft-ietf-mpls-p2mp-lsp-ping-12.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -54,186 +55,66 @@ document authors. All rights reserved. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Contents - 1. Introduction.................................................... 5 - 1.1. Design Considerations......................................... 6 - 2. Notes on Motivation............................................. 6 - 2.1. Basic Motivations for LSP Ping................................ 7 - 2.2. Motivations for LSP Ping for P2MP LSPs........................ 7 - 3. Packet Format................................................... 9 - 3.1. Identifying the LSP Under Test................................ 9 - 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 9 - 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV........................... 10 - 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV........................... 10 - 3.1.2. Identifying a Multicast LDP LSP............................ 11 - 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 11 - 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 13 - 3.2. Limiting the Scope of Responses.............................. 13 - 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 14 - 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 14 - 3.3. Preventing Congestion of Echo Responses...................... 14 - 3.4. Respond Only If TTL Expired Flag............................. 15 - 3.5. Downstream Detailed Mapping TLV.............................. 16 - 4. Operation of LSP Ping for a P2MP LSP........................... 16 - 4.1. Initiating Router Operations................................. 16 - 4.1.1. Limiting Responses to Echo Requests........................ 17 - 4.1.2. Jittered Responses to Echo Requests........................ 17 - 4.2. Responding Router Operations................................. 18 - 4.2.1. Echo Response Reporting.................................... 19 - 4.2.1.1. Responses from Transit and Branch nodes.................. 19 - 4.2.1.2. Responses from Egress Nodes.............................. 20 - 4.2.1.3. Responses from Bud Nodes................................. 20 - 4.3. Special Considerations for Traceroute........................ 22 - 4.3.1. End of Processing for Traceroutes.......................... 22 - 4.3.2. Multiple responses from Bud and Egress Nodes............... 23 - 4.3.3. Non-Response to Traceroute Echo Requests................... 23 - 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23 - 4.3.5 Cross Over Node Processing.................................. 24 - 5. Non-compliant Routers.......................................... 24 - 6. OAM Considerations............................................. 25 - 7. IANA Considerations............................................ 25 - 7.1. New Sub-TLV Types............................................ 25 - 7.2. New TLVs..................................................... 26 - 8. Security Considerations........................................ 26 - 9. Acknowledgements............................................... 26 - 10. References.................................................... 26 - 10.1. Normative References........................................ 27 - 10.2. Informative References...................................... 27 - 11. Authors' Addresses............................................ 28 - 12. Full Copyright Statement...................................... 28 - -0. Change Log - - This section to be removed before publication as an RFC. - -0.1 Changes from 00 to 01 - - - Update references. - - Fix boilerplate. - -0.2 Changes from 01 to 02 - - - Update entire document so that it is not specific to MPLS-TE, but - also includes multicast LDP LSPs. - - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new - egress identifier TLV. - - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. - - Add brief section on use of LSP Ping for bootstrapping. - - Add new references to References section. - - Add details of two new authors. - -0.3 Changes from 02 to 03 - - - Update references. - - Update boilerplate. - - Fix typos. - - Clarify in 3.2.2 that a recipient of an echo request must reply - only once it has applied incoming rate limiting. - - Tidy references to bootstrapping for [MCAST-CV] in 1.1. - - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in - sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. - - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs - in sections 3.2.1 and 3.2.2. - -0.4 Changes from 03 to 04 - - - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and - 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress - Identifier TLV. - -0.5 Changes from 04 to 05 - - - Change coordinates for Tom Nadeau. Section 13. - - Fix typos. - - Update references. - - Resolve all acronym expansions. - -0.6 Changes from 05 to 06 - - - New section, 3.2.6, to explain echo response reporting in the Ping - case. - - New section, 3.3.7, to explain echo response reporting in the - Traceroute case. - - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification - of bud nodes. Use the B-flag in a Downstream Mapping TLV with a - zero address to provide the necessary indication. - - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379 - - Section 7. Suggest values for IANA assignment. - - Rename "P2MP Responder Identifier TLV" to "P2MP Responder - Identifier TLV", "Egress Identifier sub-TLV" to "Responder - Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP - responder". This allows any LSR on the P2MP LSP to be the target - of, or responder to, an echo request. - -0.7 Changes from 06 to 07 - - - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections - 3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV. - Introduce new Node Properties TLV with Branching Properties and - Egress Address sub-TLVs. - - Section 3.3.2.4: Clarify rules on presence of Multipath Information - in Downstream Mapping TLVs. - - Section 3.3.5: Clarify padding rules. - - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for - multiple return conditions reported by a single echo response. - - Section 7: Update IANA values and add new sub-sections. - - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. - - Section 13: Update Bill Fenner's coordinates. - -0.8 Changes from 07 to 08 - - Removed the Node Properties TLV (Section 3.3.2.1 of version 07). - - Removed the New Multipath Type from Multipath Sub-TLV (Section - 3.3.5 of version 07). - - Removed the Return Code Sub-TLV from Downstream Detailed TLV - (Section 3.3.6.1 of version 07), as it is already included in - draft-ietf-mpls-lsp-ping-enhanced-dsmap-02. - - - Clarified the behavior of Responder Identifier TLV (Section - 3.2.4 of version 07). Two new Sub-TLVs are introduced. - - Downstream Detailed Mapping TLV is now mandatory for implementing - P2MP OAM functionality. - - Split Multicast LDP TLV into two TLVs, one for P2MP and other for - MP2MP. Also added description to allow MP2MP ping by using this - draft. - - Removed Section 4. as it was a duplicate of Section 2.3. - -0.9 Changes from 08 to 09 - - Reformatted the document to follow the RFC4379 style. After the - Motivations section is the Packet Format section, followed by the - Operations section. The sections on Ping and Traceroute have been - merged. - - Added a Respond if TTL Expired Flag. - - Removed reference to [MCAST-CV]. - -0.10 Changes from 09 to 10 - - Removed references to bootstrapping other OAM protocols. This draft - does not provide any details of such methods. Hence it is cleaner - to remove such references. - - Minor edits based on comments. - -0.11 Changes from 10 to 11 - - Updated behavior of T bit when no label is present. - - Clarified that Egress Address TLV is not applicable to tracing in - Multicast LDP trees. - - Changed expected processing at bud nodes upon receipt of Node - Address Responder Identifier TLV from egress node only to - combination of egress and branch node. - - Added details on how Downstream Detailed Mapping TLV should be - filled for cross-over node scenario. - - Various edits based on comments. + 1. Introduction.................................................... 3 + 1.1. Design Considerations......................................... 4 + 2. Notes on Motivation............................................. 4 + 2.1. Basic Motivations for LSP Ping................................ 4 + 2.2. Motivations for LSP Ping for P2MP LSPs........................ 5 + 3. Packet Format................................................... 7 + 3.1. Identifying the LSP Under Test................................ 7 + 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7 + 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 8 + 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8 + 3.1.2. Identifying a Multicast LDP LSP............................. 9 + 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9 + 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11 + 3.2. Limiting the Scope of Responses.............................. 11 + 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12 + 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12 + 3.3. Preventing Congestion of Echo Responses...................... 12 + 3.4. Respond Only If TTL Expired Flag............................. 13 + 3.5. Downstream Detailed Mapping TLV.............................. 14 + 4. Operation of LSP Ping for a P2MP LSP........................... 14 + 4.1. Initiating Router Operations................................. 14 + 4.1.1. Limiting Responses to Echo Requests........................ 15 + 4.1.2. Jittered Responses to Echo Requests........................ 15 + 4.2. Responding Router Operations................................. 16 + 4.2.1. Echo Response Reporting.................................... 17 + 4.2.1.1. Responses from Transit and Branch nodes.................. 17 + 4.2.1.2. Responses from Egress Nodes.............................. 18 + 4.2.1.3. Responses from Bud Nodes................................. 18 + 4.3. Special Considerations for Traceroute........................ 20 + 4.3.1. End of Processing for Traceroutes.......................... 20 + 4.3.2. Multiple responses from Bud and Egress Nodes............... 21 + 4.3.3. Non-Response to Traceroute Echo Requests................... 21 + 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21 + 4.3.5 Cross Over Node Processing.................................. 22 + 5. Non-compliant Routers.......................................... 22 + 6. OAM Considerations............................................. 23 + 7. IANA Considerations............................................ 23 + 7.1. New Sub-TLV Types............................................ 23 + 7.2. New TLVs..................................................... 24 + 8. Security Considerations........................................ 24 + 9. Acknowledgements............................................... 24 + 10. References.................................................... 24 + 10.1. Normative References........................................ 25 + 10.2. Informative References...................................... 25 + 11. Authors' Addresses............................................ 26 + 12. Full Copyright Statement...................................... 26 1. Introduction Simple and efficient mechanisms that can be used to detect data plane failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSP) are described in [RFC4379]. The techniques involve information carried in MPLS "Echo Request" and "Echo Reply" messages, and mechanisms for transporting them. The echo request and reply messages provide sufficient information to check correct operation of the data plane, as well as a mechanism to @@ -269,21 +150,21 @@ As for P2P LSPs, a critical requirement is that the echo request messages follow the same data path that normal MPLS packets traverse. However, it can be seen this notion needs to be extended for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so that it arrives at each egress (or leaf) of the P2MP tree. MPLS echo requests are meant primarily to validate the data plane, and they can then be used to validate data plane state against the control plane. They may also be used to bootstrap other OAM - procedures such as [MPLS-BFD]. As pointed out in [RFC4379], + procedures such as [RFC5884]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP Ping and are not covered in this document. As is described in [RFC4379], to avoid potential Denial of Service attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to the control plane. A rate limiter should be applied to the well-known UDP port defined for use by LSP Ping traffic. 2. Notes on Motivation @@ -1206,22 +1088,22 @@ 9. Acknowledgements The authors would like to acknowledge the authors of [RFC4379] for their work which is substantially re-used in this document. Also thanks to the members of the MBONED working group for their review of this material, to Daniel King and Mustapha Aissaoui for their review, and to Yakov Rekhter for useful discussions. The authors would like to thank Bill Fenner, Vanson Lim, Danny Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin - Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar - and IJsbrand Wijnands for their comments and suggestions. + Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, + Sam Aldrin and IJsbrand Wijnands for their comments and suggestions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. @@ -1251,23 +1133,23 @@ [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp, work in progress. - [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., - "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in - progress. + [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., + "Bidirectional Forwarding Detection (BFD) for MPLS Label + Switched Paths (LSPs)", RFC 5884, June 2010. [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 11. Authors' Addresses Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan Phone: +81 3 5205 5341