diff options
Diffstat (limited to 'doc/rfc/rfc7746.txt')
| -rw-r--r-- | doc/rfc/rfc7746.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7746.txt b/doc/rfc/rfc7746.txt new file mode 100644 index 0000000..c033d95 --- /dev/null +++ b/doc/rfc/rfc7746.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Bonica +Request for Comments: 7746 Juniper Networks +Category: Standards Track I. Minei +ISSN: 2070-1721 Google, Inc. + M. Conn + D. Pacella + L. Tomotaki + Verizon + January 2016 + + + Label Switched Path (LSP) Self-Ping + +Abstract + + When certain RSVP-TE optimizations are implemented, ingress Label + Switching Router (LSRs) can receive RSVP RESV messages before + forwarding state has been installed on all downstream nodes. + According to the RSVP-TE specification, the ingress LSR can forward + traffic through a Label Switched Path (LSP) as soon as it receives a + RESV message. However, if the ingress LSR forwards traffic through + the LSP before forwarding state has been installed on all downstream + nodes, traffic can be lost. + + This document describes LSP Self-ping. When an ingress LSR receives + an RESV message, it can invoke LSP Self-ping procedures to ensure + that forwarding state has been installed on all downstream nodes. + + LSP Self-ping is a new protocol. It is not an extension of LSP Ping. + Although LSP Ping and LSP Self-ping are named similarly, each is + designed for a unique purpose. Each protocol listens on its own UDP + port and executes its own procedures. + + LSP Self-ping is an extremely lightweight mechanism. It does not + consume control-plane resources on transit or egress LSRs. + + + + + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 1] + +RFC 7746 LSP Self-Ping January 2016 + + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7746. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. 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 + + + + + + +Bonica, et al. Standards Track [Page 2] + +RFC 7746 LSP Self-Ping January 2016 + + +1. Introduction + + Ingress Label Switching Routers (LSRs) use RSVP-TE [RFC3209] to + establish MPLS Label Switched Paths (LSPs). The following paragraphs + describe RSVP-TE procedures. + + The ingress LSR calculates a path between itself and an egress LSR. + The calculated path can be either strictly or loosely routed. Having + calculated a path, the ingress LSR constructs an RSVP PATH message. + The PATH message includes an Explicit Route Object (ERO) that + represents the path between the ingress and egress LSRs. + + The ingress LSR forwards the PATH message towards the egress LSR, + following the path defined by the ERO. Each transit LSR that + receives the PATH message executes admission control procedures. If + the transit LSR admits the LSP, it sends the PATH message downstream, + to the next node in the ERO. + + When the egress LSR receives the PATH message, it binds a label to + the LSP. The label can be implicit null, explicit null, or non-null. + The egress LSR then installs forwarding state (if necessary) and + constructs an RSVP RESV message. The RESV message contains a Label + Object that includes the label that has been bound to the LSP. + + The egress LSR sends the RESV message upstream towards the ingress + LSR. The RESV message visits the same transit LSRs that the PATH + message visited, in reverse order. Each transit LSR binds a label to + the LSP, updates its forwarding state, and updates the RESV message. + As a result, the Label Object in the RESV message contains the label + that has been bound to the LSP most recently. Finally, the transit + LSR sends the RESV message upstream, along the reverse path of the + LSP. + + When the ingress LSR receives the RESV message, it installs + forwarding state. Once the ingress LSR installs forwarding state, it + can forward traffic through the LSP. + + Referring to any LSR, RFC 3209 says, "The node SHOULD be prepared to + forward packets carrying the assigned label prior to sending the Resv + message." However, RFC 3209 does not strictly require this behavior. + + Some implementations optimize the above-described procedure by + allowing LSRs to send RESV messages before installing forwarding + state [RFC6383]. This optimization is desirable, because it allows + LSRs to install forwarding state in parallel, thus accelerating the + process of LSP signaling and setup. However, this optimization + creates a race condition. When the ingress LSR receives a RESV + message, some downstream LSRs may have not yet installed forwarding + + + +Bonica, et al. Standards Track [Page 3] + +RFC 7746 LSP Self-Ping January 2016 + + + state. If the ingress LSR forwards traffic through the LSP before + forwarding state has been installed on all downstream nodes, traffic + can be lost. + + This document describes LSP Self-ping. When an ingress LSR receives + an RESV message, it can invoke LSP Self-ping procedures to verify + that forwarding state has been installed on all downstream nodes. By + verifying the installation of downstream forwarding state, the + ingress LSR eliminates this particular cause of traffic loss. + + LSP Self-ping is a new protocol. It is not an extension of LSP Ping + [RFC4379]. Although LSP Ping and LSP Self-ping are named similarly, + each is designed for a unique purpose. Each protocol listens on its + own UDP port and executes its own procedures. + + 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]. + +2. Applicability + + LSP Self-ping is applicable in the following scenario: + + o The ingress LSR signals a point-to-point LSP. + + o The ingress LSR receives a RESV message. + + o The RESV message indicates that all downstream nodes have begun + the process of forwarding state installation. + + o The RESV message does not guarantee that all downstream nodes have + completed the process of forwarding state installation. + + o The ingress LSR needs to confirm that all downstream nodes have + completed the process for forwarding state installation. + + o 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. + + o Control-plane resources on the egress LSR may be scarce. + + + + + +Bonica, et al. Standards Track [Page 4] + +RFC 7746 LSP Self-Ping January 2016 + + + o The need to conserve control-plane resources on the egress LSR + outweighs the need to determine whether downstream forwarding + state is correct. + + 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 a forwarding state that causes an LSP to terminate at + the wrong node, LSP Self-ping will not detect an error. In another + example, if a downstream LSR erroneously forwards a packet without an + MPLS label, LSP Self-ping will not detect an error. + + Furthermore, LSP Self-ping fails when either of the following + conditions are true: + + o The LSP under test is signaled by the Label Distribution Protocol + (LDP) Independent Mode [RFC5036]. + + o 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 are + not applicable in the above-described scenario because: + + o LSP Ping consumes control-plane resources on the egress LSR. + + o An S-BFD implementation either consumes control-plane resources on + the egress LSR or 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. + + 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 functionality is + valuable during network convergence events that impact a large number + of LSPs. + + Therefore, 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. + + + + + + + + +Bonica, et al. Standards Track [Page 5] + +RFC 7746 LSP Self-Ping January 2016 + + +3. The LSP Self-ping Message + + The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC768] + packet that encapsulates a session ID. If the RSVP messages used to + establish the LSP under test were delivered over IPv4 [RFC791], the + UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP + messages used to establish the LSP were delivered over IPv6 + [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header. + + In either case: + + o The IP Source Address MAY be configurable. By default, it MUST be + the address of the egress LSR. + + o The IP Destination Address MUST be the address of the ingress LSR. + + o The IP Time to Live (TTL) / Hop Count MAY be configurable. By + default, it MUST be 255. + + o The IP DSCP (Differentiated Services Code Point) MAY be + configurable. By default, it MUST be CS6 (110000) [RFC4594]. + + o The UDP Source Port MUST be selected from the dynamic range + (49152-65535) [RFC6335]. + + o 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 associates an LSP Self-ping + message with an LSP Self-ping session. + + + + + + + + + + + +Bonica, et al. Standards Track [Page 6] + +RFC 7746 LSP Self-Ping January 2016 + + +4. LSP Self-Ping Procedures + + In order to verify that an LSP is ready to carry traffic, the ingress + LSR creates a short-lived LSP Self-ping session. All session state + is maintained locally on the ingress LSR. Session state includes the + following information: + + o Session-ID: A 64-bit number that identifies the LSP Self-ping + session. + + o Retry Counter: The maximum number of times that the ingress LSR + probes the LSP before terminating the LSP Self-ping session. The + initial value of this variable is determined by configuration. + + o Retry Timer: The number of milliseconds that the LSR waits after + probing the LSP. The initial value of this variable is determined + by configuration. + + o Status: A boolean variable indicating the completion status of the + LSP Self-ping session. The initial value of this variable is + FALSE. + + Implementations MAY represent the above-mentioned information in any + format that is convenient to them. + + The ingress LSR executes the following procedure until Status equals + TRUE or Retry Counter equals zero: + + o Format a LSP Self-ping message. + + o Set the Session-ID in the LSP Self-ping message to the Session-ID + mentioned above. + + o Send the LSP Self-ping message through the LSP under test. + + o Set a timer to expire in Retry Timer milliseconds. + + o Wait until either an LSP Self-ping message associated with the + session returns or the timer expires. If an LSP Self-ping message + associated with the session returns, set Status to TRUE. + Otherwise, decrement the Retry Counter. Optionally, increase the + value of Retry Timer according to an appropriate back-off + algorithm. + + In the process described above, the ingress LSR addresses an LSP + Self-ping message to itself and forwards that message through the LSP + under test. If forwarding state has been installed on all downstream + LSRs, the egress LSR receives the LSP Self-ping message and + + + +Bonica, et al. Standards Track [Page 7] + +RFC 7746 LSP Self-Ping January 2016 + + + determines that it is addressed to the ingress LSR. So, the egress + LSR forwards the LSP Self-ping message back to the ingress LSR, + exactly as it would forward any other IP packet. + + The LSP Self-ping message can arrive at the egress LSR with or + without an MPLS header, depending on whether the LSP under test + executes penultimate hop-popping procedures. If the LSP Self-ping + message arrives 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 is + through an LSP, the egress LSR forwards the LSP Self-ping message + through that LSP. However, if the egress LSR's most preferred route + to the ingress LSR is not through an LSP, the egress LSR forwards the + LSP Self-ping message without MPLS encapsulation. + + When an LSP Self-ping session terminates, it returns its completion + status to the invoking protocol. 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. + +5. Bidirectional LSP Procedures + + A bidirectional LSP has 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. + + When LSP Self-ping is applied to a bidirectional LSP: + + o The active side calculates the ERO, signals the LSP, and runs LSP + Self-ping. + + o The Passive side reverses the ERO, signals the LSP, and runs + another instance of LSP Self-ping. + + o 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 forward traffic through the LSP as soon as its local LSP + Self-ping returns TRUE. Endpoints are not required to wait until + both LSP Self-ping sessions have returned TRUE. + + + + + + + +Bonica, et al. Standards Track [Page 8] + +RFC 7746 LSP Self-Ping January 2016 + + +6. IANA Considerations + + IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by MPLS + LSP Self-Ping. + +7. Security Considerations + + 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 terminate the LSP Self-ping session prematurely. In + order to 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. In order to avoid predictability, implementations can + leverage a Cryptographically Secure Pseudorandom Number Generator + (CSPRNG) [NIST-CSPRNG]. + +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>. + + + + + +Bonica, et al. Standards Track [Page 9] + +RFC 7746 LSP Self-Ping January 2016 + + + [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. + + + + + + + + + +Bonica, et al. Standards Track [Page 10] + +RFC 7746 LSP Self-Ping January 2016 + + +Appendix A. Rejected Approaches + + 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 the 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 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. + + 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, making it more suitable as a tool for checking LSP + readiness when dealing with a large number of LSPs. + + 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. + + 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. + +Acknowledgements + + Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg + Mirsky, and Nobo Akiya for their contributions to this document. + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 11] + +RFC 7746 LSP Self-Ping January 2016 + + +Contributors + + The following individuals contributed significantly to this document: + + Mark Wygant + Verizon + mark.wygant@verizon.com + + Ravi Torvi + Juniper Networks + rtorvi@juniper.net + +Authors' Addresses + + 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 + + + + + + +Bonica, et al. Standards Track [Page 12] + |