diff options
Diffstat (limited to 'doc/rfc/rfc6426.txt')
| -rw-r--r-- | doc/rfc/rfc6426.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc6426.txt b/doc/rfc/rfc6426.txt new file mode 100644 index 0000000..4fc0cde --- /dev/null +++ b/doc/rfc/rfc6426.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Gray +Request for Comments: 6426 Ericsson +Updates: 4379 N. Bahadur +Category: Standards Track Juniper Networks, Inc. +ISSN: 2070-1721 S. Boutros + Cisco Systems, Inc. + R. Aggarwal + November 2011 + + + MPLS On-Demand Connectivity Verification and Route Tracing + +Abstract + + Label Switched Path Ping (LSP ping) is an existing and widely + deployed Operations, Administration, and Maintenance (OAM) mechanism + for Multi-Protocol Label Switching (MPLS) Label Switched Paths + (LSPs). This document describes extensions to LSP ping so that LSP + ping can be used for on-demand connectivity verification of MPLS + Transport Profile (MPLS-TP) LSPs and pseudowires. This document also + clarifies procedures to be used for processing the related OAM + packets. Further, it describes procedures for using LSP ping to + perform connectivity verification and route tracing functions in + MPLS-TP networks. Finally, this document updates RFC 4379 by adding + a new address type and creating an IANA registry. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6426. + + + + + + + + + + + + +Gray, et al. Standards Track [Page 1] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 + 1.2. On-Demand CV for MPLS-TP LSPs Using IP Encapsulation . . . 4 + 1.3. On-Demand CV for MPLS-TP LSPs Using Non-IP + Encapsulation . . . . . . . . . . . . . . . . . . . . . . 4 + 2. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. New Address Type for Downstream Mapping TLV . . . . . . . 5 + 2.1.1. DSMAP/DDMAP Non-IP Address Information . . . . . . . . 5 + 2.2. Source/Destination Identifier TLV . . . . . . . . . . . . 7 + 2.2.1. Source/Destination Identifier TLV Format . . . . . . . 7 + 2.2.2. Source Identifier TLV . . . . . . . . . . . . . . . . 7 + 2.2.3. Destination Identifier TLV . . . . . . . . . . . . . . 8 + 2.3. Identifying Statically Provisioned LSPs and PWs . . . . . 8 + 2.3.1. Static LSP Sub-TLV . . . . . . . . . . . . . . . . . . 9 + 2.3.2. Static Pseudowire Sub-TLV . . . . . . . . . . . . . . 10 + 3. Performing On-Demand CV over MPLS-TP LSPs . . . . . . . . . . 10 + 3.1. LSP Ping with IP Encapsulation . . . . . . . . . . . . . . 11 + 3.2. On-Demand CV with IP Encapsulation, over ACH . . . . . . . 11 + 3.3. Non-IP-Based On-Demand CV, Using ACH . . . . . . . . . . . 12 + 3.4. Reverse-Path Connectivity Verification . . . . . . . . . . 13 + 3.4.1. Requesting Reverse-Path Connectivity Verification . . 13 + 3.4.2. Responder Procedures . . . . . . . . . . . . . . . . . 13 + 3.4.3. Requester Procedures . . . . . . . . . . . . . . . . . 14 + 3.5. P2MP Considerations . . . . . . . . . . . . . . . . . . . 14 + 3.6. Management Considerations for Operation with Static + MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.7. Generic Associated Channel Label (GAL) Processing . . . . 14 + 4. Performing On-Demand Route Tracing over MPLS-TP LSPs . . . . . 15 + 4.1. On-Demand LSP Route Tracing with IP Encapsulation . . . . 15 + + + + + +Gray, et al. Standards Track [Page 2] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + 4.2. Non-IP-Based On-Demand LSP Route Tracing, Using ACH . . . 15 + 4.2.1. Requester Procedure for Sending Echo Request + Packets . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2.2. Requester Procedure for Receiving Echo Response + Packets . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2.3. Responder Procedure . . . . . . . . . . . . . . . . . 16 + 4.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 16 + 4.4. ECMP Considerations . . . . . . . . . . . . . . . . . . . 16 + 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. New Source and Destination Identifier TLVs . . . . . . . . 17 + 7.2. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 17 + 7.3. New Reverse-Path Target FEC Stack TLV . . . . . . . . . . 18 + 7.4. New Pseudowire Associated Channel Type . . . . . . . . . . 18 + 7.5. New Downstream Mapping Address Type Registry . . . . . . . 18 + 8. Contributing Authors and Acknowledgements . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 + +1. Introduction + + Label Switched Path Ping (LSP ping) [RFC4379] is an Operations, + Administration, and Maintenance (OAM) mechanism for Multi-Protocol + Label Switching (MPLS) Label Switched Paths (LSPs). This document + describes extensions to LSP ping so that LSP ping can be used for + on-demand monitoring of MPLS Transport Profile (MPLS-TP) LSPs and + pseudowires. It also clarifies the procedures to be used for + processing the related OAM packets. This document describes how LSP + ping can be used for on-demand connectivity verification (Section 3) + and route tracing (Section 4) functions required in [RFC5860] and + specified in [RFC6371]. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + There is considerable opportunity for confusion in use of the terms + "on-demand connectivity verification" (CV), "on-demand route tracing" + and "LSP ping." In this document, we try to use the terms + consistently as follows: + + o LSP ping: refers to the mechanism - particularly as defined and + used in referenced material; + + + +Gray, et al. Standards Track [Page 3] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + o On-demand CV: refers to on-demand connectivity verification and -- + where both apply equally -- on-demand route tracing, as + implemented using the LSP ping mechanism extended for support of + MPLS-TP; + + o On-demand route tracing: used in those cases where the LSP ping + mechanism (as extended) is used exclusively for route tracing. + + From the perspective of on-demand CV and route tracing, we use the + concepts of "Requester" and "Responder" as follows: + + o Requester: Originator of an OAM Request message, + + o Responder: Entity responding to an OAM Request message. + + Since, in this document, all messages are assumed to be carried in an + LSP, all Request messages would be injected at the ingress to an LSP. + A Responder might or might not be at the egress of this same LSP, + given that it could receive Request messages as a result of time-to- + live (TTL) expiry. If a Reply is to be delivered via a reverse-path + LSP, the message would again be inserted at the ingress of that LSP. + +1.2. On-Demand CV for MPLS-TP LSPs Using IP Encapsulation + + LSP ping requires IP addressing on responding Label Switching Routers + (LSRs) for performing OAM on MPLS-signaled LSPs and pseudowires. In + particular, in these cases, LSP ping packets generated by a Requester + are encapsulated in an IP/UDP header with the destination address + from the 127/8 range and then encapsulated in the MPLS label stack + ([RFC4379] , [RFC5884]). A Responder uses the presence of the 127/8 + destination address to identify OAM packets and relies further on the + UDP port number to determine whether the packet is an LSP ping + packet. It is to be noted that this determination does not require + IP forwarding capabilities. It requires the presence of an IP host + stack, which enables responding LSRs to process packets with a + destination address from the 127/8 range. [RFC1122] allocates the + 127/8 range as "Internal host loopback address" and [RFC1812] states + that "a router SHOULD NOT forward, except over a loopback interface, + any packet that has a destination address on network 127". + +1.3. On-Demand CV for MPLS-TP LSPs Using Non-IP Encapsulation + + In certain MPLS-TP deployment scenarios, IP addressing might not be + available or use some form of non-IP encapsulation might be preferred + for on-demand CV, route tracing, and BFD packets. In such scenarios, + on-demand CV and/or route tracing SHOULD be run without IP + addressing, using the Associated Channel (ACH) channel type specified + in Section 3. + + + +Gray, et al. Standards Track [Page 4] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + Section 3.3 and Section 4.2 describe the theory of operation for + performing on-demand CV over MPLS-TP LSPs with any non-IP + encapsulation. + +2. LSP Ping Extensions + +2.1. New Address Type for Downstream Mapping TLV + + [RFC4379] defines the Downstream Mapping (DSMAP) TLV. [RFC6424] + further defines the Downstream Detailed Mapping (DDMAP) TLV. This + document defines the following new address type, which MAY be used in + any DSMAP or DDMAP TLV included in an on-demand CV message: + + Type # Address Type K Octets + ------ -------------- -------- + 5 Non IP 12 + + Figure 1: New Downstream Mapping Address Type + + The new address type indicates that no address is present in the + DSMAP or DDMAP TLV. However, IF_Num information (see definition of + "IF_Num" in [RFC6370]) for both ingress and egress interfaces, as + well as Multipath Information, is included in the format and MAY be + present. + + IF_Num values of zero indicate that no IF_Num applies in the field in + which this value appears. + + The Multipath Type SHOULD be set to zero (no multipath) when using + this address type. + + When this address type is used, on receipt of an LSP ping echo + request, interface verification MUST be bypassed. Thus, the + receiving node SHOULD only perform MPLS label control-plane/ + data-plane consistency checks. Note that these consistency checks + include checking the included identifier information. + + The new address type is also applicable to the Detailed Downstream + Mapping (DDMAP) TLV defined in [RFC6424]. + +2.1.1. DSMAP/DDMAP Non-IP Address Information + + If the DSMAP (or DDMAP) TLV is included when sending on-demand CV + packets using ACH, without IP encapsulation, the following + information MUST be included in any DSMAP or DDMAP TLV that is + included in the packet. This information forms the address portion + of the DSMAP TLV (as defined in [RFC4379]) or DDMAP TLV (as defined + in [RFC6424] using one of the address information fields defined in + + + +Gray, et al. Standards Track [Page 5] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + [RFC4379] and extended to include non-IP identifier types in this + document). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTU | Address Type | DS Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ingress IF_Num (4 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Egress IF_Num (4 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multipath Type| Depth Limit | Multipath Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: New DSMAP/DDMAP Address Format + + Address Type will be 5 (as shown in Section 2.1 above). + + Ingress IF_Num identifies the ingress interface on the target node. + A value of zero indicates that the interface is not part of the + identifier. + + Egress IF_Num identifies the egress interface on the target node. A + value of zero indicates that the interface is not part of the + identifier. + + The Multipath Type SHOULD be set to zero (no multipath) when using + this address type. + + Including this TLV, with one or the other IF_Num (but not both) set + to a non-zero value, in a request message that also includes a + Destination Identifier TLV (as described in Section 2.2), is + sufficient to identify the "per-interface" MIP in Section 7.3 of + [RFC6370]. + + Inclusion of this TLV with both IF_Num fields set to zero would be + interpreted as specifying neither an ingress, nor an egress, + interface. Note that this is the same as not including the TLV; + hence, including this TLV with both IF_Num values set to zero is NOT + RECOMMENDED. + + Including this TLV with both IF_NUM fields set to a non-zero value + will result in the responder sending a Return Code of 5 ("Downstream + Mapping Mis-match") if either IF_Num is incorrect for this LSP or PW. + + + + + + +Gray, et al. Standards Track [Page 6] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +2.2. Source/Destination Identifier TLV + +2.2.1. Source/Destination Identifier TLV Format + + The format for the identifier TLV is the same for both Source and + Destination Identifier TLVs (only the type is different). The format + is as specified in the figure below. + + 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 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Global_ID (4 Octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node_ID (4 Octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: New Source/Destination Identifier Format + + Type will be one of either 13 or 14, depending on whether the TLV in + question is a Source or Destination Identifier TLV. + + Global_ID is as defined in [RFC6370]. + + Node_ID is as defined in [RFC6370]. + +2.2.2. Source Identifier TLV + + When sending on-demand CV packets using ACH, without IP + encapsulation, there MAY be a need to identify the source of the + packet. This source identifier (Source ID) will be specified via the + Source Identifier TLV, using the Identifier TLV defined in + Section 2.2.1, containing the information specified above. + + An on-demand CV packet MUST NOT include more than one Source + Identifier TLV. The Source Identifier TLV MUST specify the + identifier of the originator of the packet. If more than one such + TLV is present in an on-demand CV request packet, then error 1 + (Malformed echo request received; see Section 3.1 of [RFC4379]) MUST + be returned, if it is possible to unambiguously identify the source + of the packet. + + + + + + + + + +Gray, et al. Standards Track [Page 7] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +2.2.3. Destination Identifier TLV + + When sending on-demand CV packets using ACH, without IP + encapsulation, there MAY be a need to identify the destination of the + packet. This destination identifier (Destination ID) will be + specified via the Destination Identifier TLV, using the Identifier + TLV defined in Section 2.2.1, containing the information specified + above. + + An on-demand CV packet MUST NOT include more than one Destination + Identifier TLV. The Destination Identifier TLV MUST specify the + destination node for the packet. If more than 1 such TLV is present + in an on-demand CV Request packet, then error 1 (Malformed echo + request received; see Section 3.1 of [RFC4379]) MUST be returned, if + it is possible to unambiguously identify the source of the packet. + +2.3. Identifying Statically Provisioned LSPs and PWs + + [RFC4379] specifies how an MPLS LSP under test is identified in an + echo request. A Target FEC Stack TLV is used to identify the LSP. + In order to identify a statically provisioned LSP and PW, new target + FEC Stack sub-TLVs are being defined. The new sub-TLVs are assigned + sub-type identifiers as follows and are described in the following + sections. + + Type # Sub-Type # Length Value Field + ------ ---------- ------ ----------- + 1 22 24 Static LSP + 1 23 32 Static Pseudowire + + Figure 4: New Target FEC Sub-Types + + + + + + + + + + + + + + + + + + + + +Gray, et al. Standards Track [Page 8] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +2.3.1. Static LSP Sub-TLV + + The format of the Static LSP sub-TLV value field is specified in the + following figure. The value fields are taken from the definitions in + [RFC6370]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Global ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Node ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Tunnel Number | LSP Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Global ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Node ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Tunnel Number | Must be Zero | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Static LSP FEC Sub-TLV + + The Source Global ID and Destination Global ID MAY be set to zero. + When set to zero, the field is not applicable. + + + + + + + + + + + + + + + + + + + + + + + + + +Gray, et al. Standards Track [Page 9] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +2.3.2. Static Pseudowire Sub-TLV + + The format of the Static PW sub-TLV value field is specified in the + following figure. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Service Identifier + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Global ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Node ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source AC-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Global ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Node ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination AC-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Static PW FEC Sub-TLV + + The Service Identifier is a 64-bit unsigned integer that is included + in the first two words, as shown. The Service Identifier identifies + the service associated with the transport path under test. The value + MAY, for example, be an Attachment Group Identifier (AGI), type 0x01, + as defined in [RFC4446]. + + The Source Global ID and Destination Global ID MAY be set to zero. + When either of these fields is set to zero, the corresponding Global + ID is not applicable. This might be done in a scenario where local + scope is sufficient for uniquely identifying services. + + The Global ID and Node ID fields are defined in [RFC6370]. The AC-ID + fields are defined in [RFC5003]. + +3. Performing On-Demand CV over MPLS-TP LSPs + + This section specifies how on-demand CV can be used in the context of + MPLS-TP LSPs. The on-demand CV function meets the on-demand + connectivity verification requirements specified in [RFC5860], + Section 2.2.3. This function SHOULD NOT be performed except in the + on-demand mode. This function SHOULD be performed between + + + +Gray, et al. Standards Track [Page 10] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + Maintenance Entity Group End Points (MEPs) and Maintenance Entity + Group Intermediate Points (MIPs) of PWs and LSPs, and between End + Points of PWs, LSPs, and Sections. In order for the on-demand CV + packet to be processed at the desired MIP, the TTL of the MPLS label + MUST be set such that it expires at the MIP to be probed. + + [RFC5586] defines an ACH mechanism for MPLS LSPs. The mechanism is a + generalization of the Associated Channel mechanism that [RFC4385] + defined for use with pseudowires. As a result, it is possible to use + a single Associated Channel Type for either an LSP or pseudowire. + + A new Pseudowire Associated Channel Type (0x0025) is defined for use + in performing on-demand connectivity verification. Its use is + described in the following sections. + + ACH TLVs SHALL NOT be associated with this channel type. + + Except as specifically stated in the sections below, message and TLV + construction procedures for on-demand CV messages are as defined in + [RFC4379]. + +3.1. LSP Ping with IP Encapsulation + + LSP ping packets, as specified in [RFC4379], are sent over the MPLS + LSP for which OAM is being performed and contain an IP/UDP packet + within them. The IP header is not used for forwarding (since LSP + forwarding is done using MPLS). The IP header is used mainly for + addressing and can be used in the context of MPLS-TP LSPs. This form + of on-demand CV OAM MUST be supported for MPLS-TP LSPs when IP + addressing is in use. + + The on-demand CV echo response message MUST be sent on the reverse + path of the LSP. The reply MUST contain IP/UDP headers followed by + the on-demand CV payload. The destination address in the IP header + MUST be set to that of the sender of the echo request message. The + source address in the IP header MUST be set to a valid address of the + replying node. + +3.2. On-Demand CV with IP Encapsulation, over ACH + + IP encapsulated on-demand CV packets MAY be sent over the MPLS LSP + using the control channel (ACH). The IP ACH type specified in + [RFC4385] MUST be used in such a case. The IP header is used mainly + for addressing and can be used in the context of MPLS-TP LSPs. + + Note that the application-level control channel in this case is the + reverse path of the LSP (or Pseudowire) using ACH. + + + + +Gray, et al. Standards Track [Page 11] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + The on-demand CV echo response message MUST be sent on the reverse + path of the LSP. The response in this case SHOULD use ACH and SHOULD + be IP encapsulated. + + If IP encapsulated, the destination address in the IP header MUST be + set to that of the sender of the echo request message, and the source + address in the IP header MUST be set to a valid address of the + replying node. + +3.3. Non-IP-Based On-Demand CV, Using ACH + + The OAM procedures defined in [RFC4379] require the use of IP + addressing, and in some cases IP routing, to perform OAM functions. + + When the ACH header is used, IP addressing and routing is not needed. + This section describes procedures for performing on-demand CV without + a dependency on IP addressing and routing. + + In the non-IP case, when using on-demand CV via LSP ping with the ACH + header, the on-demand CV request payload MUST directly follow the ACH + header, and the LSP ping Reply mode [RFC4379] in the LSP ping echo + request SHOULD be set to 4 (Reply via application level control + channel). + + Note that the application-level control channel in this case is the + reverse path of the LSP (or pseudowire) using ACH. + + The requesting node MAY attach a Source Identifier TLV (Section 2.2) + to identify the node originating the request. + + If the Reply mode indicated in an on-demand CV Request is 4 (Reply + via application level control channel), the on-demand CV reply + message MUST be sent on the reverse path of the LSP using ACH. The + on-demand CV payload MUST directly follow the ACH header, and IP + and/or UDP headers MUST NOT be attached. The responding node MAY + attach a Source Identifier TLV to identify the node sending the + response. + + If a node receives an MPLS echo request packet over ACH, without IP/ + UDP headers, with a reply mode of 4, and if that node does not have a + return MPLS LSP path to the echo request source, then the node SHOULD + drop the echo request packet and not attempt to send a response. + + If a node receives an MPLS echo request with a reply mode other than + 4 (Reply via application level control channel), and if the node + supports that reply mode, then it MAY respond using that reply mode. + If the node does not support the reply mode requested, or is unable + to reply using the requested reply mode in any specific instance, the + + + +Gray, et al. Standards Track [Page 12] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + node MUST drop the echo request packet and not attempt to send a + response. + +3.4. Reverse-Path Connectivity Verification + +3.4.1. Requesting Reverse-Path Connectivity Verification + + A new Global flag, Validate Reverse Path (R), is being defined in the + LSP ping packet header. When this flag is set in the echo request, + the Responder SHOULD return reverse-path FEC information, as + described in Section 3.4.2. + + The R flag MUST NOT be set in the echo response. + + The Global Flags field is now a bit vector with the following format: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ |R|T|V| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Global Flags Field + + The V flag is defined in [RFC4379]. The T flag is defined in + [RFC6425]. The R flag is defined in this document. + + The Validate FEC Stack (V) flag MAY be set in the echo response when + reverse-path connectivity verification is being performed. + +3.4.2. Responder Procedures + + When the R flag is set in the echo request, the responding node + SHOULD attach a Reverse-path Target FEC Stack TLV in the echo + response. The requesting node (on receipt of the response) can use + the Reverse-path Target FEC Stack TLV to perform reverse-path + connectivity verification. For co-routed bidirectional LSPs, the + Reverse-path Target FEC Stack used for the on-demand CV will be the + same in both the forward and reverse path of the LSP. For associated + bidirectional LSPs, the Target FEC Stack MAY be different for the + reverse path. + + The format of the Reverse-path Target FEC Stack TLV is the same as + that of the Target FEC Stack TLV defined in [RFC4379]. The rules for + creating a Target FEC Stack TLV also apply to the Reverse-path Target + FEC Stack TLV. + + + + + +Gray, et al. Standards Track [Page 13] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + Type Meaning + -------- ------------------------------------ + 16 Reverse-path Target FEC Stack + + Figure 8: Reverse-Path Target FEC Stack TLV Type + +3.4.3. Requester Procedures + + On receipt of the echo response, the requesting node MUST perform the + following checks: + + 1. Perform interface and label-stack validation to ensure that the + packet is received on the reverse path of the bidirectional LSP. + + 2. If the Reverse-path Target FEC Stack TLV is present in the echo + response, then perform FEC validation. + + The verification in this case is performed as described for the + Target FEC Stack in Section 3.6 of [RFC4379]. + + If any of the validations fail, then the requesting node MUST drop + the echo response and SHOULD log and/or report an error. + +3.5. P2MP Considerations + + [RFC6425] describes how LSP ping can be used for OAM on P2MP LSPs + with IP encapsulation. This MUST be supported for MPLS-TP P2MP LSPs + when IP addressing is used. When IP addressing is not used, then the + procedures described in Section 3.3 can be applied to P2MP MPLS-TP + LSPs as well. + +3.6. Management Considerations for Operation with Static MPLS-TP + + Support for on-demand CV on a static MPLS-TP LSP or pseudowire MAY + require manageable objects to allow, for instance, configuring + operating parameters such as identifiers associated with the + statically configured LSP or PW. + + The specifics of this manageability requirement are out-of-scope in + this document and SHOULD be addressed in appropriate management + specifications. + +3.7. Generic Associated Channel Label (GAL) Processing + + At the Requester, when encapsulating the LSP echo request (LSP ping) + packet (with the IP ACH, or the Non IP ACH, codepoint), a GAL MUST be + added before adding the MPLS LSP label, and sending the LSP Ping echo + request packet in-band in the MPLS LSP. + + + +Gray, et al. Standards Track [Page 14] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + The GAL MUST NOT be considered as part of the MPLS label stack that + requires verification by the Responder. For this reason, a Nil FEC + TLV MUST NOT be added or associated with the GAL. + + The GAL MUST NOT be included in DSMAP or DDMAP TLVs. + + Interface and Label Stack TLVs MUST include the whole label stack + including the GAL. + +4. Performing On-Demand Route Tracing over MPLS-TP LSPs + + This section specifies how on-demand CV route tracing can be used in + the context of MPLS-TP LSPs. The on-demand CV route tracing function + meets the route tracing requirement specified in [RFC5860], Section + 2.2.3. + + This function SHOULD be performed on-demand. This function SHOULD be + performed between End Points and Intermediate Points of PWs and LSPs, + and between End Points of PWs, LSPs and Sections. + + When performing on-demand CV route tracing, the requesting node + inserts a Downstream Mapping TLV to get the downstream node + information and to enable LSP verification along the transit nodes. + The Downstream Mapping TLV can be used as is for performing route + tracing. If IP addressing is not in use, then the Address Type field + in the Downstream Mapping TLV can be set to "Non IP" (Section 2.1). + The Downstream Mapping TLV address type field can be extended to + include other address types as needed. + +4.1. On-Demand LSP Route Tracing with IP Encapsulation + + The mechanics of on-demand CV route tracing are similar to those + described for ping in Section 3.1. On-demand route tracing packets + sent by the Requester MUST follow procedures described in [RFC4379]. + This form of on-demand CV OAM MUST be supported for MPLS-TP LSPs, + when IP addressing is used. + +4.2. Non-IP-Based On-Demand LSP Route Tracing, Using ACH + + This section describes procedures for performing LSP route tracing + when using LSP ping with the ACH header and without any dependency on + IP addressing. The procedures specified in Section 3.3 with regards + to the Source Identifier TLV apply to LSP route tracing as well. + + + + + + + + +Gray, et al. Standards Track [Page 15] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +4.2.1. Requester Procedure for Sending Echo Request Packets + + On-demand route tracing packets sent by the Requester MUST adhere to + the format described in Section 3.3. MPLS-TTL expiry (as described + in [RFC4379]) will be used to direct the packets to specific nodes + along the LSP path. + +4.2.2. Requester Procedure for Receiving Echo Response Packets + + The on-demand CV route tracing responses will be received on the LSP + itself, and the presence of an ACH header with channel type of on- + demand CV is an indicator that the packet contains an on-demand CV + payload. + +4.2.3. Responder Procedure + + When an echo request reaches the Responder, the presence of the ACH + channel type of on-demand CV will indicate that the packet contains + on-demand CV data. The on-demand CV data, the label stack, and the + destination identifier are sufficient to identify the LSP associated + with the echo request packet. If there is an error and the node is + unable to identify the LSP on which the echo response would be sent, + the node MUST drop the echo request packet and not send any response + back. All responses MUST always be sent on an LSP path using the ACH + header and ACH channel type of on-demand CV. + +4.3. P2MP Considerations + + [RFC6425] describes how LSP ping can be used for OAM on P2MP LSPs. + This MUST be supported for MPLS-TP P2MP LSPs when IP addressing is + used. When IP addressing is not used, then the procedures described + in Section 4.2 can be applied to P2MP MPLS-TP LSPs as well. + +4.4. ECMP Considerations + + On-demand CV using ACH SHOULD NOT be used when there is ECMP (Equal + Cost Multi-Path) for a given LSP. The inclusion of the additional + ACH header can modify the hashing behavior for OAM packets that could + result in incorrect monitoring of the path taken by data traffic. + +5. Applicability + + The procedures specified in this document for non-IP encapsulation + apply to MPLS-TP transport paths. This includes LSPs and PWs when IP + encapsulation is not desired. However, when IP addressing is used, + as in non MPLS-TP LSPs, procedures specified in [RFC4379] MUST be + used. + + + + +Gray, et al. Standards Track [Page 16] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +6. Security Considerations + + This document does not itself introduce any new security + considerations. Those discussed in [RFC4379] are applicable to this + document. + + Unlike typical deployment scenarios identified in [RFC4379], however, + likely deployments of on-demand CV for transport paths involves a + strong possibility that the techniques in this document may be used + across MPLS administrative boundaries. Where this may occur, it is + RECOMMENDED that on-demand OAM is configured as necessary to ensure + that Source Identifier TLVs are included in on-demand CV messages. + This will allow implementations to filter OAM messages arriving from + an unexpected or unknown source. + +7. IANA Considerations + +7.1. New Source and Destination Identifier TLVs + + IANA has assigned the following TLV types from the "Multi-Protocol + Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" + registry, "TLVs and sub-TLVs" sub-registry (from the "Standards + Action" TLV type range): + + Length + Type # TLV Name Octets Reference + ------ ----------------- ------ --------------------------- + 13 Source ID 8 this document (Section 2.2) + 14 Destination ID 8 this document (Section 2.2) + + Figure 9: New Source and Destination Identifier TLV Types + +7.2. New Target FEC Stack Sub-TLVs + + Section 2.3 defines 2 new sub-TLV types for inclusion within the LSP + ping [RFC4379] Target FEC Stack TLV (1). + + IANA has assigned sub-type values to the following sub-TLVs from the + "Multi-Protocol Label Switching Architecture (MPLS) Label Switched + Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub- + registry. + + Value Meaning Reference + ----- ------------------- ----------------------------- + 22 Static LSP this document (Section 2.4.1) + 23 Static Pseudowire this document (Section 2.4.2) + + + + + +Gray, et al. Standards Track [Page 17] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +7.3. New Reverse-Path Target FEC Stack TLV + + Section 3.4.2 defines a new TLV type for inclusion in the LSP ping + packet. + + IANA has assigned a type value to the TLV from the "Multi-Protocol + Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping + Parameters" registry, "TLVs and sub-TLVs" sub-registry. + + Type Meaning Reference + ----- -------------------------- --------------------------- + 16 Reverse-path Target FEC this document (Section 3.4) + Stack TLV + + The sub-TLV space and assignments for this TLV will be the same as + that for the Target FEC Stack TLV. Sub-types for the Target FEC + Stack TLV and the Reverse-path Target FEC Stack TLV MUST be kept the + same. Any new sub-type added to the Target FEC Stack TLV MUST apply + to the Reverse-path Target FEC Stack TLV as well. + +7.4. New Pseudowire Associated Channel Type + + On-demand connectivity verification requires a unique Associated + Channel Type. IANA has assigned a PW ACH Type from the "Pseudowire + Associated Channel Types" registry as described below: + + Value Description TLV Follows Reference + ------ ------------- ----------- ------------------------- + 0x0025 On-Demand CV No this document (Section 3) + + ACH TLVs SHALL NOT be associated with this channel type. + +7.5. New Downstream Mapping Address Type Registry + + [RFC4379] defined several registries. It also defined some value + assignments without explicitly asking for IANA to create a registry + to support additional value assignments. One such case is in + defining address types associated with the Downstream Mapping (DSMAP) + TLV. + + This document extends RFC 4379 by defining a new address type for use + with the Downstream Mapping and Downstream Detailed Mapping TLVs. + + Recognizing that the absence of a registry makes it possible to have + collisions of "address-type" usages, IANA has established a new + registry -- associated with both [RFC4379] and this document -- that + initially allocates the following assignments: + + + + +Gray, et al. Standards Track [Page 18] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + Type # Address Type K Octets Reference + ------ ------------ -------- -------------------------- + 1 IPv4 Numbered 16 RFC 4379 + 2 IPv4 Unnumbered 16 RFC 4379 + 3 IPv6 Numbered 40 RFC 4379 + 4 IPv6 Unnumbered 28 RFC 4379 + 5 Non IP 12 this document (Sect. 2.1.1) + + Downstream Mapping Address Type Registry + + Because the field in this case is an 8-bit field, the allocation + policy for this registry is "Standards Action." + +8. Contributing Authors and Acknowledgements + + The following individuals contributed materially to this document: + + o Thomas D. Nadeau, CA Technologies + + o Nurit Sprecher, Nokia Siemens Networks + + o Yaacov Weingarten, Nokia Siemens Networks + + In addition, we would like to thank the following individuals for + their efforts in reviewing and commenting on the document: + + o Adrian Farrel + + o Alexander Vaishtein + + o David Sinicrope (Routing Directorate) + + o Greg Mirsky + + o Hideki Endo + + o Huub van Helvoort + + o Joel Halpern (Routing Directorate) + + o Loa Andersson + + o Mach Chen + + o Mahesh Akula + + o Sam Aldrin + + + + +Gray, et al. Standards Track [Page 19] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + o Sandra Murphy (Security Directorate) + + o Yaacov Weingarten + + o Yoshinori Koike + + o Zhenlong Cui + +9. References + +9.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 G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, February 2006. + + [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic + Associated Channel", RFC 5586, June 2009. + + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. + + [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for + Performing Label Switched Path Ping (LSP Ping) over MPLS + Tunnels", RFC 6424, November 2011. + + [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, + S., and T. Nadeau, "Detecting Data-Plane Failures in + Point-to-Multipoint MPLS - Extensions to LSP Ping", + RFC 6425, November 2011. + +9.2. Informative References + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + + +Gray, et al. Standards Track [Page 20] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + + [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, + "Attachment Individual Identifier (AII) Types for + Aggregation", RFC 5003, September 2007. + + [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for + Operations, Administration, and Maintenance (OAM) in MPLS + Transport Networks", RFC 5860, May 2010. + + [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, + "Bidirectional Forwarding Detection (BFD) for MPLS Label + Switched Paths (LSPs)", RFC 5884, June 2010. + + [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and + Maintenance Framework for MPLS-Based Transport Networks", + RFC 6371, September 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gray, et al. Standards Track [Page 21] + +RFC 6426 MPLS On-Demand Connectivity Verification November 2011 + + +Authors' Addresses + + Eric Gray + Ericsson + 900 Chelmsford Street + Lowell, MA 01851 + US + + Phone: +1 978 275 7470 + EMail: eric.gray@ericsson.com + + + Nitin Bahadur + Juniper Networks, Inc. + 1194 N. Mathilda Avenue + Sunnyvale, CA 94089 + US + + Phone: +1 408 745 2000 + EMail: nitinb@juniper.net + URI: www.juniper.net + + + Sami Boutros + Cisco Systems, Inc. + 3750 Cisco Way + San Jose, CA 95134 + US + + EMail: sboutros@cisco.com + + + Rahul Aggarwal + + EMail: raggarwa_1@yahoo.com + + + + + + + + + + + + + + + + +Gray, et al. Standards Track [Page 22] + |