RFC 7746

Label Switched Path (LSP) Self-Ping

📅 published January 2016, from ietf

Label Switched Path (LSP) Self-Ping ✨

okay bestie, let's get into it 🎀 this is RFC 7746, and it's a Standards Track document (so it's a real, official Internet protocol spec, not just a vibe 💅). It was written by R. Bonica (Juniper Networks), I. Minei (Google, Inc.), M. Conn, D. Pacella, and L. Tomotaki (all Verizon), and it's dated January 2016 🦋. It's published under ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's a fresh one, no drama 🌸.

Abstract

okay so the whole point of this doc is that some fancy RSVP-TE optimizations can make ingress Label Switching Routers (LSRs) get RESV messages before forwarding state is installed on every downstream node 😭. The RSVP-TE spec says the ingress LSR is allowed to start sending traffic down the LSP as soon as that RESV shows up, but if it does that too early, traffic can get lost. yikes 💀

so this doc introduces LSP Self-ping 🧚. When an ingress LSR gets a RESV message, it can run LSP Self-ping procedures to make sure forwarding state is actually installed on all the downstream nodes. it's giving safety check, no cap ✨.

LSP Self-ping is its own brand-new protocol, not an extension of LSP Ping. they have similar names but they're built for totally different jobs 🙈. each one listens on its own UDP port and does its own thing.

and the best part: LSP Self-ping is an extremely lightweight mechanism 🫶. it does not use up control-plane resources on transit or egress LSRs. that's major main character energy 👑.

Status of This Memo

this is an Internet Standards Track document 🔥. it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741. the current status, any errata, and how to give feedback live at http://www.rfc-editor.org/info/rfc7746 🌈.

Copyright Notice

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 publication date. please read those carefully, because they spell out your rights and restrictions 🎀. any Code Components pulled out of this doc 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 🍓.

here's the full layout, in order 🌸:

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  The LSP Self-ping Message . . . . . . . . . . . . . . . . . .   6
4.  LSP Self-Ping Procedures  . . . . . . . . . . . . . . . . . .   7
5.  Bidirectional LSP Procedures  . . . . . . . . . . . . . . . .   8
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Appendix A.  Rejected Approaches  . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

okay so ingress LSRs use RSVP-TE [RFC3209] to set up MPLS Label Switched Paths (LSPs) 🦋. here's how that dance goes:

the ingress LSR works out a path between itself and an egress LSR 🗺️. that path can be strictly or loosely routed. once it has the path, the ingress LSR builds an RSVP PATH message. the PATH message has an Explicit Route Object (ERO) that describes the path between the ingress and egress LSRs.

the ingress LSR sends the PATH message toward the egress LSR, following the ERO. every transit LSR that gets the PATH message runs admission control. if the transit LSR says yes and admits the LSP, it passes the PATH message downstream to the next node in the ERO 💅.

when the egress LSR gets the PATH message, it binds a label to the LSP. that label can be implicit null, explicit null, or non-null 💖. then the egress LSR installs forwarding state (if it needs to) and builds an RSVP RESV message. the RESV message has a Label Object with the label bound to the LSP ✨.

the egress LSR sends the RESV message upstream toward the ingress LSR 🌈. it goes through the same transit LSRs the PATH message went through, just in reverse order. each transit LSR binds a label to the LSP, updates its forwarding state, and updates the RESV message. so in the end, the Label Object in the RESV has the most recently bound label 🧚. finally, the transit LSR sends the RESV upstream along the reverse path of the LSP.

when the ingress LSR finally gets the RESV message, it installs forwarding state. once that's in place, it can forward traffic through the LSP 🎀.

now here's a spicy quote 🌶️. RFC 3209 says, "The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message." but RFC 3209 doesn't strictly require that behavior, so it's not a must 🙈.

some implementations speed things up by letting LSRs send RESV messages before installing forwarding state [RFC6383] ⚡. this is nice because LSRs can install forwarding state in parallel, which makes LSP signaling and setup way faster. BUT it creates a race condition 😭. when the ingress LSR gets a RESV, some downstream LSRs might not have installed forwarding state yet. if the ingress forwards traffic before forwarding state is on every downstream node, traffic can get lost. it's the classic "too early, bestie" moment 💀.

so this doc describes LSP Self-ping 💜. when the ingress LSR gets a RESV message, it can run LSP Self-ping procedures to verify that forwarding state is installed on all downstream nodes. by checking that downstream forwarding state is in place, the ingress LSR gets rid of this particular cause of traffic loss 🫶.

LSP Self-ping is a new protocol, not an extension of LSP Ping [RFC4379] 🍓. like the abstract said, the names are similar but each one is designed for its own purpose. each protocol listens on its own UDP port and runs its own procedures ✨.

and yes, I'm saying it again because it matters: LSP Self-ping is an extremely lightweight mechanism 🦋. it does not consume control-plane resources on transit or egress LSRs 👑.

1.1. 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] 📜. these are the official requirement words, so they're capitalized on purpose 🙌.

2. Applicability 🌸

okay so LSP Self-ping is applicable in the following scenario 🧚:

the ingress LSR signals a point-to-point LSP 🦋.
the ingress LSR receives a RESV message 💌.
the RESV message indicates that all downstream nodes have begun the process of forwarding state installation 🌈.
the RESV message does not guarantee that all downstream nodes have completed the process of forwarding state installation 😭.
the ingress LSR needs to confirm that all downstream nodes have completed the process for forwarding state installation 🎀.
the ingress LSR does not need to confirm the correctness of downstream forwarding state, because there is a very high likelihood that downstream forwarding state is correct ✨.
control-plane resources on the egress LSR may be scarce 💀.
the need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct 👑.

now, unlike LSP Ping and S-BFD [S-BFD], LSP Self-ping is not a general-purpose MPLS OAM mechanism 🙅‍♀️. it cannot reliably determine whether downstream forwarding state is correct 😬. for example, if a downstream LSR installs forwarding state that makes an LSP terminate at the wrong node, LSP Self-ping will not detect the error. another example: if a downstream LSR erroneously forwards a packet without an MPLS label, LSP Self-ping will not catch it 💔.

and LSP Self-ping fails when either of these is true 💀:

the LSP under test is signaled by the Label Distribution Protocol (LDP) Independent Mode [RFC5036].
Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on links that connect the ingress LSR to the egress LSR.

while LSP Ping and S-BFD are general-purpose OAM mechanisms, they're not applicable in the scenario above, because:

LSP Ping consumes control-plane resources on the egress LSR 😩.
an S-BFD implementation either consumes control-plane resources on the egress LSR, or it requires special support for S-BFD on the forwarding plane 🙃.

by contrast, LSP Self-ping requires nothing from the egress LSR beyond the ability to forward an IP datagram 🫶. that's the glow-up 💖.

LSP Self-ping's purpose is to determine whether forwarding state has been installed on all downstream LSRs ✨. its primary constraint is to minimize its impact on egress LSR performance 🌈. this matters a lot during network convergence events that affect a large number of LSPs 🔥.

so, LSP Self-ping is applicable in the scenario described above, where the LSP is signaled by RSVP, RPF is not enabled, and the need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct 💅🎀. that's the whole vibe, bestie 🦋.

3. The LSP Self-ping Message ✨

okay so the LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC768] packet that carries a session ID 🎀. If the RSVP messages used to set up the LSP under test went over IPv4 [RFC791], the UDP datagram MUST be wrapped in an IPv4 header. If they went over IPv6 [RFC2460], the UDP datagram MUST be wrapped in an IPv6 header. Either way, the vibe is the same 💅

In either case:

The IP Source Address MAY be configurable. By default, it MUST be the address of the egress LSR.
The IP Destination Address MUST be the address of the ingress LSR.
The IP Time to Live (TTL) / Hop Count MAY be configurable. By default, it MUST be 255.
The IP DSCP (Differentiated Services Code Point) MAY be configurable. By default, it MUST be CS6 (110000) [RFC4594].
The UDP Source Port MUST be selected from the dynamic range (49152-65535) [RFC6335].
The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS].

UDP packet contents have the following format 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Session-ID                             |
   |                        (64 bits)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           LSP Self-Ping Message

The Session-ID is a 64-bit field that links an LSP Self-ping message to its LSP Self-ping session. It's the main character of this whole thing, honestly 👑

4. LSP Self-Ping Procedures 🌸

So before an LSP carries real traffic, the ingress LSR is like "wait, is this thing actually ready?" 🙈 To find out, it spins up a short-lived LSP Self-ping session. All of the session state stays local on the ingress LSR. The session state includes:

Session-ID: A 64-bit number that identifies the LSP Self-ping session.
Retry Counter: The maximum number of times that the ingress LSR probes the LSP before ending the LSP Self-ping session. Its starting value comes from configuration.
Retry Timer: The number of milliseconds the LSR waits after probing the LSP. Its starting value also comes from configuration.
Status: A boolean that shows the completion status of the LSP Self-ping session. It starts out as FALSE.

Implementations MAY store the info above in any format that's convenient for them. Do what slays for your codebase 🧚

The ingress LSR keeps running the following procedure until Status equals TRUE or Retry Counter equals zero:

Format an LSP Self-ping message.
Set the Session-ID in the LSP Self-ping message to the Session-ID mentioned above.
Send the LSP Self-ping message through the LSP under test.
Set a timer to expire in Retry Timer milliseconds.
Wait until either an LSP Self-ping message associated with the session comes back or the timer expires. If an LSP Self-ping message associated with the session comes back, set Status to TRUE. Otherwise, decrement the Retry Counter. Optionally, increase the value of Retry Timer according to an appropriate back-off algorithm.

Okay, the plot twist 😭 The ingress LSR addresses an LSP Self-ping message to itself and then forwards it through the LSP under test. If forwarding state has been installed on all downstream LSRs, the egress LSR gets the message and realizes it's addressed to the ingress LSR. So it forwards the message right back to the ingress LSR, exactly the same way it would forward any other IP packet. It's giving boomerang, and I'm obsessed 🪃✨

The LSP Self-ping message can reach the egress LSR with or without an MPLS header, and that depends on whether the LSP under test uses penultimate hop-popping procedures. If the message shows up at the egress LSR with an MPLS header, the egress LSR removes that header.

If the egress LSR's most preferred route to the ingress LSR goes through an LSP, the egress LSR forwards the LSP Self-ping message through that LSP. But if the egress LSR's most preferred route to the ingress LSR does not go through an LSP, the egress LSR forwards the LSP Self-ping message without MPLS encapsulation. Iconic routing decisions only 💅

When an LSP Self-ping session ends, it hands its completion status back to whatever invoked it. For example, if RSVP-TE invokes LSP Self-ping as part of the LSP setup procedure, LSP Self-ping returns its completion status to RSVP-TE. Teamwork makes the dream work 🫶

5. Bidirectional LSP Procedures 🦋

A bidirectional LSP has two sides: an active side and a passive side. The active side calculates the ERO and signals the LSP in the forward direction. The passive side reverses the ERO and signals the LSP in the reverse direction. Two roles, one vibe 💜

When LSP Self-ping is applied to a bidirectional LSP:

The active side calculates the ERO, signals the LSP, and runs LSP Self-ping.
The Passive side reverses the ERO, signals the LSP, and runs another instance of LSP Self-ping.
Neither side forwards traffic through the LSP until local LSP Self-ping returns TRUE.

The two LSP Self-ping sessions mentioned above are independent of one another. They are not required to have the same Session-ID. Each endpoint can start forwarding traffic through the LSP as soon as its own local LSP Self-ping returns TRUE. Endpoints are not required to wait until both LSP Self-ping sessions have returned TRUE. No waiting for your bestie to be ready first, just vibes 🌈

6. IANA Considerations 🍓

IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by MPLS LSP Self-Ping. That's the port number locked in 🔒

7. Security Considerations 💀

This section is a whole serious moment, so I'm not gonna sugarcoat it 😭

LSP Self-ping messages are easily forged. Therefore, an attacker can send the ingress LSR a forged LSP Self-ping message, causing the ingress LSR to end the LSP Self-ping session prematurely. To help mitigate these threats, operators SHOULD filter LSP Self-ping packets at the edges of the MPLS signaling domain. Furthermore, implementations SHOULD NOT assign Session-IDs in a predictable manner. To avoid predictability, implementations can use a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) [NIST-CSPRNG]. Unpredictable IDs are the whole point, bestie 🔥

8. References 📚

8.1. Normative References

[RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
           DOI 10.17487/RFC0768, August 1980,
           <http://www.rfc-editor.org/info/rfc768>.

[RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
           DOI 10.17487/RFC0791, September 1981,
           <http://www.rfc-editor.org/info/rfc791>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
           December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <http://www.rfc-editor.org/info/rfc3209>.

[RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
           Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
           2004, <http://www.rfc-editor.org/info/rfc3704>.

[RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
           Label Switched (MPLS) Data Plane Failures", RFC 4379,
           DOI 10.17487/RFC4379, February 2006,
           <http://www.rfc-editor.org/info/rfc4379>.

[RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
           "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
           October 2007, <http://www.rfc-editor.org/info/rfc5036>.

[RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
           Cheshire, "Internet Assigned Numbers Authority (IANA)
           Procedures for the Management of the Service Name and
           Transport Protocol Port Number Registry", BCP 165,
           RFC 6335, DOI 10.17487/RFC6335, August 2011,
           <http://www.rfc-editor.org/info/rfc6335>.

8.2. Informative References

[IANA.PORTS]
           IANA, "Service Name and Transport Protocol Port Number
           Registry", <http://www.iana.org/assignments/
           service-names-port-numbers>.

[NIST-CSPRNG]
           NIST, "Recommendation for Random Number Generation Using
           Deterministic Random Bit Generators", NIST Special
           Publication 800-90A, January 2012.

[RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
           Guidelines for DiffServ Service Classes", RFC 4594,
           DOI 10.17487/RFC4594, August 2006,
           <http://www.rfc-editor.org/info/rfc4594>.

[RFC6383]  Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
           Start Sending Data on Label Switched Paths Established
           Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September
           2011, <http://www.rfc-editor.org/info/rfc6383>.

[S-BFD]    Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
           Networks, "Seamless Bidirectional Forwarding Detection
           (S-BFD)", Work in Progress, draft-ietf-bfd-seamless-
           base-05, June 2015.

Appendix A. Rejected Approaches 🙅‍♀️

Okay, tea time ☕ This is where the team looked at the options that didn't make the cut.

In a rejected approach, the ingress LSR uses LSP Ping to verify LSP readiness. This approach was rejected for the following reasons.

While an ingress LSR can control its control-plane overhead due to LSP Ping, an egress LSR has no such control. This is because each ingress LSR can, on its own, control the rate of the LSP Ping originated by that LSR, while an egress LSR must respond to all the LSP Pings originated by various ingresses. Furthermore, when an MPLS Echo Request reaches an egress LSR, it is sent to the control plane of the egress LSR. This makes the egress LSR processing overhead of LSP Ping well above the overhead of its data plane (MPLS/IP forwarding). These factors make LSP Ping problematic as a tool for detecting LSP readiness to carry traffic when dealing with a large number of LSPs. Too much drama for the control plane 😩

By contrast, LSP Self-ping does not consume any control-plane resources at the egress LSR, and it relies solely on the data plane of the egress LSR. That makes it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs. Data plane supremacy 👑

In another rejected approach, the ingress LSR does not verify LSP readiness. Instead, it sets a timer when it receives an RSVP RESV message and does not forward traffic through the LSP until the timer expires. This approach was rejected because it is impossible to determine the optimal setting for this timer. If the timer value is set too low, it does not prevent black-holing. If the timer value is set too high, it slows down the process of LSP signaling and setup. Lowkey a guessing game nobody wants 🎲

Moreover, the above-mentioned timer is configured on a per-router basis. However, its optimum value is determined by a network-wide behavior. Therefore, changes in the network could require changes to the value of the timer, making the optimal setting of this timer a moving target. Moving target = not it 🎯

Acknowledgements 🫶

Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Mirsky, and Nobo Akiya for their contributions to this document. You all are literally the best 💖

Contributors 🌸

Okay bestie, time to give credit where it's due 🫶 These two folks contributed significantly to this doc, so they get the spotlight ✨

Mark Wygant, Verizon, mark.wygant@verizon.com 💜
Ravi Torvi, Juniper Networks, rtorvi@juniper.net 🦋

Authors' Addresses 💅

Meet the authors, the people who actually wrote this thing, and how to reach each of them 💖

Ron Bonica
Juniper Networks

Email: rbonica@juniper.net


Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States

Email: inaminei@google.com


Michael Conn
Verizon

Email: meconn26@gmail.com


Dante Pacella
Verizon

Email: dante.j.pacella@verizon.com


Luis Tomotaki
Verizon

Email: luis.tomotaki@verizon.com

That's the whole RFC, babe! 🌈✨ Five authors, two contributors, and a whole lot of LSP self-ping energy 👑🎀

📦 where this page comes from

ietf: rfc7746 2016-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms