RFC 6426

MPLS On-Demand Connectivity Verification and Route Tracing

📅 published November 2011, from ietf

RFC 6426 💖 MPLS On-Demand Connectivity Verification and Route Tracing

Okay bestie, here's the deets 🧚

  • Number: RFC 6426 🎀
  • Title: MPLS On-Demand Connectivity Verification and Route Tracing
  • Authors: E. Gray (Ericsson), N. Bahadur (Juniper Networks, Inc.), S. Boutros (Cisco Systems, Inc.), and R. Aggarwal (no affiliation listed)
  • Category: Standards Track 👑
  • Date: November 2011
  • ISSN: 2070-1721
  • Updates: 4379 🦋
  • Obsoletes: not listed in the title block 🙈

It's from the IETF (Internet Engineering Task Force) and it's a whole mood ✨

Abstract ✨

Okay so, LSP ping (Label Switched Path Ping) is already a real, widely used OAM (Operations, Administration, and Maintenance) tool for MPLS (Multi-Protocol Label Switching) LSPs (Label Switched Paths). 💅 This doc extends LSP ping so it can do on-demand connectivity verification for MPLS-TP (MPLS Transport Profile) LSPs and pseudowires. 🌸 It also clears up how to process the related OAM packets, and it explains how LSP ping can do connectivity verification and route tracing in MPLS-TP networks. Last but not least, it updates RFC 4379 by adding a new address type and creating an IANA registry. Iconic behaviour, honestly 😭

Status of This Memo ✨

This one is an Internet Standards Track document. 👑

It's a product of the IETF, so it represents the consensus of the IETF community. It went through public review and got approved for publication by the IESG (Internet Engineering Steering Group). If you want more info on Internet Standards, check Section 2 of RFC 5741 🫶

Info on the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6426. Bookmark it, bestie 🔖

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. 📜 Please actually read those, because they spell out your rights and restrictions for this document. Also, any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. No warranty, no cap 🙈

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
     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 ✨

So, LSP ping [RFC4379] is an OAM (Operations, Administration, and Maintenance) mechanism for MPLS (Multi-Protocol Label Switching) LSPs (Label Switched Paths). 🦋 This doc extends LSP ping so it can do on-demand monitoring of MPLS-TP (MPLS Transport Profile) LSPs and pseudowires. It also explains how the related OAM packets should be processed. 💜 The doc shows how LSP ping does the on-demand connectivity verification (Section 3) and route tracing (Section 4) jobs that are required in [RFC5860] and specified in [RFC6371]. Main character energy 👑

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]. 🫶

Ngl, there's a lot of room for mix-ups with the terms "on-demand connectivity verification" (CV), "on-demand route tracing," and "LSP ping." 😭 So this doc tries to use them consistently, like this:

  • LSP ping: the mechanism itself, especially as defined and used in the referenced material.
  • On-demand CV: on-demand connectivity verification and, where both apply equally, on-demand route tracing, as done using the LSP ping mechanism extended for MPLS-TP.
  • On-demand route tracing: used when the LSP ping mechanism (as extended) is used exclusively for route tracing.

From the on-demand CV and route tracing perspective, there are two roles, the Requester and the Responder:

  • Requester: the originator of an OAM Request message.
  • Responder: the entity responding to an OAM Request message.

In this doc, every message is assumed to be carried in an LSP, so all Request messages get injected at the ingress of an LSP. 🧚 A Responder might or might not be at the egress of that same LSP, because it could receive Request messages thanks to TTL (time-to-live) expiry. And if a Reply is going to come back over a reverse-path LSP, the message gets inserted at the ingress of that LSP again. Full circle 🔁

1.2. On-Demand CV for MPLS-TP LSPs Using IP Encapsulation 🌈

Here's the tea: LSP ping needs IP addressing on the responding LSRs (Label Switching Routers) so it can do OAM on MPLS-signaled LSPs and pseudowires. 💅 In these cases, LSP ping packets made by a Requester get wrapped in an IP/UDP header with the destination address from the 127/8 range, and then they get wrapped in the MPLS label stack ([RFC4379] , [RFC5884]). 🎀 A Responder spots OAM packets by the presence of the 127/8 destination address, and then it checks the UDP port number to figure out whether the packet is an LSP ping packet. It's worth noting that this check does not require IP forwarding capabilities. ✨ It just needs an IP host stack, which lets responding LSRs process packets with a destination address from the 127/8 range. [RFC1122] assigns the 127/8 range as "Internal host loopback address", and [RFC1812] says 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 some MPLS-TP deployments, IP addressing might not be available, or some form of non-IP encapsulation might just be preferred for on-demand CV, route tracing, and BFD packets. 🌸 In those situations, on-demand CV and/or route tracing SHOULD be run without IP addressing, using the Associated Channel (ACH) channel type specified in Section 3. 🧚

Section 3.3 and Section 4.2 explain the theory of operation for doing on-demand CV over MPLS-TP LSPs with any non-IP encapsulation. 📚 Read them, bestie 💖

2. LSP Ping Extensions ✨

2.1. New Address Type for Downstream Mapping TLV 💜

[RFC4379] defines the Downstream Mapping (DSMAP) TLV. [RFC6424] goes further and defines the Downstream Detailed Mapping (DDMAP) TLV. 🔥 This doc 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 says there's no address in the DSMAP or DDMAP TLV. 🙈 But the IF_Num information for both the ingress and egress interfaces (see the definition of "IF_Num" in [RFC6370]), plus Multipath Information, are included in the format and MAY be present. 🦋 An IF_Num value of zero means no IF_Num applies in the field where that value shows up. 💅

The Multipath Type SHOULD be set to zero (no multipath) when this address type is used. ✨

When this address type is used, the receiving node MUST bypass interface verification on receipt of an LSP ping echo request. So, 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 also applies to the Detailed Downstream Mapping (DDMAP) TLV defined in [RFC6424]. 🌈

2.1.1. DSMAP/DDMAP Non-IP Address Information ✨

okay so, if you're sending a DSMAP (or DDMAP) TLV with on-demand CV packets over ACH without IP encapsulation, the following info MUST be included in any DSMAP or DDMAP TLV in that packet 💅. This is the address part of the DSMAP TLV (from [RFC4379]) or the DDMAP TLV (from [RFC6424], which uses one of the address info fields from [RFC4379] that got 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 tells you which ingress interface on the target node we're talking about 🎀. A value of zero means the interface is not part of the identifier.

Egress IF_Num tells you which egress interface on the target node we're talking about 🌸. A value of zero means the interface is not part of the identifier.

The Multipath Type SHOULD be set to zero (no multipath) when using this address type 🍓.

Okay, this next bit is a vibe 🧚. 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] 💖.

Including 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 at all, so including this TLV with both IF_Num values set to zero is NOT RECOMMENDED 🙈.

bestie, don't do the both-zeros thing. It's giving confusion 💀

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 😭.

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. The only thing that changes is the type ✨. 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 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 😤.

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. To identify a statically provisioned LSP and PW, new target FEC Stack sub-TLVs are being defined 🌸. The new sub-TLVs get sub-type identifiers as follows, and they're described in the sections after this one.

         Type #   Sub-Type #       Length        Value Field
         ------   ----------       ------        -----------
           1         22              24          Static LSP
           1         23              32          Static Pseudowire

                    Figure 4: New Target FEC Sub-Types

2.3.1. Static LSP Sub-TLV

The format of the Static LSP sub-TLV value field is shown 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.

2.3.2. Static Pseudowire Sub-TLV

The format of the Static PW sub-TLV value field is shown 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 gets included in the first two words, as shown 🌟. It 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 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. So as a result, it's 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 they contain an IP/UDP packet inside 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 it 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

okay so 💖 IP encapsulated on-demand CV packets MAY be sent over the MPLS LSP using the control channel (ACH). The IP ACH type from [RFC4385] MUST be used in that case. The IP header is mostly there for addressing, and it can be used with MPLS-TP LSPs ✨

Note that the application-level control channel here is the reverse path of the LSP (or Pseudowire) using ACH 🦋

The on-demand CV echo response message MUST be sent on the reverse path of the LSP. The response SHOULD use ACH and SHOULD be IP encapsulated 💅

If it's IP encapsulated, the destination address in the IP header MUST be set to the address 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. bestie, the addressing has to be correct or nothing gets back 🫶

3.3. Non-IP-Based On-Demand CV, Using ACH

The OAM procedures in [RFC4379] need IP addressing, and sometimes IP routing, to do their OAM thing 🙈

When the ACH header is used, IP addressing and routing aren't needed 🌸 This section explains how to do on-demand CV without depending on IP addressing and routing, and it's giving independence 👑

In the non-IP case, when on-demand CV goes through LSP ping with the ACH header, the on-demand CV request payload MUST directly follow the ACH header. The LSP ping Reply mode from [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 here is also the reverse path of the LSP (or pseudowire) using ACH 🦋

The requesting node MAY attach a Source Identifier TLV (Section 2.2) to say which node sent the request 💜

If the Reply mode 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 say which node sent the response 🎀

If a node gets an MPLS echo request packet over ACH, with no IP/UDP headers and a reply mode of 4, and that node doesn't have a return MPLS LSP path to the echo request source, then the node SHOULD drop the echo request packet and not try to send a response. no path back, no reply, periodt 💀

If a node gets an MPLS echo request with a reply mode other than 4 (Reply via application level control channel), and the node supports that reply mode, then it MAY respond using that reply mode. If the node doesn't support the requested reply mode, or can't reply using it in some specific instance, the node MUST drop the echo request packet and not try to send a response 🥺

3.4. Reverse-Path Connectivity Verification

3.4.1. Requesting Reverse-Path Connectivity Verification

okay this one is lowkey iconic 🔥 A brand new Global flag, Validate Reverse Path (R), is being added to 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. Not me setting it there 🙅‍♀️

The Global Flags field is now a bit vector with this 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. three flags, three homes, very organized 🧚

The Validate FEC Stack (V) flag MAY be set in the echo response when reverse-path connectivity verification is happening 💖

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 to the echo response. The requesting node can use that TLV, once the response comes back, to do reverse-path connectivity verification 🫶 For co-routed bidirectional LSPs, the Reverse-path Target FEC Stack used for on-demand CV is the same on 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 Reverse-path Target FEC Stack TLV has the same format as the Target FEC Stack TLV defined in [RFC4379]. The rules for making a Target FEC Stack TLV also apply to the Reverse-path Target FEC Stack TLV ✨

             Type         Meaning
             --------     ------------------------------------
                16        Reverse-path Target FEC Stack

Figure 8: Reverse-Path Target FEC Stack TLV Type 💅

3.4.3. Requester Procedures

When the echo response arrives, the requesting node MUST do the following checks. bestie, this is the verification glow-up 😭

  1. Do interface and label-stack validation, to make sure the packet arrived on the reverse path of the bidirectional LSP.
  2. If the Reverse-path Target FEC Stack TLV is in the echo response, then do FEC validation.

The verification here is done the same way as for the Target FEC Stack in Section 3.6 of [RFC4379] 🌸

If any validation fails, the requesting node MUST drop the echo response and SHOULD log and/or report an error. no ghosting the error, log it 🚨

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 isn't used, the procedures in Section 3.3 can also be applied to P2MP MPLS-TP LSPs 🌈

3.6. Management Considerations for Operation with Static MPLS-TP

On-demand CV on a static MPLS-TP LSP or pseudowire MAY need manageable objects, so you can configure operating parameters like the identifiers tied to the statically configured LSP or PW 🎀

The specifics of this manageability requirement are out of scope for this document, and they SHOULD be handled in the appropriate management specifications. that's a problem for future us, and it's giving organized delegation 📋

3.7. Generic Associated Channel Label (GAL) Processing

At the Requester, when the LSP echo request (LSP ping) packet gets encapsulated (with the IP ACH or the Non IP ACH codepoint), a GAL MUST be added before the MPLS LSP label is added, and the LSP Ping echo request packet is sent in-band in the MPLS LSP 🧚

The GAL MUST NOT be treated as part of the MPLS label stack that the Responder has to verify. For this reason, a Nil FEC TLV MUST NOT be added or associated with the GAL. the GAL is the VIP that doesn't get checked 👑

The GAL MUST NOT be included in DSMAP or DDMAP TLVs 🙅‍♀️

Interface and Label Stack TLVs MUST include the whole label stack, GAL included ✨

4. Performing On-Demand Route Tracing over MPLS-TP LSPs 🦋

This section explains how on-demand CV route tracing works with MPLS-TP LSPs 💜 The on-demand CV route tracing function meets the route tracing requirement in [RFC5860], Section 2.2.3 ✨

This function SHOULD be performed on-demand. It SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections 🫶

When doing 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 route tracing. If IP addressing isn't in use, 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 what's described for ping in Section 3.1. On-demand route tracing packets sent by the Requester MUST follow the procedures 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 explains how to do LSP route tracing using LSP ping with the ACH header, without depending on IP addressing 🎀 The procedures in Section 3.3 about the Source Identifier TLV apply to LSP route tracing too 🦋

4.2.1. Requester Procedure for Sending Echo Request Packets

On-demand route tracing packets sent by the Requester MUST match the format in Section 3.3. MPLS-TTL expiry (as described in [RFC4379]) is 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 come back on the LSP itself. An ACH header with the on-demand CV channel type tells you the packet has an on-demand CV payload, so look for that 🔥

4.2.3. Responder Procedure

When an echo request reaches the Responder, the ACH channel type of on-demand CV tells it the packet has on-demand CV data. The on-demand CV data, the label stack and the destination identifier are enough to identify the LSP associated with the echo request packet. If there's an error and the node can't identify the LSP the echo response would go on, 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 the ACH channel type of on-demand CV. no LSP, no response, no drama 💀

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 isn't used, the procedures in Section 4.2 can also be applied to P2MP MPLS-TP LSPs 🌈

4.4. ECMP Considerations

On-demand CV using ACH SHOULD NOT be used when there's ECMP (Equal Cost Multi-Path) for a given LSP. Adding the extra ACH header can change how OAM packets get hashed, which could lead to wrongly monitoring the path that data traffic takes. ngl that's a sneaky one 🙈

5. Applicability 🌸

The procedures in this document for non-IP encapsulation apply to MPLS-TP transport paths. That covers LSPs and PWs when IP encapsulation isn't wanted. However, when IP addressing is used, as in non MPLS-TP LSPs, the procedures in [RFC4379] MUST be used 💜

6. Security Considerations 🔥

This document doesn't introduce any new security considerations of its own. The ones discussed in [RFC4379] apply to this document 🔒

⚠️ Plot twist, and it's a big one: unlike the typical deployment scenarios in [RFC4379], deployments of on-demand CV for transport paths have a strong possibility of using the techniques in this document across MPLS administrative boundaries. Where that may happen, it is RECOMMENDED that on-demand OAM is configured as needed so that Source Identifier TLVs are included in on-demand CV messages. That lets implementations filter OAM messages that arrive from an unexpected or unknown source. Trust no unknown source, bestie 🚨😭

7. IANA Considerations ✨

7.1. New Source and Destination Identifier TLVs ✨

okay so IANA gave us two shiny new TLV types 💖 from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, in the "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 these 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)

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. 🔥

bestie, these two MUSTs are not optional. Keep the sub-types matched or the two TLVs drift apart 😭

7.4. New Pseudowire Associated Channel Type 💜

On-demand connectivity verification requires a unique Associated Channel Type, so IANA gave it its very own PW ACH Type from the "Pseudowire Associated Channel Types" registry 🌈

  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, and it also defined some value assignments without explicitly asking IANA to create a registry to support additional value assignments. One such case is the address types associated with the Downstream Mapping (DSMAP) TLV. It's giving "gaps in the paperwork" 💀

This document extends RFC 4379 by defining a new address type for use with the Downstream Mapping and Downstream Detailed Mapping TLVs. ⭐

Recognizing that having no registry makes it possible for "address-type" usages to collide, IANA has established a new registry, associated with both [RFC4379] and this document, that initially allocates the following assignments 👑

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: 💖

  • Thomas D. Nadeau, CA Technologies
  • Nurit Sprecher, Nokia Siemens Networks
  • 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, because they absolutely slayed the review 🙌

  • Adrian Farrel
  • Alexander Vaishtein
  • David Sinicrope (Routing Directorate)
  • Greg Mirsky
  • Hideki Endo
  • Huub van Helvoort
  • Joel Halpern (Routing Directorate)
  • Loa Andersson
  • Mach Chen
  • Mahesh Akula
  • Sam Aldrin
  • Sandra Murphy (Security Directorate)
  • Yaacov Weingarten
  • Yoshinori Koike
  • 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.
  • [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.

Authors' Addresses 🧚

Eric Gray

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

That's the whole RFC, bestie 🌈🦋✨

📦 where this page comes from