Skip to main content

RSVP Setup Protection
draft-shen-mpls-rsvp-setup-protection-00

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-03-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-00
Internet Engineering Task Force                                  Y. Shen
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                               Y. Kamite
Expires: September 6, 2012                NTT Communications Corporation
                                                           March 5, 2012

                         RSVP Setup Protection
                draft-shen-mpls-rsvp-setup-protection-00

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 a 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 September 6, 2012.

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 September 6, 2012               [Page 1]
Internet-Draft            RSVP Setup Protection               March 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 Attributes TLVs . . . . . . . . . . . . . . . . .  5
       3.1.1.  Protected LSP Sender IPv4 Address TLV  . . . . . . . .  5
       3.1.2.  Protected LSP Sender IPv6 Address TLV  . . . . . . . .  6
     3.2.  PLR behavior . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  MP behavior  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Local Revertive Mode . . . . . . . . . . . . . . . . . . .  9
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Shen & Kamite           Expires September 6, 2012               [Page 2]
Internet-Draft            RSVP Setup Protection               March 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 onto a
   bypass LSP upon a failure of the immediate downstream link or node.
   The establishment of such protection is normally triggered by
   receiving a Resv message.  In link protection, the PLR must learn the
   label and address of the nexthop 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-
   nexthop router.  The information is carried in Resv message.

   Imagine a scenario where an LSP is being signaled, but its Path
   message carries an EXPLICIT_ROUTE object (ERO) that is pre-computed,
   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 on this path has already failed, the signaling will halt
   at the router immediate upstream of the failure.  This will still be
   the case even if there is an existing bypass LSP protecting the link
   or node for some other P2P or P2MP LSP.  In other words, the LSP is
   not protected during 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 originate a PathErr message, so that the
   ingress router of the LSP can compute and signal a new path to avoid
   the failed link or node.  However, this approach may not always be
   possible or desirable, as can be seen in the scenarios described
   below.

   1.  Pre-computed or explicitly defined paths.  If the path is pre-
       computed or fixed, or the ingress router is incapable of re-
       computing the path, an alternative path will not be set up.

   2.  Requirements for LSP setup time.  Control protocol convergence
       and path computation may introduce a significant delay, which may
       impact signaling performance for services that have a specific
       requirement for LSP setup time.

   3.  Sibling sub-LSPs of a P2MP LSP sharing the failed link.  In this
       case, the existing bypass LSP will not be used, even if it is the
       preferred alternative path.  For example, the LSP being signaled
       is a sub-LSP of a P2MP LSP, and it is expected to share the same
       downstream link with an existing sibling sub-LSP (sub-LSP of the
       same P2MP LSP).  If the new sub-LSP is rerouted through another
       path, unnecessary traffic will be generated on the network.

   This document extends the RSVP facility-backup fast reroute mechanism

Shen & Kamite           Expires September 6, 2012               [Page 3]
Internet-Draft            RSVP Setup Protection               March 2012

   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
   on the desired path, and 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 its 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
   allows 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, and optionally the "node protection
   desired" and "bandwidth protection desired" flags in the
   SESSION_ATTRIBUTE object.

   On a given 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, and
   hence reliably detect its status.  For link protection, the strict
   nexthop also indicates the merge point (MP), i.e. the egress router
   of the bypass LSP to be used for rerouting the LSP.  For node
   protection, the strict next-next ERO hop indicates the MP.

   During setup protection operation, the PLR signals a backup LSP by
   tunneling a Path message through the bypass LSP.  Unlike the normal
   facility-backup FRR, this Path message carries additional information
   of the protected LSP (Section 3.1).  When the MP receives the Path
   message, it terminates the backup LSP, and also re-creates the
   protected LSP.  If the MP is a transit router of the protected LSP,
   it signals the LSP further downstream.

Shen & Kamite           Expires September 6, 2012               [Page 4]
Internet-Draft            RSVP Setup Protection               March 2012

   Eventually, the LSP is established end to end, with the backup LSP
   being tunneled through the bypass LSP from the PLR to the MP.  The
   RSVP states on the PLR and the MP and the RSVP messages generated by
   these routers are the same as those in a normal facility-backup FRR
   scenario.

   After the failed link or node is restored, the PLR MAY revert the LSP
   to the primary path.  This is referred to as local revertive mode, as
   described 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.3.

3.1.  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.

   o  Protected LSP Sender IPv4 Address TLV

   o  Protected LSP Sender IPv6 Address TLV

   Both TLVs are carried by the LSP_REQUIRED_ATTRIBUTES object in the
   Path message of a backup LSP.

3.1.1.  Protected LSP Sender IPv4 Address TLV

   The Protected LSP Sender IPv4 Address TLV is defined with type 2.  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

Shen & Kamite           Expires September 6, 2012               [Page 5]
Internet-Draft            RSVP Setup Protection               March 2012

      TBD

   Length

      8

   Value

      Original sender address in the IPv4 SENDER_TEMPLATE object of the
      protected LSP.

3.1.2.  Protected LSP Sender IPv6 Address TLV

   The Protected LSP Sender IPv6 Address TLV is defined with type 3.  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 (20)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                            Value                            //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   Type

      TBD

   Length

      20

   Value

      Original sender address in the IPv6 SENDER_TEMPLATE object of the
      protected LSP.

3.2.  PLR behavior

   When a router has a Path message to send out and the next ERO hop is
   a strict IPv4 or IPv6 prefix, the router validates the hop against
   the routing table, traffic engineering (TE) database, and/or a

Shen & Kamite           Expires September 6, 2012               [Page 6]
Internet-Draft            RSVP Setup Protection               March 2012

   topology database.  If the hop is reachable and one hop away from the
   router, the Path message is sent as it is.  Otherwise, there is a
   possibility that the hop has experienced a link or node failure.

   The router determines this by searching for an existing bypass LSP
   that is protecting the hop.  If the LSP being signaled desires link
   protection, the egress router of the bypass LSP (i.e.  MP) must be
   the router that owns the IP prefix of the hop.  If the LSP desires
   node protection, the next-next ERO hop of the LSP must also be a
   strict IP prefix, and the MP must be the router that owns this IP
   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).

   If a bypass LSP is found, the router MUST act as a PLR of setup
   protection, and reroute the LSP via the bypass LSP.  If multiple such
   bypass LSPs exist, the PLR MAY select one based on bandwidth
   constraints or policy.  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.  This helps against generating duplicate traffic on two
   separate bypass LSPs.

   The PLR SHOULD NOT send the Path message of the protected LSP.
   Instead, it MUST create a backup LSP, and send a Path message for the
   backup LSP 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 SENDER_TEMPLATE object set to an address
   of the PLR.  It MUST also carried a LSP_REQUIRED_ATTRIBUTES object
   containing a Protected LSP Sender IPv4 Address TLV or Protected LSP
   Sender IPv6 Address TLV.

   Upon receiving a Resv message from the MP, the PLR 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,
   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 MUST
   originate a PathErr message with code = 25 (notify error) and sub-
   code = 3 (tunnel locally repaired).

   The PLR also installs a forwarding entry for the LSP.  The nexthop 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.

Shen & Kamite           Expires September 6, 2012               [Page 7]
Internet-Draft            RSVP Setup Protection               March 2012

   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 propagate
   the PathErr message upstream.  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 propagate the PathErr message upstream.

   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.

   In any case where the PLR tears down the protected LSP due to receipt
   of a PathTear message, state time-out, configuration, etc, the PLR
   MUST also tear down the backup LSP by sending a PathTear message
   through the bypass LSP.

3.3.  MP behavior

   When a MP receives the Path message of a backup LSP, it detects 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 the setup protection mode is disabled on the router, it MUST
   reject the Path message.  In this case, the router recognizes the
   TLV, but does not support it.  Therefore, it MUST originate a PathErr
   with code = 2 (policy control failure).

   The MP then terminates the backup LSP, and re-creates the protected
   LSP.  If the MP is the egress router of the LSP, it MUST also
   terminate the protected LSP.  Otherwise, it MUST send a Path message
   of the protected LSP downstream.  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 a Protected LSP Sender IPv4 Address TLV or Protected
   LSP Sender IPv6 Address TLV.

   The MP MUST allocate a label for the 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, the MP MAY allocate the same label as an
   existing sibling sub-LSP, in order to avoid traffic duplication.

   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.

Shen & Kamite           Expires September 6, 2012               [Page 8]
Internet-Draft            RSVP Setup Protection               March 2012

   In any case where the MP receives or originates a PathErr or ResvTear
   message of the protected LSP, it SHOULD translate it into a message
   of the backup LSP and send it to the PLR.

3.4.  Local Revertive Mode

   When the failed link or node is restored, the PLR MAY revert the
   protected LSP to its primary path, following the procedure of local
   revertive mode described in [RFC 4090].

4.  IANA Considerations

   This document defines two new RSVP Attributes TLVs.  New type values
   need to 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.

Shen & Kamite           Expires September 6, 2012               [Page 9]
Internet-Draft            RSVP Setup Protection               March 2012

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              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 September 6, 2012              [Page 10]