RFC 7110
Return Path Specified Label Switched Path (LSP) Ping
RFC 7110: Return Path Specified LSP Ping 🎀
okay bestie, this RFC is a whole mood ✨ it's all about letting you pick the return path for an LSP ping echo reply, so you can test both directions in one go and the test gets way more reliable 💅
The title block, the important bits 🦋
- RFC number: 7110
- Title: Return Path Specified Label Switched Path (LSP) Ping
- Authors: M. Chen and W. Cao (Huawei Technologies Co., Ltd), S. Ning (Tata Communications), F. Jounay (Orange CH), and S. Delord (no affiliation listed in the header)
- Category: Standards Track
- ISSN: 2070-1721
- Date: January 2014
- Obsoletes and updates: the header doesn't list anything it obsoletes or updates
Abstract
okay so this doc adds extensions to the data-plane failure-detection protocol for MPLS Label Switched Paths (LSPs) that everyone calls "LSP ping" 🔍 the extensions let you choose which LSP the echo reply comes back on 🛤️ forcing a specific return path can check bidirectional connectivity and make LSP ping more robust 💖
Status of This Memo 🌸
this is an Internet Standards Track document 🎀
it's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ more on Internet Standards is in Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7110 🔗
Copyright Notice 🌈
Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they were on the date it was published 📜 please read those carefully, because they spell out your rights and restrictions 🧐 any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 💜
Table of Contents 🧚
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Problem Statements and Solution Overview ........................3
3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
3.2. Limitations of Existing Mechanisms for Handling
Unreliable Return Paths ....................................4
4. Extensions ......................................................5
4.1. Reply via Specified Path Mode ..............................6
4.2. Reply Path (RP) TLV ........................................6
4.3. Tunnel Sub-TLVs ............................................8
4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
4.3.3. Static Tunnel Sub-TLV ..............................12
4.4. Reply TC TLV ..............................................12
5. Theory of Operation ............................................13
5.1. Sending an Echo Request ...................................14
5.2. Receiving an Echo Request .................................14
5.3. Sending an Echo Reply .....................................15
5.4. Receiving an Echo Reply ...................................16
5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
7.1. TLVs ......................................................17
7.2. New Target FEC Stack Sub-TLVs .............................17
7.3. New Reply Mode ............................................17
7.4. Reply Path Return Code ....................................18
8. Contributors ...................................................19
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................201. Introduction ✨
okay so this doc extends the data-plane failure-detection protocol for MPLS LSPs that everybody calls "LSP ping" [RFC4379] 💅 the new bits let you specify the return path for the echo reply message 🛤️ which means more robustness, less room for error, and a more reliable echo reply overall 🫶
it adds a new Reply Mode called "Reply via Specified Path" 🦋 and a new Type-Length-Value (TLV) called "Reply Path (RP) TLV" 💜 the procedures here only apply to "ping" mode. "traceroute" mode is out of scope for this document 🙈
quick terminology check: "bidirectional LSP" here covers two things. one is the co-routed bidirectional LSP from [RFC3945] 🌸 the other is the associated bidirectional LSP, which is built from a pair of unidirectional LSPs (one for each direction) that are linked to each other at the LSP's ingress and egress points [RFC5654] 🔗 these mechanisms can work for both IP/MPLS and MPLS Transport Profile (MPLS-TP) setups 🌈
2. Requirements Language 💖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📚
3. Problem Statements and Solution Overview 🔍
so MPLS LSP ping is defined in [RFC4379] 🎀 it can detect data-path failures in all MPLS LSPs 💅
LSPs are everywhere now, and they're increasingly used to provide bidirectional services 🌐 the co-routed bidirectional LSP is defined in [RFC3945], and the associated bidirectional LSP is defined in [RFC5654] ✨ with those services out there, operators want to test both directions of a bidirectional LSP in a single operation 🫶
there's another problem too 😬 when you test just one direction of an LSP (either a unidirectional LSP or one direction of a bidirectional LSP) with LSP ping, the result can depend on whether the echo reply actually gets delivered 📭 if the echo reply doesn't make it from the egress Label Switching Router (LSR) back to the ingress LSR, you can get false negatives 💀 the LSP under test gets reported as "down" even though it's totally working 😭
3.1. Limitations of Existing Mechanisms for Bidirectional LSPs 🧚
with the existing LSP ping mechanisms, as defined in [RFC4379], operators have to turn on LSP detection at each of the two ends of a bidirectional LSP separately 😩 that doubles the workload, and it can also cause extra trouble when checking the backward direction of the LSP under this condition:
The LSR that the operator logged on to perform the checking operations might not have out-of-band connectivity to the LSR at the far end of the LSP. That can mean it is not possible to check the return direction of a bidirectional LSP in a single operation -- the operator must log on to the LSR at the other end of the LSP to test the return direction.
associated bidirectional LSPs have the same issues as the co-routed ones 🙄
this document defines a mechanism that lets the operator ask for both directions of a bidirectional LSP to be tested by a single LSP ping message exchange 🎀
3.2. Limitations of Existing Mechanisms for Handling Unreliable Return Paths 🌸
[RFC4379] defines four Reply Modes 🌈
- Do not reply
- Reply via an IPv4/IPv6 UDP packet
- Reply via an IPv4/IPv6 UDP packet with Router Alert
- Reply via application level control channel
obviously, the return path reliability issue doesn't apply to the first one, since there's no reply at all 🙃
[RFC4379] says the third mode may be used when the IP return path is considered unreliable 🛟 but this mode needs every intermediate node to support the Router Alert option and to understand how to forward MPLS echo replies 😵 that's a seriously strict requirement in deployed IP/MPLS networks, especially since the return path might go through legacy IP-only routers 🏚️
and honestly, Reply Modes 2 or 3 can't guarantee that echo responses get through an IP network that's fundamentally unreliable 💔 when they don't arrive, you get false negatives, and the LSP looks broken when it isn't 😭
letting the ingress LSR control the path used for echo reply messages gives the operator an extra layer of deterministic process for the LSP ping test 🧠 for example, say you're testing an LSP and Reply Mode 2 is used at the start, but no echo reply comes back 👀 if you suspect the return path has failed, the operator can start another LSP ping using the Reply Mode defined in this document, and specify a different return path that seems workable to finish the test 🔁
this document defines extensions to LSP ping so you can specify the return paths of the echo reply message inside an echo request message 💜
4. Extensions 🦋
LSP ping, defined in [RFC4379], works by sending an echo request message 📨 it carries the Forwarding Equivalence Class (FEC) information of the LSP being tested 🧾 that FEC info says which MPLS path is being verified, along the same data path as other normal data packets in that FEC 🛣️
[RFC4379] defines four Reply Modes that tell the egress LSR how to send an echo reply back 💅 this document adds a new one, the "Reply via Specified Path" mode 🎀 it tells the egress LSR of the tested LSP to send the echo reply back along the path that's specified in the echo request message ✨
on top of that, two new TLVs are defined here: the "Reply Path (RP) TLV" and the "Reply Traffic Class (TC) TLV" [RFC5462] 🌈 the Reply Path TLV holds one or more nested sub-TLVs, which carry the specified return path information for the echo reply message 🫶
4.1. Reply via Specified Path Mode 🧚
a new Reply Mode is defined to go in the Reply Mode field of the echo request message 💖
the value for Reply via Specified Path mode is 5. IANA gave it out using early allocation, and IANA still needs to confirm it 🙈
Value Meaning
----- -------
5 Reply via Specified Paththe Reply via Specified Path mode asks the remote LSR that receives the echo request message to send the echo reply message back along the specified paths carried in the Reply Path TLV 🔥
4.2. Reply Path (RP) TLV ✨
okay so the Reply Path (RP) TLV is technically optional inside the LSP ping protocol 🎀 BUT if you asked for the Reply via Specified Path mode from Section 4.1, the Reply Path (RP) TLV MUST be included in your echo request message. If it's missing, that counts as a malformed echo request, as described in [RFC4379] 💀 And if an echo request does have a Reply Path (RP) TLV, then the echo reply from an implementation that's conformant to this spec MUST include one too. no cap, it's a whole vibe 💅
The Reply Path (RP) TLV carries the specified return path that the echo reply is required to follow 🦋 The format looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path return code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reply Path TLVReply Path TLV Type: it's 2 octets long, and the type value is 21 🌸
Length: also 2 octets. It tells you the length in octets of the Reply Path return code, Flags, and Reply Path fields ✨
Reply Path return code: this one is 2 octets too 🎀 The egress LSR of the forward LSP uses it to report how the Reply Path TLV processing went and how the return path was picked. It MUST be set to zero in a Reply Path TLV carried on an echo request message and MUST be ignored on receipt. Here are the Reply Path return codes this document defines for a Reply Path TLV carried on an echo reply:
Value Meaning
------ ----------------------
0x0000 Reserved, MUST NOT be used
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental UseFlags: also 2 octets 💜 The egress uses it to figure out how to process the Reply Paths field when it's doing return path selection. It's a bit vector with this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flags- A (Alternative path): the egress LSR MUST select a non-default path as the return path. This is super useful when you suspect reverse default path problems, and you can actually confirm them by forcing the echo reply onto a non-default return path 🔥 Here, the default path just means the path the egress LSR would use to send the echo reply when Reply Mode 2 or 3 is used. If the A bit is set, you don't need to carry any specific reply path sub-TLVs, and if they show up anyway, they SHOULD be ignored.
- B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP 🦋 If the B bit is set, there's no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored.
⚠️ The A flag and B flag MUST NOT both be set. If they are, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" MUST be returned. not me making the rules, but we follow them 🙈
Reply Path: this is where the return path lives 🍓 It's variable in length and can contain zero, one, or more Target FEC sub-TLVs [RFC4379]. In an echo request, it carries sub-TLVs that describe the specified path the echo reply is required to follow. In an echo reply, the sub-TLVs describe the FEC Stack information of the return path (when the return path is an MPLS path) that the echo reply will be sent along 🧚
4.3. Tunnel Sub-TLVs 🌈
okay so [RFC4379] already defined several Target FEC sub-TLVs, and those are a great way to identify a specific return path 💖 The Reply Path TLV can carry any sub-TLV defined for use in the Target FEC Stack TLV to specify the return path, including ones that exist now and ones that get defined later ✨
This document defines three new Target FEC sub-TLVs: the IPv4 RSVP Tunnel sub-TLV, the IPv6 RSVP Tunnel sub-TLV, and the Static Tunnel sub-TLV 🎀 One usage of these generic RSVP Tunnel sub-TLVs is when LSP ping is used to periodically verify the control plane against the data plane [RFC5884]. Using a Tunnel instead of a particular LSP can avoid the impact of an LSP identifier changing when Make-Before-Break (MBB) is deployed 👑 These sub-TLVs can also be used in the Reply Path TLV, so the operator can specify a more generic tunnel FEC, rather than a particular LSP, as the return path.
No assignments of sub-TLVs are made directly for TLV Type 21. The sub-TLV space and assignments for TLV Type 21 will be the same as those for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 MUST be kept the same, and any new sub-type added to TLV Type 1 MUST apply to TLV Type 21 as well 🫶
With the Return Path TLV flags and the sub-TLVs defined for the Target FEC Stack TLV and in this document, you get these options for specifying a return path 💅
- a particular LSP as return path
- use those sub-TLVs defined for the Target FEC Stack TLV
- a more generic tunnel FEC as return path
- use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of this document
- the reverse path of the bidirectional LSP as return path
- use B bit defined in Section 4.2 of this document.
- Force return path to non-default path
- use A bit defined in Section 4.2 of this document.
4.3.1. IPv4 RSVP Tunnel Sub-TLV 🦋
the format of the IPv4 RSVP Tunnel sub-TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 RSVP Tunnel Sub-TLVThe IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV defined in Section 3.2.3 of [RFC4379]. Every field has the same semantics as in [RFC4379], except that the LSP-ID field is left out and a brand-new Flags field gets added 🌸
The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets long, and the recommended type value is 26.
Flags: 2 octets long 🩵 It tells the egress LSR how to choose the return path. It's a bit vector with this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Tunnel Flags- P (Primary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel, and the LSP MUST be the primary LSP.
- S (Secondary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel, and the LSP MUST be the secondary LSP. Primary and secondary LSPs are defined in [RFC4872] 🧚
⚠️ The P bit and S bit MUST NOT both be set. If they are, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" SHOULD be returned. If both the P bit and S bit are unset, the return path could be any one of the LSPs from the same Tunnel 💜
4.3.2. IPv6 RSVP Tunnel Sub-TLV 💖
the format of the IPv6 RSVP Tunnel sub-TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 RSVP Tunnel Sub-TLVThe IPv6 RSVP Tunnel sub-TLV is derived from the RSVP IPv6 FEC TLV defined in Section 3.2.4 of [RFC4379]. Every field has the same semantics as in [RFC4379], except that the LSP-ID field is left out and a brand-new Flags field gets added ✨
The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets long, and the type value is 27.
The Flags field is 2 octets long and is identical to the one described in Section 4.3.1 🫶
4.3.3. Static Tunnel Sub-TLV ✨
okay so the Static RSVP Tunnel sub-TLV has this layout 🦋 and its value fields borrow their definitions from [RFC6370], so go check that one for the deets 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Static Tunnel Sub-TLV
The Flags field is 2 octets long and is identical to the one described in Section 4.3.1 🎀
The sub-TLV type value is 28 💜
4.4. Reply TC TLV 🌈
okay so the Reply TOS Byte TLV [RFC4379] lets the originator of the echo request ask for the echo reply to come back with the IP header TOS byte set to whatever value is in the TLV 💅 this doc does the same vibe with a brand new TLV, the Reply TC TLV 🫶 the originator of the echo request MAY use it to ask for the echo reply to be sent with the TC bits of the return path LSP set to the value in this TLV ✨ and it's not stuck to Reply via Specified Path (the Reply Mode defined in this doc). it works in all the other Reply Modes too, iconic 👑 the format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply TC TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Reply TC TLV
The Reply TC TLV Type field is 2 octets long, and the type value is 22 🌸
The Length field is 2 octets long, and its value is fixed at 4 octets 🍓
5. Theory of Operation 🔥
bestie, the procedures in this doc only apply to "ping" mode for now 🙈 "traceroute" mode is out of scope here, so we're not doing that one 💀
in [RFC4379], the echo reply is what reports the LSP checking result back to the LSP ping initiator 📬 this doc defines a new Reply Mode and a new TLV (the Reply Path TLV) so the LSP ping initiator can specify or constrain the return path of the echo reply 🦋 the echo reply is also extended so it can detect the requested return path by looking at a specified path FEC TLV ✨ this means LSP ping can catch failures in both directions with a single operation. literally cuts the operational steps needed to verify end-to-end bidirectional connectivity and integrity of an LSP in half 😭🫶
when the return path is an MPLS path, the echo reply MUST carry the FEC Stack information in a Reply Path TLV so it can test the return MPLS LSP path 💖 the destination IP address of the echo reply message MUST never be used in a forwarding decision 🙅♀️ to make sure that can't happen, the destination IP address of the echo reply sent along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6, the IP Time to Live (TTL) MUST be set to 1, and the TTL in the outermost label MUST be set to 255 🔒
when the return path is a pure IP forwarding path, the procedures in [RFC4379] apply unchanged (the destination IP address is copied from the source IP address) 🌈
5.1. Sending an Echo Request 💅
when you're sending an echo request, you follow the rules and procedures in Section 4.3 of [RFC4379] plus this stuff: the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV MUST be carried in the echo request message to match 🎀 the Reply Path TLV holds one or several reply path sub-TLV(s) that identify the return path(s) the egress LSR should use for its reply 🧚
for a bidirectional LSP, the ingress LSR and egress LSR already know how the forward and backward direction LSPs are related 🤝 so only the B bit SHOULD be set in the Reply Path TLV ✨ if the operator wants the echo reply to go somewhere other than the reverse direction of the bidirectional LSP, then the A bit SHOULD be set, or another FEC sub-TLV SHOULD be carried in the Reply Path TLV instead, and the B bit MUST be clear 💜
sometimes operators want to treat two unidirectional LSPs (one for each direction) as a pair, even if there's no binding relationship between them 👯 with the mechanism in this doc, they can run LSP ping once from one end and finish failure detection on both unidirectional LSPs 🔥 to make that happen, the echo request message MUST carry (in the Reply Path TLV) a FEC sub-TLV that belongs to the backward LSP 🙌
5.2. Receiving an Echo Request 🦋
"Ping" mode processing, as defined in Section 4.4 of [RFC4379], still applies here 💅 on top of that, when an echo request comes in and the egress LSR doesn't know the Reply Mode from this doc, it sends back an echo reply with the return code set to "Malformed echo request received" and the Subcode set to zero, following the rules of [RFC4379] 💀 if the egress LSR does know the Reply Mode, it SHOULD look at the Reply Path TLV and find and select the desired return path 🧚 if there's a matched path, an echo reply with a Reply Path TLV that identifies the return path SHOULD be sent back to the ingress LSR, and the Reply Path return code SHOULD be set to "The echo reply was sent successfully using the specified Reply Path" 🎀 if there's no such path, an echo reply with the Reply Path TLV SHOULD be sent back to the ingress LSR, and the Reply Path return code SHOULD be set to the relevant code (defined in Section 4.2) for what actually happened, so it reflects how the Reply Path TLV was processed and how the return path was picked 🌸
for example, if the specified LSP isn't found and the egress picks another LSP as the return path, the Reply Path return code SHOULD be set to "The specified reply path was not found, the echo reply was sent via another LSP" 😭 and if the egress picks an IP path instead, the Reply Path return code SHOULD be set to "The specified Reply Path was not found, the echo reply was sent via pure IP forwarding (non-MPLS) path" 🌊 if there's an unknown sub-TLV in the received Reply Path TLV, the Reply Path return code SHOULD be set to "One or more of the sub-TLVs in the Reply Path TLV were not understood" 🤔
if the A bit of the Reply Path TLV in a received echo request is set, the egress LSR SHOULD send the echo reply along a non-default return path 🛤️
if the B bit of the Reply Path TLV in a received echo request is set, the egress LSR SHOULD send the echo reply along the reverse direction of the bidirectional LSP 🔁
and lowkey, the FEC validate results of the forward path LSP SHOULD NOT affect the egress LSR continuing to test the return path LSP 🙅♀️✨
5.3. Sending an Echo Reply 🌸
as [RFC4379] says, the echo reply message is a UDP packet, and it MUST be sent only in response to an MPLS echo request 💌 the source IP address is a valid IP address of the replier, and the source UDP port is the well-know UDP port for LSP ping 🎀
when the return path is an MPLS LSP, the destination IP address of the echo reply is copied from the destination IP address of the echo request, and the destination UDP port is copied from the source UDP port of the echo request 🦋 the IP TTL MUST be set to 1, and the TTL in the outermost label MUST be set to 255 🔒
when the return path is a pure IP forwarding path, the same rules from [RFC4379] apply, so the destination IP address and UDP port get copied from the source IP address and source UDP port of the echo request 🌈
when sending the echo reply, a Reply Path TLV that identifies the return path MUST be carried 💖 the Reply Path return code SHOULD be set to the relevant code that reflects how the egress processed the Reply Path TLV in the echo request and which return path it chose 🧚 carrying the Reply Path TLV in the echo reply gives the ingress LSR enough info about the reverse direction of the tested path to check that the data plane matches the control plane 🫶 so one LSP ping can test both directions of a path, main character energy ✨ if the return path is a pure IP path, no sub-TLVs are carried in the Reply Path TLV 🙃
5.4. Receiving an Echo Reply 🫧
the rules and process in Section 4.6 of [RFC4379] apply here 💅 when an echo reply is received, the Reply Mode is "Reply via Specified Path", the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and the return path is an MPLS LSP, the ingress LSR MUST perform FEC validation based on the FEC Stack information of the return path carried in the Reply Path TLV 😤 it does this the same way an egress LSR does when it receives an echo request, and the FEC validation process (relevant to "ping" mode) in Section 4.4.1 of [RFC4379] applies here too 🔥
when an echo reply comes back with the return code set to "Malformed echo request received" and the Subcode set to zero, it's possible the egress LSR doesn't know the "Reply via Specified Path" Reply Mode 🙈 in that case the operator may choose to re-run LSP ping using one of the four Reply Modes defined in [RFC4379] 🔁
if the Reply Path return code in the Reply Path TLV is set to "The specified reply path was not found, ...", it means the egress LSR couldn't find a matching return path like you asked 😭 operators can choose another LSP as the return path or use other methods to dig into the path further 🕵️♀️✨
5.5. Non-IP Encapsulation for MPLS-TP LSPs 🧚
okay so in some MPLS-TP deployments, IP addressing might not be available, or some form of non-IP encapsulation might just be preferred 🌊 in those cases, the Non-IP encapsulation defined in [RFC6426] applies here 🎀 the LSP Ping Reply Mode in the echo request and echo reply is set to 5, and the return path of the echo reply is whatever the Reply Path TLV says 💜
6. Security Considerations 🔒
Okay, bestie, the security stuff 😭. Everything [RFC4379] said about security applies here too, so go read that one as well. 🛡️
Now the new part: these extensions could be used for "proxying" attacks 👀. Like, an echo request initiator could name a return path whose destination isn't the initiator itself. Normally this won't happen 🙅♀️, because in an MPLS domain the initiators and receivers are in the same domain. But to stop this extension from being used as a proxy for attacks, the return path LSP should have its destination at the same node the forward path comes from 💅. If the receiver can't figure out whether the return path LSP ends at the initiator, it may drop the echo request 💀. So when the initiator sends an echo request, it should pick a proper source address based on the specified return path LSP, so the receiver can make that call. Main character security energy 👑✨.
7. IANA Considerations 📋
7.1. TLVs 🎀
IANA gave the value 21 to the Reply Path TLV and the value 22 to the Reply TC TLV, both from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, in the "TLVs" subregistry 🌸.
Value Meaning Reference
----- ------- ---------
21 Reply Path TLV this document (Section 4.2)
22 Reply TC TLV this document (Section 4.4)Here's the tea ☕: the sub-TLV space and assignments for the Reply Path TLV match the Target FEC Stack TLV's. The sub-types for the Target FEC Stack TLV and the Reply Path TLV MUST be kept the same 🫶. Any new sub-type added to the Target FEC Stack TLV MUST apply to the Reply Path TLV as well 🔥. Non-negotiable, periodt 💅.
7.2. New Target FEC Stack Sub-TLVs 🦋
IANA picked up three new sub-TLV types from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, in the "Sub-TLVs for TLV Types 1, 16, and 21" subregistry ✨.
Sub-Type Sub-TLV Name Reference
------- ----------- ---------
26 IPv4 RSVP Tunnel this document (Section 4.3.1)
27 IPv6 RSVP Tunnel this document (Section 4.3.2)
28 Static Tunnel this document (Section 4.3.3)7.3. New Reply Mode 🧚
IANA allocated (5 - Reply via Specified Path) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, in the "Reply Modes" subregistry 💜.
Value Meaning Reference
----- ----- ----------
5 Reply via Specified Path this document (Section 4.1)7.4. Reply Path Return Code 🍓
IANA made a brand-new subregistry in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for Reply Path return codes 🌈.
This document (Section 4.2) defines these return codes:
Value Meaning
------ ----------------------
0x0000 No return code
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Reserved for Experimental UseRange 0x0006-0xfffb isn't allocated yet and is saved for future extensions 🔮, and it gets allocated via Standard Action. The 0xfffc-0xffff range is for Experimental Use 🧪.
8. Contributors 🫶
Shoutout to the people who also helped write this doc 📣:
Ehud Doron
Orckit-Corrigent
EMail: ehudd@orckit.com
Ronen Solomon
Orckit-Corrigent
EMail: RonenS@orckit.com
Ville Hallivuori
Tellabs
Sinimaentie 6 C
FI-02630 Espoo, Finland
EMail: ville.hallivuori@tellabs.com
Xinchun Guo
EMail: guoxinchun@huawei.com9. Acknowledgements 💖
The authors thanked Adrian Farrel, Peter Ashwood-Smith, Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos Pignataro, and Tom Petch for their reviews, suggestions, and comments. Iconic behaviour from all of them 👑.
10. References 📚
10.1. Normative References 🔗
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.10.2. Informative References 🧠
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.Authors' Addresses 🌟
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095
China
EMail: mach.chen@huawei.com
Wei Cao
Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095
China
EMail: wayne.caowei@huawei.com
So Ning
Tata Communications
EMail: ning.so@tatacommunications.com
Frederic Jounay
Orange CH
4 rue caudray 1020 Renens
Switzerland
EMail: frederic.jounay@orange.ch
Simon Delord
EMail: Simon.delord@team.telstra.com📦 where this page comes from
- ietf: rfc7110 2014-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms