RSVP Setup Protection
draft-shen-mpls-rsvp-setup-protection-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yimin Shen , Yuji Kamite | ||
| Last updated | 2012-09-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-shen-mpls-rsvp-setup-protection-01
Internet Engineering Task Force Y. Shen
Internet-Draft Juniper Networks
Intended status: Standards Track Y. Kamite
Expires: March 10, 2013 NTT Communications Corporation
September 6, 2012
RSVP Setup Protection
draft-shen-mpls-rsvp-setup-protection-01
Abstract
RFC 4090 specifies an RSVP facility-backup fast reroute mechanism
that can protect LSPs against link and node failures. This document
extends the mechanism to provide "setup protection" for LSPs during
initial Path message signaling time. In particular, it enables a
router to reroute an LSP via an existing bypass LSP, when there is a
link or node failure along the desired path.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
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 March 10, 2013.
Copyright Notice
Copyright (c) 2012 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
Shen & Kamite Expires March 10, 2013 [Page 1]
Internet-Draft RSVP Setup Protection September 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
3.1. New RSVP Attribute Flag . . . . . . . . . . . . . . . . . 5
3.2. New RSVP Attributes TLVs . . . . . . . . . . . . . . . . . 5
3.2.1. Protected LSP Sender IPv4 Address TLV . . . . . . . . 6
3.2.2. Protected LSP Sender IPv6 Address TLV . . . . . . . . 6
3.3. PLR behavior . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. MP behavior . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Local Revertive Mode . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Shen & Kamite Expires March 10, 2013 [Page 2]
Internet-Draft RSVP Setup Protection September 2012
1. Introduction
In RSVP facility-backup fast reroute (FRR) [RFC 4090], the router at
a point of local repair (PLR) of an LSP can redirect traffic via a
bypass LSP upon a failure of the immediate downstream link or node.
Such kind of protection is normally established after the PLR has
received a Resv message of the LSP. In link protection, the PLR must
learn the label and address of the next-hop router, before it can set
up or select a bypass LSP to protect the LSP. Likewise, in node
protection, the PLR must learn the label and address of the next-
next-hop router. The information of the label and the address is
carried in the Resv message.
Imagine a scenario where an LSP is being signaled, but its Path
message carries an EXPLICIT_ROUTE object (ERO) that is statically
configured or computed based on a topology that may not reflect the
current state of every link or node of the network. If a link or
node along this path is in a failure condition, RSVP signaling will
halt at the router immediate upstream of the failure. This will be
the case even if there is an existing bypass LSP protecting the link
or node for some other LSPs. In other words, the LSP is not
protected during its setup time, i.e. the initial Path message
signaling time.
In this situation, the network would rely on IGP to flood the up-to-
date traffic engineering (TE) information, and the router immediate
upstream of the failure to send a PathErr message to notify the
ingress router. The ingress router can then compute and signal a new
path to avoid the failed link or node. However, this approach may
not always be possible or desirable, as in the scenarios below.
1. Pre-configured or pre-defined paths. If the path is pre-
configured or pre-defined, and the ingress router is incapable of
computing a new path, the LSP will not be set up.
2. LSPs with a strict requirement for setup time. IGP TE
information flooding, PathErr message propagation, path re-
computation, and RSVP re-signaling may introduce a significant
delay to LSP establishment. This may impact on signaling
performance for services that have a strict requirement for LSP
setup time, such as an on-demand transport service for real-time
data.
3. Sibling P2MP sub-LSPs sharing a failed link. In this case, the
LSP being signaled is a sub-LSP of a P2MP LSP, and it is supposed
to share the failed link with an existing sibling sub-LSP (i.e.
another sub-LSP of the same P2MP LSP) which is being protected by
a bypass LSP. If the new sub-LSP is rerouted via a different
Shen & Kamite Expires March 10, 2013 [Page 3]
Internet-Draft RSVP Setup Protection September 2012
path, it will not be able to share the data flow over the bypass
LSP with that sibling sub-LSP, and unnecessary traffic flow will
be generated in the network.
This document extends the RSVP facility-backup fast reroute mechanism
to provide so-called "setup protection" for LSPs. During the initial
Path message signaling of an LSP, if there is a link or node failure
along the desired path, and if there is a bypass LSP protecting the
link or node, the LSP will be signaled through the bypass LSP. The
LSP will be established as if it was originally set up along the
desired primary path and then failed over to the bypass LSP after the
link or node failure. When the link or node is restored, the LSP MAY
be reverted to the primary path. The mechanism supports both P2P and
P2MP LSPs.
2. Specification of Requirements
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 RFC 2119.
3. Theory of Operation
When an LSP is being signaled by RSVP, a Path message is sent hop by
hop from the ingress router to the egress router, following the path
defined by an ERO. The setup protection mechanism in this document
enables an ingress or transit router to reroute the LSP via a bypass
LSP, if the router detects a failure of the immediate downstream link
or node represented by the next hop in the ERO, i.e. next ERO hop.
This router is referred to as a PLR.
The mechanism is relevant when the Path message carries the "local
protection desired" flag in the SESSION_ATTRIBUTE object [RFC 4090]
and a new "setup protection desired" flag defined in this document
(Section 3.1).
On a PLR, the mechanism is only applicable when the next ERO hop is a
strict hop, and in case of node protection, the next-next ERO hop is
also a strict hop. A strict next ERO hop allows the PLR to
unambiguously decide the intended downstream link or node on the
desired path, and hence reliably detect the status of the link or
node. In link protection, the strict next ERO hop also indicates the
merge point (MP), i.e. the destination of the bypass LSP to be used
for rerouting the LSP. In node protection, the strict next-next ERO
hop indicates the MP.
Shen & Kamite Expires March 10, 2013 [Page 4]
Internet-Draft RSVP Setup Protection September 2012
When performing setup protection, the PLR signals a backup LSP by
tunneling a Path message through the bypass LSP. Like the Path
message of a backup LSP in the normal facility-backup FRR, this Path
message carries an address of the PLR as the sender address. In
addition, the Path message also carries some information of the
protected LSP (Section 3.2). When the MP receives the Path message,
it terminates the backup LSP, and then re-creates the protected LSP.
If the MP is a transit router of the protected LSP, it signals the
LSP further downstream.
Eventually, the LSP will be established end to end, with the backup
LSP tunneled through the bypass LSP from the PLR to the MP. The RSVP
state on the PLR and the MP and the RSVP messages generated by these
routers are no different than those of an LSP in a post-failure
situation of the normal facility-backup FRR.
After the link or node is restored, the PLR MAY revert the LSP to the
primary path, in the same manner as the local revertive mode
specified in [RFC 4090].
The setup protection mode MAY be enabled and disabled on a router
based on configuration. For an LSP to be setup-protected, the mode
MUST be enabled on both PLR and MP. If it is enabled on a PLR but
disabled on an MP, the MP SHOULD reject the Path message of the
backup LSP and send a PathErr message, as described Section 3.4.
3.1. New RSVP Attribute Flag
In order to facilitate explicit request for setup protection, this
document defines a new "setup protection desired" flag in the
Attribute Flags TLV, which is carried in the LSP_ATTRIBUTES object
[RFC5420] of the Path message of a protected LSP.
3.2. New RSVP Attributes TLVs
This document defines two new RSVP Attributes TLVs [RFC 5420]. They
are used by a PLR to convey to an MP the original sender address of a
protected LSP. Both TLVs are carried in the LSP_REQUIRED_ATTRIBUTES
object in the Path message of a backup LSP.
o Protected LSP Sender IPv4 Address TLV
o Protected LSP Sender IPv6 Address TLV
Shen & Kamite Expires March 10, 2013 [Page 5]
Internet-Draft RSVP Setup Protection September 2012
3.2.1. Protected LSP Sender IPv4 Address TLV
The Protected LSP Sender IPv4 Address TLV is defined with type X. It
is allowed on LSP_REQUIRED_ATTRIBUTES object, and not allowed on
LSP_ATTRIBUTES object. It is encoded as the following.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Type
TBD
Length
8
Value
Original sender address in the IPv4 SENDER_TEMPLATE object of the
protected LSP.
3.2.2. Protected LSP Sender IPv6 Address TLV
The Protected LSP Sender IPv6 Address TLV is defined with type Y. It
is allowed on LSP_REQUIRED_ATTRIBUTES object, and not allowed on
LSP_ATTRIBUTES object. It is encoded as the following.
Shen & Kamite Expires March 10, 2013 [Page 6]
Internet-Draft RSVP Setup Protection September 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length (20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Type
TBD
Length
20
Value
Original sender address in the IPv6 SENDER_TEMPLATE object of the
protected LSP.
3.3. PLR behavior
When a router has a Path message to send out, if the Path message
carries the "local protection desired" flag in the SESSION_ATTRIBUTE
object and the "setup protection desired" flag in the LSP_ATTRIBUTES
object, and if the next ERO hop is a strict IPv4 or IPv6 prefix, the
router SHOULD validate the prefix against the routing table, the
traffic engineering (TE) database, and/or a topology database. If
the prefix is reachable and is one hop away from the router, the Path
message is sent as it is. Otherwise, there is a possibility that the
link or node represented by the prefix has experienced a failure.
The router SHOULD determine this by searching for an existing bypass
LSP that is protecting the prefix. If the protected LSP desires link
protection, the destination of the bypass LSP (i.e. MP) is
considered as the router that owns the prefix. If the LSP desires
node protection with the "node protection desired" flag set in the
SESSION_ATTRIBUTE object, the next-next ERO hop of the LSP must also
be a strict prefix, and the MP is considered as the router that owns
this prefix.
If a bypass LSP is not found, the router MUST originate a PathErr
with code = 24 (routing problem) and sub-code = 2 (bad strict node).
Shen & Kamite Expires March 10, 2013 [Page 7]
Internet-Draft RSVP Setup Protection September 2012
If a bypass LSP is found, the router MUST act as a PLR of setup
protection, and reroute the protected LSP via the bypass LSP. If
multiple satisfactory bypass LSPs exist, the PLR MAY select one based
on bandwidth constraints or local policies. If the protected LSP is
a sub-LSP of a P2MP LSP, a bypass LSP that is protecting an existing
sibling sub-LSP MUST be preferred, in order to minimize traffic
duplication in the network.
The PLR SHOULD NOT send a Path message for the protected LSP.
Instead, it MUST create a backup LSP, and send a Path message of the
backup LSP to the MP via the bypass LSP. The Path message is
constructed by using the sender template specific method [RFC 4090].
In particular, it has the sender address in the SENDER_TEMPLATE
object set to an address of the PLR. It MUST also carry an
LSP_REQUIRED_ATTRIBUTES object containing a Protected LSP Sender IPv4
Address TLV or Protected LSP Sender IPv6 Address TLV.
Upon receiving a Resv message of the backup LSP from the MP, the PLR
SHOULD brings up both of the backup LSP and the protected LSP. If
the PLR is the ingress router of the protected LSP, the LSP has been
set up successfully. If the PLR is a transit router, it MUST send a
Resv message upstream for the protected LSP, with the "local
protection available", "local protection in use", and optionally
"node protection" and "bandwidth protection" flags set to 1 in the
RRO hop corresponding to the PLR [RFC 4090]. The PLR SHOULD
originate a PathErr message with code = 25 (notify error) and sub-
code = 3 (tunnel locally repaired).
The PLR SHOULD also install a forwarding entry for the protected LSP.
The next-hop of this entry MAY indicate zero, one, or two outgoing
labels, depending on whether any of the backup LSP's label and the
bypass LSP's label is Implicit NULL. In the case of two labels, the
inner label is the backup LSP's label, and the outer label is the
bypass LSP's label.
If the PLR receives a PathErr message when signaling the backup LSP,
the PLR MUST NOT bring up the backup LSP or the protected LSP. If
the PLR is a transit router of the protected LSP, it MUST send a
PathErr message upstream for the protected LSP. Likewise, if the PLR
receives a PathErr message after the backup LSP and the primary LSP
have been set up, and the PLR is a transit router of the protected
LSP, it MUST also send a PathErr message upstream for the protected
LSP.
When the PLR receives a ResvTear message of the backup LSP, the PLR
MUST bring down both the backup LSP and the protected LSP. If the
PLR is a transit router of the protected LSP, it MUST send a ResvTear
message upstream for the protected LSP.
Shen & Kamite Expires March 10, 2013 [Page 8]
Internet-Draft RSVP Setup Protection September 2012
In any cases where the PLR tears down the protected LSP due to a
received PathTear message, RSVP state time-out, configuration change,
administrative command, etc, the PLR MUST also tear down the backup
LSP by sending a PathTear message through the bypass LSP.
3.4. MP behavior
When an MP receives the Path message of a backup LSP, it SHOULD
detect the setup protection condition based on the presence of
Protected LSP Sender IPv4 Address TLV or Protected LSP Sender IPv6
Address TLV in LSP_REQUIRED_ATTRIBUTES object.
If setup protection mode is disabled on the MP, it MUST reject the
Path message, by sending a PathErr with code = 2 (policy control
failure) to the PLR.
Otherwise, the MP MUST terminate the backup LSP and re-create the
protected LSP. If the MP is the egress router of the protected LSP,
it MUST also terminate the protected LSP. If the MP is a transit
router of the LSP, it MUST send a Path message downstream for the
protected LSP. The Path message has the sender address in
SENDER_TEMPLATE object set to the original address of the ingress
router, based on the above received TLV. The Path message MUST NOT
carry the Protected LSP Sender IPv4 Address TLV or Protected LSP
Sender IPv6 Address TLV received in the above LSP_REQUIRED_ATTRIBUTES
object.
The MP MUST allocate a label for the backup LSP, and distribute it to
the PLR via the Resv message of the backup LSP. If the protected LSP
is a sub-LSP of a P2MP LSP and there is an existing sibling sub-LSP,
the MP SHOULD allocate the same label as the sibling sub-LSP, in
order to avoid traffic duplication in the network.
When the MP receives a PathTear message of the backup LSP, it MUST
tear down both the backup LSP and the protected LSP. If the MP is a
transit router of the protected LSP, it MUST send a PathTear message
downstream.
In any cases where the MP receives or originates a PathErr or
ResvTear message for the protected LSP, the MP SHOULD translate the
message to a message of the backup LSP and send it to the PLR.
3.5. Local Revertive Mode
When the failed link or node is restored, the PLR MAY revert the
protected LSP to its desired primary path, by following the procedure
of local revertive mode described in [RFC 4090].
Shen & Kamite Expires March 10, 2013 [Page 9]
Internet-Draft RSVP Setup Protection September 2012
4. IANA Considerations
This document defines a new flag in the Attribute Flags TLV, which is
carried in the LSP_ATTRIBUTES Object of Path message. This flag is
used to communicate whether setup protection is desired for an LSP.
New flag value needs to be assigned to it by IANA.
Setup Protection Desired: TBD
This document defines two new RSVP Attributes TLVs, which are carried
in the LSP_REQUIRED_ATTRIBUTES object of Path message. New type
values need to be assigned to them by IANA.
Protected LSP Sender IPv4 Address TLV
Protected LSP Sender IPv6 Address TLV
5. Security Considerations
The security considerations discussed in RFC 3209, RFC 4090 and RFC
4875 apply to this document.
6. Acknowledgements
Thanks to Rahul Aggarwal, Disha Chopra, and Nischal Sheth for their
contribution.
7. References
7.1. Normative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Shen & Kamite Expires March 10, 2013 [Page 10]
Internet-Draft RSVP Setup Protection September 2012
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Constraint-
based Routed Label Distribution Protocol (CR-LDP)
Extensions", RFC 3472, January 2003.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
7.2. Informative References
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone: +1 9785890722
Email: yshen@juniper.net
Yuji Kamite
NTT Communications Corporation
Granpark Tower 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.com
Shen & Kamite Expires March 10, 2013 [Page 11]