draft-ietf-mpls-self-ping-04.txt   draft-ietf-mpls-self-ping-05.txt 
MPLS Working Group R. Bonica MPLS Working Group R. Bonica
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: March 11, 2016 Google, Inc. Expires: April 4, 2016 Google, Inc.
M. Conn M. Conn
D. Pacella D. Pacella
L. Tomotaki L. Tomotaki
Verizon Verizon
September 8, 2015 October 2, 2015
LSP Self-Ping LSP Self-Ping
draft-ietf-mpls-self-ping-04 draft-ietf-mpls-self-ping-05
Abstract Abstract
When certain RSVP-TE optimizations are implemented, ingress LSRs can When certain RSVP-TE optimizations are implemented, ingress LSRs can
receive RSVP RESV messages before forwarding state has been installed receive RSVP RESV messages before forwarding state has been installed
on all downstream nodes. According to the RSVP-TE specification, the on all downstream nodes. According to the RSVP-TE specification, the
ingress LSR can forward traffic through an LSP as soon as it receives ingress LSR can forward traffic through an LSP as soon as it receives
a RESV message. However, if the ingress LSR forwards traffic through a RESV message. However, if the ingress LSR forwards traffic through
the LSP before forwarding state has been installed on all downstream the LSP before forwarding state has been installed on all downstream
nodes, traffic can be lost. nodes, traffic can be lost.
This memo describes LSP Self-ping. When an ingress LSR receives an This document describes LSP Self-ping. When an ingress LSR receives
RESV message, it can invoke LSP Self-ping procedures to ensure that an RESV message, it can invoke LSP Self-ping procedures to ensure
forwarding state has been installed on all downstream nodes. 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 light-weight mechanism. It does not LSP Self-ping is an extremely light-weight mechanism. It does not
consume control plane resources on transit or egress LSRs. consume control plane resources on transit or egress LSRs.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 2, line 10 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2016. This Internet-Draft will expire on April 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5 3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5
4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6 4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 7 5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8
6. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to
establish MPLS Label Switched Paths. The following paragraphs establish MPLS Label Switched Paths. The following paragraphs
describe RSVP-TE procedures. describe RSVP-TE procedures.
The ingress LSR calculates a path between itself and an egress LSR. The ingress LSR calculates a path between itself and an egress LSR.
The calculated path can be either strictly or loosely routed. Having The calculated path can be either strictly or loosely routed. Having
skipping to change at page 3, line 33 skipping to change at page 3, line 42
the LSP, updates its forwarding state and updates the RESV message. the LSP, updates its forwarding state and updates the RESV message.
As a result, the Label Object in the RESV message contains the label 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 that has been bound to the LSP most recently. Finally, the transit
LSR sends the RESV message upstream, along the reverse path of the LSR sends the RESV message upstream, along the reverse path of the
LSP. LSP.
When the ingress LSR receives the RESV message, it installs When the ingress LSR receives the RESV message, it installs
forwarding state. Once the ingress LSR installs forwarding state it forwarding state. Once the ingress LSR installs forwarding state it
can forward traffic through the LSP. 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 Some implementations optimize the above-described procedure by
allowing LSRs to send RESV messages before installing forwarding allowing LSRs to send RESV messages before installing forwarding
state [RFC6383]. This optimization is desirable, because it allows state [RFC6383]. This optimization is desirable, because it allows
LSRs to install forwarding state in parallel, thus accelerating the LSRs to install forwarding state in parallel, thus accelerating the
process of LSP signaling and setup. However, this optimization process of LSP signaling and setup. However, this optimization
creates a race condition. When the ingress LSR receives a RESV creates a race condition. When the ingress LSR receives a RESV
message, some downstream LSRs may have not yet installed forwarding message, some downstream LSRs may have not yet installed forwarding
state. If the ingress LSR forwards traffic through the LSP before state. If the ingress LSR forwards traffic through the LSP before
forwarding state has been installed on all downstream nodes, traffic forwarding state has been installed on all downstream nodes, traffic
can be lost. can be lost.
This memo describes LSP Self-ping. When an ingress LSR receives an This document describes LSP Self-ping. When an ingress LSR receives
RESV message, it can invoke LSP Self-ping procedures to verify that an RESV message, it can invoke LSP Self-ping procedures to verify
forwarding state has been installed on all downstream nodes. By that forwarding state has been installed on all downstream nodes. By
verifying the installation of downstream forwarding state, the verifying the installation of downstream forwarding state, the
ingress LSR eliminates this particular cause of traffic loss. 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 light-weight mechanism. It does not LSP Self-ping is an extremely light-weight mechanism. It does not
consume control plane resources on transit or egress LSRs. consume control plane resources on transit or egress LSRs.
Although LSP Ping and LSP Self-ping are named similarly, each is a
unique protocol, designed for a unique purpose. Each protocol
listens on its own UDP port and executes its own unique procedures.
2. Applicability 2. Applicability
LSP Self-ping is applicable in the following scenario: LSP Self-ping is applicable in the following scenario:
o The ingress LSR signals a point-to-point LSP o The ingress LSR signals a point-to-point LSP
o The ingress LSR receives a RESV message o The ingress LSR receives a RESV message
o The RESV message indicates that all downstream nodes have begun o The RESV message indicates that all downstream nodes have begun
the process of forwarding state installation the process of forwarding state installation
skipping to change at page 4, line 36 skipping to change at page 4, line 49
o The ingress LSR does not need to confirm the correctness of o The ingress LSR does not need to confirm the correctness of
downstream forwarding state, because there is a very high downstream forwarding state, because there is a very high
likelihood that downstream forwarding state is correct likelihood that downstream forwarding state is correct
o Control plane resources on the egress LSR may be scarce o Control plane resources on the egress LSR may be scarce
o The need to conserve control plane resources on the egress LSR o The need to conserve control plane resources on the egress LSR
outweighs the need to determine whether downstream forwarding outweighs the need to determine whether downstream forwarding
state is correct state is correct
Unlike LSP Ping [RFC4379] and S-BFD [I-D.akiya-bfd-seamless-base], Unlike LSP Ping and S-BFD [I-D.akiya-bfd-seamless-base], LSP Self-
LSP Self-ping is not a general purpose MPLS OAM mechanism. It cannot ping is not a general purpose MPLS OAM mechanism. It cannot reliably
reliably determine whether downstream forwarding state is correct. determine whether downstream forwarding state is correct. For
For example, if a downstream LSR installs a forwarding state that example, if a downstream LSR installs a forwarding state that causes
causes an LSP to terminate at the wrong node, LSP Self-ping will not an LSP to terminate at the wrong node, LSP Self-ping will not detect
detect an error. In another example, if a downstream LSR erroneously an error. In another example, if a downstream LSR erroneously
forwards a packet without an MPLS label, LSP Self-ping will not forwards a packet without an MPLS label, LSP Self-ping will not
detect an error. detect an error.
Furthermore, LSP Self-ping fails when either of the following Furthermore, LSP Self-ping fails when either of the following
conditions are true: conditions are true:
o The LSP under test is signaled by the Label Distribution Protocol o The LSP under test is signaled by the Label Distribution Protocol
(LDP) Independent Mode [RFC5036] (LDP) Independent Mode [RFC5036]
o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on
skipping to change at page 8, line 19 skipping to change at page 8, line 30
o Neither side forwards traffic through the LSP until local LSP o Neither side forwards traffic through the LSP until local LSP
Self-ping returns TRUE Self-ping returns TRUE
The two LSP Self-ping sessions, mentioned above, are independent of The two LSP Self-ping sessions, mentioned above, are independent of
one another. They are not required to have the same Session-ID. one another. They are not required to have the same Session-ID.
Each endpoint can forward traffic through the LSP as soon as the its Each endpoint can forward traffic through the LSP as soon as the its
local LSP Self-ping returns TRUE. Endpoints are not required to wait local LSP Self-ping returns TRUE. Endpoints are not required to wait
until both LSP Self-ping sessions have returned TRUE. until both LSP Self-ping sessions have returned TRUE.
6. Rejected Approaches 6. IANA Considerations
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, which 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 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 signalling 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.
7. IANA Considerations
IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by LSP IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by LSP
Self-ping. Self-ping.
8. Security Considerations 7. Security Considerations
LSP Self-ping messages are easily forged. Therefore, an attacker can LSP Self-ping messages are easily forged. Therefore, an attacker can
send the ingress LSR a forged LSP Self-ping message, causing the send the ingress LSR a forged LSP Self-ping message, causing the
ingress LSR to terminate the LSP Self-ping session prematurely. In ingress LSR to terminate the LSP Self-ping session prematurely. In
order to mitigate these threats, implementations SHOULD NOT assign order to mitigate these threats, implementations SHOULD NOT assign
Session-ID's in a predictable manner. Furthermore, operators SHOULD Session-ID's in a predictable manner. Furthermore, operators SHOULD
filter LSP Self-ping packets at network ingress points. filter LSP Self-ping packets at network ingress points.
9. Contributors 8. Contributors
The following individuals contributed significantly to this document: The following individuals contributed significantly to this document:
Mark Wygant Mark Wygant
Verizon Verizon
mark.wygant@verizon.com mark.wygant@verizon.com
Ravi Torvi Ravi Torvi
Juniper Networks Juniper Networks
rtorvi@juniper.net rtorvi@juniper.net
10. Acknowledgements 9. Acknowledgements
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg
Mirsky and Nobo Akiya for their contributions to this document. Mirsky and Nobo Akiya for their contributions to this document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 10, line 39 skipping to change at page 10, line 21
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
11.2. Informative References 10.2. Informative References
[I-D.akiya-bfd-seamless-base] [I-D.akiya-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-akiya-bfd-seamless-base-03 (work in (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in
progress), April 2014. progress), April 2014.
[IANA.PORTS] [IANA.PORTS]
IANA, "Service Name and Transport Protocol Port Number IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/ Registry", <http://www.iana.org/assignments/
skipping to change at page 11, line 15 skipping to change at page 10, line 45
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September
2011, <http://www.rfc-editor.org/info/rfc6383>. 2011, <http://www.rfc-editor.org/info/rfc6383>.
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, which 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 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 signalling 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.
Authors' Addresses Authors' Addresses
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Email: rbonica@juniper.net Email: rbonica@juniper.net
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
 End of changes. 21 change blocks. 
73 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/