--- 1/draft-ietf-mpls-lsp-ping-06.txt 2006-02-05 00:41:13.000000000 +0100 +++ 2/draft-ietf-mpls-lsp-ping-07.txt 2006-02-05 00:41:13.000000000 +0100 @@ -1,19 +1,18 @@ - Network Working Group K. Kompella Internet Draft Juniper Networks Category: Standards Track G. Swallow -Expires: January 2005 Cisco Systems - July 2004 +Expires: April 2005 Cisco Systems + October 2004 Detecting MPLS Data Plane Failures - draft-ietf-mpls-lsp-ping-06.txt + draft-ietf-mpls-lsp-ping-07.txt *** DRAFT *** Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering @@ -42,33 +41,28 @@ used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. Changes since last revision (This section to be removed before publication.) - *** Changed the format of an L2 circuit ID FEC back to what it was, - on demand. Added a new FEC with sender's PE address field to - uniquely identify the VC ID *** - - *** Added a FEC TLV for "Labeled BGP IPv4" *** - - Reformatted section on Downstream Mapping + Added a new error code for Downstream Mapping Mismatch. - Described issue with (and solution to) problem with VPN IPv4/6 + Split TLV space into "mandatory" and "optional"; updated IANA + allocation policies to reflect this. - Rephrased section on receiving an LSP ping + Added two new top-level TLVs for LSR Self Test. - Clarified "Expert Review" allocation policy. + Added a new optional top-level TLV for "Errored TLVs" 1. Introduction This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSPs. There are two parts to this document: information carried in an MPLS "echo request" and "echo reply"; and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. @@ -99,25 +94,25 @@ return path. It is suggested that first-time readers skip the actual packet formats and read the Theory of Operation first; the document is structured the way it is to avoid forward references. 1.3. Contributors The following made vital contributions to all aspects of this document, and much of the material came out of debate and discussion among this group. - Ronald P. Bonica, MCI + Ronald P. Bonica, Juniper Networks, Inc. Dave Cooper, Global Crossing - Ping Pan, Ciena + Ping Pan, Hammerhead Systems Nischal Sheth, Juniper Networks, Inc. - Sanjay Wadhwa, Juniper Networks + Sanjay Wadhwa, Juniper Networks, Inc. 2. Motivation When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time; and a mechanism to isolate faults. In this document, we describe a mechanism that accomplishes these @@ -258,20 +252,33 @@ octets. The Value field depends on the Type; it is zero padded to align to a four-octet boundary. Type # Value Field ------ ----------- 1 Target FEC Stack 2 Downstream Mapping 3 Pad 4 Error Code 5 Vendor Enterprise Code + 6 TBD + 7 IPv4 Interface and Label Stack Object + 8 IPv6 Interface and Label Stack Object + 9 Errored TLVs + + Types with the high order bit not set (i.e., 1) are mandatory TLVs + that MUST either be supported by an implementation or result in the + return code of 2 ("One or more of the TLVs was not understood") being + sent in the echo response. + + Types with the high order bit not set (i.e., 0) are optional TLVs + that MUST be ignored if the implementation does not support or + understand them. 3.1. Return Codes The Return Code is set to zero by the sender. The receiver can set it to one of the values listed below. The notation refers to the Return Subcode. This field is filled in with the stack-depth for those codes which specify that. For all other codes the Return Subcode MUST be set to zero. Value Meaning @@ -283,41 +290,46 @@ 1 Malformed echo request received 2 One or more of the TLVs was not understood 3 Replying router is an egress for the FEC at stack depth 4 Replying router has no mapping for the FEC at stack depth - 5 Reserved + 5 Downstream Mapping Mismatch (See Note 1) 6 Reserved 7 Reserved 8 Label switched at stack-depth + 9 Label switched but no MPLS forwarding at stack-depth 10 Mapping for this FEC is not the given label at stack depth 11 No label entry at stack-depth - 12 Protocol not associated with interface at FEC stack depth 13 Premature termination of ping due to label stack shrinking to a single label + Note 1. The Return Subcode contains the point in the label stack + where processing was terminated. If the RSC is 0, no labels + were processed. Otherwise the packet would have been label + switched at depth RSC. + 3.2. Target FEC Stack A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by the looking at the sub-TLV length fields. Sub-Type # Length Value Field ---------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix 3 20 RSVP IPv4 Session Query @@ -811,20 +825,153 @@ should the reason arise. 3.6. Vendor Enterprise Code The Length is always 4; the value is the SMI Enterprise code, in network octet order, of the vendor with a Vendor Private extension to any of the fields in the fixed part of the message, in which case this TLV MUST be present. If none of the fields in the fixed part of the message have vendor private extensions, this TLV is OPTIONAL. +3.7. Interface and Label Stack Object + + The Interface and Label Stack Object is an optional TLV. It is used + in a Reply message to report the interface on which the Request + Message was received and the label stack which was on the packet when + it was received. Only one such object may appear. The purpose of + the object is to allow the upstream router to obtain the exact + interface and label stack information as it appears at the replying + LSR. It has two formats, type 7 for IPv4 and type 8 for IPv6 (to be + assigned by IANA). + +3.8. IPv4 Interface and Label Stack Object + + The Length is 8 + 4*N octets, N is the number of Downstream Labels. + The value field of a Interface and Label Stack TLV has the following + format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Downstream IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Downstream Interface Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . + . Label Stack . + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Downstream IPv4 Address + + If the address type is 'No Address', the address field MUST be + set to zero and ignored on receipt. + + If the address type is 'IPv4', the address field MUST either be + set to the downstream LSR's Router ID or the downstream LSR's + interface address. + + If the address type is 'unnumbered', the address field MUST be + set to the downstream LSR's Router ID. + + Downstream Interface Address + + If the address type is 'IPv4', the interface address field MUST + MUST be set to the downstream LSR's interface address. + + If the address type is 'unnumbered', interface address field + MUST be set to the index assigned by the downstream LSR to the + interface. + + Label Stack + The label stack of the received echo request message. If any + TTL values have been changed by this router, they SHOULD be + restored. + +3.9. IPv6 Interface and Label Stack Object + + The Length is 32 + 4*N octets, N is the number of Downstream Labels. + The value field of a Interface and Label Stack TLV has the following + format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Downstream IPv6 Address | + | Downstream IPv6 Address (Cont.) | + | Downstream IPv6 Address (Cont.) | + | Downstream IPv6 Address (Cont.) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Downstream Interface Address | + | Downstream Interface Address (Cont.) | + | Downstream Interface Address (Cont.) | + | Downstream Interface Address (Cont.) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . + . Label Stack . + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Downstream IPv6 Address + + If the address type is 'No Address', the address field MUST be + set to zero and ignored on receipt. + + If the address type is 'IPv6', the address field MUST either be + set to the downstream LSR's Router ID or the downstream LSR's + interface address. + + If the address type is 'unnumbered', the address field MUST be + set to the downstream LSR's Router ID. + + Downstream Interface Address + + If the address type is 'IPv6', the interface address field MUST + MUST be set to the downstream LSR's interface address. + + If the address type is 'unnumbered', first four octets of + interface address field MUST be set to the index assigned by + the downstream LSR to the interface. The remaining 12 octets + MUST be set to zero. + + Label Stack + + The label stack of the received echo request message. If any + TTL values have been changed by this router, they SHOULD be + restored. + +3.10. Errored TLVs + + The following TLV is an optional TLV defined to be sent back to the + sender of an Echo Request to inform it of Mandatory TLVs either not + supported by an implementation, or parsed and found to be in error. + + The Value field contains the TLVs not understood encoded as subtlvs. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 32678 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value | + . . + . . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4. Theory of Operation An MPLS echo request is used to test a particular LSP. The LSP to be tested is identified by the "FEC Stack"; for example, if the LSP was set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC stack contains a single element, namely, an LDP IPv4 prefix sub-TLV with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the FEC stack consists of a single element that captures the RSVP Session and Sender Template which uniquely identifies the LSP. @@ -1179,36 +1326,37 @@ Expert Review; values in the range 252-255 are for Vendor Private Use, and MUST NOT be allocated. If any of these fields fall in the Vendor Private range, a top-level Vendor Enterprise Code TLV MUST be present in the message. 5.2. TLVs It is requested that IANA maintain registries for the Type field of top-level TLVs as well as for sub-TLVs. The valid range for each of - these is 0-65535. Assignments in the range 0-32767 are made via - Standards Action as defined in {IANA]; assignments in the range - 32768-64511 are made via Expert Review (see below); values in the - range 64512-65535 are for Vendor Private Use, and MUST NOT be - allocated. + these is 0-65535. Assignments in the range 0-16383 and 32768-49161 + are made via Standards Action as defined in [IANA]; assignments in + the range 16384-31743 and 49162-64511 are made via Expert Review (see + below); values in the range 31744-32746 and 64512-65535 are for + Vendor Private Use, and MUST NOT be allocated. If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Enterprise Code, in network octet order. The rest of the Value field is private to the vendor. Acknowledgments This document is the outcome of many discussions among many people, that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa - Gan, Brook Bailey, Eric Rosen, Ina Minei and Shivani Aggarwal. + Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vansom + Lim. The description of the Multipath Information sub-field of the Downstream Mapping TLV was adapted from text suggested by Curtis Villamizar. Appendix This appendix specifies non-normative aspects of detecting MPLS data plane liveness.