draft-ietf-mpls-self-ping-06.txt   rfc7746.txt 
MPLS Working Group R. Bonica Internet Engineering Task Force (IETF) R. Bonica
Internet-Draft Juniper Networks Request for Comments: 7746 Juniper Networks
Intended status: Standards Track I. Minei Category: Standards Track I. Minei
Expires: May 4, 2016 Google, Inc. ISSN: 2070-1721 Google, Inc.
M. Conn M. Conn
D. Pacella D. Pacella
L. Tomotaki L. Tomotaki
Verizon Verizon
November 1, 2015 January 2016
LSP Self-Ping Label Switched Path (LSP) Self-Ping
draft-ietf-mpls-self-ping-06
Abstract Abstract
When certain RSVP-TE optimizations are implemented, ingress LSRs can When certain RSVP-TE optimizations are implemented, ingress Label
receive RSVP RESV messages before forwarding state has been installed Switching Router (LSRs) can receive RSVP RESV messages before
on all downstream nodes. According to the RSVP-TE specification, the forwarding state has been installed on all downstream nodes.
ingress LSR can forward traffic through an LSP as soon as it receives According to the RSVP-TE specification, the ingress LSR can forward
a RESV message. However, if the ingress LSR forwards traffic through 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 the LSP before forwarding state has been installed on all downstream
nodes, traffic can be lost. nodes, traffic can be lost.
This document describes LSP Self-ping. When an ingress LSR receives This document describes LSP Self-ping. When an ingress LSR receives
an RESV message, it can invoke LSP Self-ping procedures to ensure an RESV message, it can invoke LSP Self-ping procedures to ensure
that 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. 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 Although LSP Ping and LSP Self-ping are named similarly, each is
designed for a unique purpose. Each protocol listens on its own UDP designed for a unique purpose. Each protocol listens on its own UDP
port and executes its own procedures. port and executes its own procedures.
LSP Self-ping is an extremely light-weight mechanism. It does not LSP Self-ping is an extremely lightweight mechanism. It does not
consume control plane resources on transit or egress LSRs. consume control-plane resources on transit or egress LSRs.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2016. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5 3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 6
4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6 4. LSP Self-Ping Procedures . . . . . . . . . . . . . . . . . . 7
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8 5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11 Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to Ingress Label Switching Routers (LSRs) use RSVP-TE [RFC3209] to
establish MPLS Label Switched Paths. The following paragraphs establish MPLS Label Switched Paths (LSPs). 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
calculated a path, the ingress LSR constructs an RSVP PATH message. calculated a path, the ingress LSR constructs an RSVP PATH message.
The PATH message includes an Explicit Route Object (ERO) that The PATH message includes an Explicit Route Object (ERO) that
represents the path between the ingress and egress LSRs. represents the path between the ingress and egress LSRs.
The ingress LSR forwards the PATH message towards the egress LSR, The ingress LSR forwards the PATH message towards the egress LSR,
following the path defined by the ERO. Each transit LSR that following the path defined by the ERO. Each transit LSR that
receives the PATH message executes admission control procedures. If receives the PATH message executes admission control procedures. If
the transit LSR admits the LSP, it sends the PATH message downstream, the transit LSR admits the LSP, it sends the PATH message downstream,
to the next node in the ERO. to the next node in the ERO.
When the egress LSR receives the PATH message, it binds a label to 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 LSP. The label can be implicit null, explicit null, or non-null.
The egress LSR then installs forwarding state (if necessary), and The egress LSR then installs forwarding state (if necessary) and
constructs an RSVP RESV message. The RESV message contains a Label constructs an RSVP RESV message. The RESV message contains a Label
Object that includes the label that has been bound to the LSP. Object that includes the label that has been bound to the LSP.
The egress LSR sends the RESV message upstream towards the ingress The egress LSR sends the RESV message upstream towards the ingress
LSR. The RESV message visits the same transit LSRs that the PATH LSR. The RESV message visits the same transit LSRs that the PATH
message visited, in reverse order. Each transit LSR binds a label to message visited, in reverse order. Each transit LSR binds a label to
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 Referring to any LSR, RFC 3209 says, "The node SHOULD be prepared to
forward packets carrying the assigned label prior to sending the RESV forward packets carrying the assigned label prior to sending the Resv
message". However, RFC 3209 does not strictly require this behavior. 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
an RESV message, it can invoke LSP Self-ping procedures to verify an RESV message, it can invoke LSP Self-ping procedures to verify
that 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 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, [RFC4379]. Although LSP Ping and LSP Self-ping are named similarly,
each is designed for a unique purpose. Each protocol listens on its each is designed for a unique purpose. Each protocol listens on its
own UDP port and executes its own procedures. 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 lightweight mechanism. It does not
consume control plane resources on transit or egress LSRs. 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 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.
o The RESV message does not guarantee that all downstream nodes have o The RESV message does not guarantee that all downstream nodes have
completed the process of forwarding state installation completed the process of forwarding state installation.
o The ingress LSR needs to confirm that all downstream nodes have o The ingress LSR needs to confirm that all downstream nodes have
completed the process for forwarding state installation completed the process for forwarding state installation.
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 and S-BFD [I-D.akiya-bfd-seamless-base], LSP Self- Unlike LSP Ping and S-BFD [S-BFD], LSP Self-ping is not a general-
ping is not a general purpose MPLS OAM mechanism. It cannot reliably purpose MPLS OAM mechanism. It cannot reliably determine whether
determine whether downstream forwarding state is correct. For downstream forwarding state is correct. For example, if a downstream
example, if a downstream LSR installs a forwarding state that causes LSR installs a forwarding state that causes an LSP to terminate at
an LSP to terminate at the wrong node, LSP Self-ping will not detect the wrong node, LSP Self-ping will not detect an error. In another
an error. In another example, if a downstream LSR erroneously example, if a downstream LSR erroneously forwards a packet without an
forwards a packet without an MPLS label, LSP Self-ping will not 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
links that connect the ingress LSR to the egress LSR links that connect the ingress LSR to the egress LSR.
While LSP Ping and S-BFD are general purpose OAM mechanisms, they are While LSP Ping and S-BFD are general-purpose OAM mechanisms, they are
not applicable in the above described scenario because: not applicable in the above-described scenario because:
o LSP Ping consumes control plane resources on the egress LSR o LSP Ping consumes control-plane resources on the egress LSR.
o An S-BFD implementation either consumes control plane resources on o An S-BFD implementation either consumes control-plane resources on
the egress LSR or requires special support for S-BFD on the the egress LSR or requires special support for S-BFD on the
forwarding plane. forwarding plane.
By contrast, LSP Self-ping requires nothing from the egress LSR By contrast, LSP Self-ping requires nothing from the egress LSR
beyond the ability to forward an IP datagram. beyond the ability to forward an IP datagram.
LSP Self-ping's purpose is to determine whether forwarding state has LSP Self-ping's purpose is to determine whether forwarding state has
been installed on all downstream LSRs. Its primary constraint is to been installed on all downstream LSRs. Its primary constraint is to
minimize its impact on egress LSR performance. This functionality is minimize its impact on egress LSR performance. This functionality is
valuable during network convergence events that impact a large number valuable during network convergence events that impact a large number
of LSPs. of LSPs.
Therefore, LSP Self-ping is applicable in the scenario described Therefore, LSP Self-ping is applicable in the scenario described
above, where the LSP is signaled by RSVP, RPF is not enabled, and the 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 need to conserve control-plane resources on the egress LSR outweighs
the need to determine whether downstream forwarding state is correct. the need to determine whether downstream forwarding state is correct.
3. The LSP Self-ping Message 3. The LSP Self-ping Message
The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768] The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC768]
packet that encapsulates a session ID. If the RSVP messages used to packet that encapsulates a session ID. If the RSVP messages used to
establish the LSP under test were delivered over IPv4 [RFC0791], the establish the LSP under test were delivered over IPv4 [RFC791], the
UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP
messages used to establish the LSP were delivered over IPv6 messages used to establish the LSP were delivered over IPv6
[RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header. [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header.
In either case: In either case:
o The IP Source Address MAY be configurable. By default, it MUST be o The IP Source Address MAY be configurable. By default, it MUST be
the address of the egress LSR the address of the egress LSR.
o The IP Destination Address MUST be the address of the ingress 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 o The IP Time to Live (TTL) / Hop Count MAY be configurable. By
default, it MUST be 255 default, it MUST be 255.
o The IP DSCP MAY be configurable. By default, it MUST be CS6 o The IP DSCP (Differentiated Services Code Point) MAY be
(Ox48) [RFC4594] configurable. By default, it MUST be CS6 (110000) [RFC4594].
o The UDP Source Port MUST be selected from the dynamic range o The UDP Source Port MUST be selected from the dynamic range
(49152-65535) [RFC6335] (49152-65535) [RFC6335].
o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS] o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS]
UDP packet contents have the following format: UDP packet contents have the following format:
0 1 2 3 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 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 | | Session-ID |
| (64 bits) | | (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Self-ping Message LSP Self-Ping Message
The Session-ID is a 64-bit field that associates an LSP Self-ping The Session-ID is a 64-bit field that associates an LSP Self-ping
message with an LSP Self-ping session. message with an LSP Self-ping session.
4. LSP Self Ping Procedures 4. LSP Self-Ping Procedures
In order to verify that an LSP is ready to carry traffic, the ingress 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 LSR creates a short-lived LSP Self-ping session. All session state
is maintained locally on the ingress LSR. Session state includes the is maintained locally on the ingress LSR. Session state includes the
following information: following information:
o Session-ID: A 64-bit number that identifies the LSP Self-ping o Session-ID: A 64-bit number that identifies the LSP Self-ping
session session.
o Retry Counter: The maximum number of times that the ingress LSR o Retry Counter: The maximum number of times that the ingress LSR
probes the LSP before terminating the LSP Self-ping session. The probes the LSP before terminating the LSP Self-ping session. The
initial value of this variable is determined by configuration. initial value of this variable is determined by configuration.
o Retry Timer: The number of milliseconds that the LSR waits after o Retry Timer: The number of milliseconds that the LSR waits after
probing the LSP. The initial value of this variable is determined probing the LSP. The initial value of this variable is determined
by configuration. by configuration.
o Status: A boolean variable indicating the completion status of the o Status: A boolean variable indicating the completion status of the
LSP Self-ping session. The initial value of this variable is LSP Self-ping session. The initial value of this variable is
FALSE. FALSE.
Implementations MAY represent the above mentioned information in any Implementations MAY represent the above-mentioned information in any
format that is convenient to them. format that is convenient to them.
The ingress LSR executes the following procedure until Status equals The ingress LSR executes the following procedure until Status equals
TRUE or Retry Counter equals zero: TRUE or Retry Counter equals zero:
o Format a LSP Self-ping message. o Format a LSP Self-ping message.
o Set the Session-ID in the LSP Self-ping message to the Session-ID o Set the Session-ID in the LSP Self-ping message to the Session-ID
mentioned above mentioned above.
o Send the LSP Self-ping message through the LSP under test o Send the LSP Self-ping message through the LSP under test.
o Set a timer to expire in Retry Timer milliseconds o Set a timer to expire in Retry Timer milliseconds.
o Wait until either an LSP Self-ping message associated with the o Wait until either an LSP Self-ping message associated with the
session returns or the timer expires. If an LSP Self-ping message session returns or the timer expires. If an LSP Self-ping message
associated with the session returns, set Status to TRUE. associated with the session returns, set Status to TRUE.
Otherwise, decrement the Retry Counter. Optionally, increase the Otherwise, decrement the Retry Counter. Optionally, increase the
value of Retry Timer according to an appropriate back off value of Retry Timer according to an appropriate back-off
algorithm. algorithm.
In the process described above, the ingress LSR addresses an LSP In the process described above, the ingress LSR addresses an LSP
Self-ping message to itself and forwards that message through the LSP Self-ping message to itself and forwards that message through the LSP
under test. If forwarding state has been installed on all downstream under test. If forwarding state has been installed on all downstream
LSRs, the egress LSR receives the LSP Self-ping message and LSRs, the egress LSR receives the LSP Self-ping message and
determines that it is addressed to the ingress LSR. So, the egress determines that it is addressed to the ingress LSR. So, the egress
LSR forwards LSP Self-ping message back to the ingress LSR, exactly LSR forwards the LSP Self-ping message back to the ingress LSR,
as it would forward any other IP packet. exactly as it would forward any other IP packet.
The LSP Self-ping message can arrive at the egress LSR with or The LSP Self-ping message can arrive at the egress LSR with or
without an MPLS header, depending on whether the LSP under test without an MPLS header, depending on whether the LSP under test
executes penultimate hop-popping procedures. If the LSP Self-ping executes penultimate hop-popping procedures. If the LSP Self-ping
message arrives at the egress LSR with an MPLS header, the egress LSR message arrives at the egress LSR with an MPLS header, the egress LSR
removes that header. removes that header.
If the egress LSR's most preferred route to the ingress LSR is 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 an LSP, the egress LSR forwards the LSP Self-ping message
through that LSP. However, if the egress LSR's most preferred route 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 to the ingress LSR is not through an LSP, the egress LSR forwards the
LSP Self-ping message without MPLS encapsulation. LSP Self-ping message without MPLS encapsulation.
When an LSP Self-ping session terminates, it returns its completion When an LSP Self-ping session terminates, it returns its completion
status to the invoking protocol. For example, if RSVP-TE invokes LSP status to the invoking protocol. For example, if RSVP-TE invokes LSP
Self-ping as part of the LSP set-up procedure, LSP Self-ping returns Self-ping as part of the LSP setup procedure, LSP Self-ping returns
its completion status to RSVP-TE. its completion status to RSVP-TE.
5. Bidirectional LSP Procedures 5. Bidirectional LSP Procedures
A bidirectional LSP has an active side and a passive side. The A bidirectional LSP has an active side and a passive side. The
active side calculates the ERO and signals the LSP in the forward active side calculates the ERO and signals the LSP in the forward
direction. The passive side reverses the ERO and signals the LSP in direction. The passive side reverses the ERO and signals the LSP in
the reverse direction. the reverse direction.
When LSP Self-ping is applied to a bidirectional LSP: When LSP Self-ping is applied to a bidirectional LSP:
o The active side calculates ERO, signals LSP and runs LSP Self-ping o The active side calculates the ERO, signals the LSP, and runs LSP
Self-ping.
o The Passive side reverses ERO, signals LSP and runs another o The Passive side reverses the ERO, signals the LSP, and runs
instance of LSP Self-ping another instance of LSP Self-ping.
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
one another. They are not required to have the same Session-ID. another. They are not required to have the same Session-ID. Each
Each endpoint can forward traffic through the LSP as soon as the its endpoint can forward traffic through the LSP as soon as its local LSP
local LSP Self-ping returns TRUE. Endpoints are not required to wait Self-ping returns TRUE. Endpoints are not required to wait until
until both LSP Self-ping sessions have returned TRUE. both LSP Self-ping sessions have returned TRUE.
6. IANA Considerations 6. 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 MPLS
Self-ping. LSP Self-Ping.
7. 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, operators SHOULD filter LSP Self- order to mitigate these threats, operators SHOULD filter LSP Self-
ping packets at the edges of the MPLS signaling domain. Furthermore, ping packets at the edges of the MPLS signaling domain. Furthermore,
implementations SHOULD NOT assign Session-ID's in a predictable implementations SHOULD NOT assign Session-IDs in a predictable
manner. In order to avoid predictablity, imlementations can leverage manner. In order to avoid predictability, implementations can
a Cryptographically Secure Pseudo-randomn Number Generator (CSPRNG) leverage a Cryptographically Secure Pseudorandom Number Generator
[NIST-CSPRNG] (CSPRNG) [NIST-CSPRNG].
8. Contributors
The following individuals contributed significantly to this document:
Mark Wygant
Verizon
mark.wygant@verizon.com
Ravi Torvi
Juniper Networks
rtorvi@juniper.net
9. Acknowledgements
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg
Mirsky and Nobo Akiya for their contributions to this document.
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] 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, [RFC791] 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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
skipping to change at page 10, line 21 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>.
10.2. Informative References 8.2. Informative References
[I-D.akiya-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-akiya-bfd-seamless-base-03 (work in
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/
service-names-port-numbers/ service-names-port-numbers>.
service-names-port-numbers.txt>.
[NIST-CSPRNG] [NIST-CSPRNG]
"NIST Special Publication 800-90A, Recommendation for NIST, "Recommendation for Random Number Generation Using
Random Number Generation Using Deterministic Random Bit Deterministic Random Bit Generators", NIST Special
Generators", January 2012. Publication 800-90A, January 2012.
[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>.
[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 Appendix A. Rejected Approaches
In a rejected approach, the ingress LSR uses LSP-Ping to verify LSP In a rejected approach, the ingress LSR uses LSP Ping to verify LSP
readiness. This approach was rejected for the following reasons. readiness. This approach was rejected for the following reasons.
While an ingress LSR can control its control plane overhead due to 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 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 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 originated by the LSR, while an egress LSR must respond to all the
LSP Pings originated by various ingresses. Furthermore, when an MPLS LSP Pings originated by various ingresses. Furthermore, when an MPLS
Echo Request reaches an egress LSR it is sent to the control plane of Echo Request reaches an egress LSR, it is sent to the control plane
the egress LSR, which makes egress LSR processing overhead of LSP of the egress LSR; this makes egress LSR processing overhead of LSP
Ping well above the overhead of its data plane (MPLS/IP forwarding). Ping well above the overhead of its data plane (MPLS/IP forwarding).
These factors make LSP Ping problematic as a tool for detecting LSP These factors make LSP Ping problematic as a tool for detecting LSP
readiness to carry traffic when dealing with a large number of LSPs. readiness to carry traffic when dealing with a large number of LSPs.
By contrast, LSP Self-ping does not consume any control plane By contrast, LSP Self-ping does not consume any control-plane
resources at the egress LSR, and relies solely on the data plane of resources at the egress LSR, and it relies solely on the data plane
the egress LSR, making it more suitable as a tool for checking LSP of the egress LSR, making it more suitable as a tool for checking LSP
readiness when dealing with a large number of LSPs. readiness when dealing with a large number of LSPs.
In another rejected approach, the ingress LSR does not verify LSP In another rejected approach, the ingress LSR does not verify LSP
readiness. Instead, it sets a timer when it receives an RSVP RESV readiness. Instead, it sets a timer when it receives an RSVP RESV
message and does not forward traffic through the LSP until the timer message and does not forward traffic through the LSP until the timer
expires. This approach was rejected because it is impossible to expires. This approach was rejected because it is impossible to
determine the optimal setting for this timer. If the timer value is 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 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. set too high, it slows down the process of LSP signaling and setup.
Moreover, the above-mentioned timer is configured on a per-router Moreover, the above-mentioned timer is configured on a per-router
basis. However, its optimum value is determined by a network-wide basis. However, its optimum value is determined by a network-wide
behavior. Therefore, changes in the network could require changes to behavior. Therefore, changes in the network could require changes to
the value of the timer, making the optimal setting of this timer a the value of the timer, making the optimal setting of this timer a
moving target. moving target.
Acknowledgements
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg
Mirsky, and Nobo Akiya for their contributions to this document.
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 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
Mountain View, CA 94043 Mountain View, CA 94043
U.S.A. United States
Email: inaminei@google.com Email: inaminei@google.com
Michael Conn Michael Conn
Verizon Verizon
Email: michael.e.conn@verizon.com Email: meconn26@gmail.com
Dante Pacella Dante Pacella
Verizon Verizon
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
Luis Tomotaki Luis Tomotaki
Verizon Verizon
Email: luis.tomotaki@verizon.com Email: luis.tomotaki@verizon.com
 End of changes. 75 change blocks. 
164 lines changed or deleted 157 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/