[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

   CCAMP Working Group                                        Zafar Ali
   Internet Draft                                        George Swallow
   Intended status: Standard Track                    Clarence Filsfils
   Expires: August 17, 2013                                 Ori Gerstel
                                                           Matt Hartley
                                                           Cisco Systems
                                                       February 18, 2013

          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
                Extension for Label Switched Path (LSP) Inquiry

                      draft-ali-ccamp-lsp-inquiry-00.txt


   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 August 15, 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 the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow



   Ali, Swallow, Filsfils   Expires August 2013               [Page 1]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Abstract

   RSVP-TE reoptimization procedure for Packet Switch Capable (PSC)
   tunnels and non-PSC tunnels has some differences. This document
   highlights these differences, describes how existing procedures can
   be used for reoptimization of non-PSC tunnels and proposes some
   enhancements for reoptimization of non-PSC tunnels.

   Conventions used in this document

   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 [RFC2119].

   Table of Contents

   1. Introduction .................................................. 2
     1.1. Inquiry with Resource Locking.............................. 4
     1.2. Inquiry without Resource Locking .......................... 5
   2. RSVP-TE signaling procedure ................................... 6
     2.1. RSVP-TE Signaling for Inquiry with Resource Locking ....... 6
     2.2. RSVP-TE Signaling for Inquiry without Resource Locking .... 7
   3. Security Considerations ....................................... 8
   4. IANA Considerations ........................................... 8
     4.1. RSVP Attribute Bit Flags .................................. 8
   5. References
.................................................... 9
     5.1. Normative References ...................................... 9
     5.2. Informative References .................................... 9


   1. Introduction

   During reoptimization of PSC tunnel, existing and reoptimization
   LPSs may use independent labels and may install independent


   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 2]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


   forwarding states for each LSP. That is, existing and reoptimization
   LSPs may be simultaneously active in both control and data planes.
   However, for many non-PSC technologies label itself represents the
   underlying physical resource and hence cannot be shared between
   existing and reoptimization LSPs in the data plane. Consequently,
   for many non-PSC technologies, reoptimization LSPs can only be
   instantiated in the control plane. Furthermore, reoptimization LSP
   is not immediately available to carry any traffic and requires
   additional signaling for its activation in the data plane.

   In this document, inquiry refers to a way to signal sharing of
   resources (e.g., labels, links) between the existing and
   reoptimization LSPs in the control plane without installing any
   forwarding states in the data plane (e.g., without installing cross-
   connections). In most non-PSC networks, inquiry step is required to
   access feasibility and characteristics of the reoptimization LSP
   before committing data plane resources and moving traffic to it.
   This is especially true of scenarios when route computation is not
   performed by ingress Label Edge Router (LER). These include (but are
   not limited to):
      .  LSPs with loose hops in the Explicit Route Object (ERO), e.g.
        inter-domain LSPs.

      .  Generalized Multi-Protocol Label Switching (GMPLS) User-
        Network Interface (UNI) where route computation may be
        performed by the (server layer) core Label Switch Router (LSR)
        [RFC4208];

   In such cases, ingress LER may like to inquire about feasibility and
   attributes of a better path. Cost, TE metrics and SRLG values are
   examples of attributes that ingress LER may like to inquire about
   (e.g., before making a reoptimization decision). Procedures
   specified in [ID.SRLG-RECORDING] and [ID.METRIC-RECORDING] may be
   used for this purpose.

   Reoptimization is an example where inquiry procedure is needed.
   However, inquiry is also useful for other use cases, e.g., for
   probing purposes. Hence, for the generalization purposes, LSP
   signaled during inquiry is referred as inquiry LSP. Reoptimization
   LSP is an example of inquiry LSP.




   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 3]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


   Inquiry LSP may be signaled with or without resource locking in the
   control plane. This is detailed in the following.

   1.1. Inquiry with Resource Locking

      Signaling inquiry LSP with resource locking is depicted in Figure
      1. Specifically, Path message (Path1) is signaled such that
      resource activation is Data Plane (DP) is skipped. However,
      inquiry LSP reserves resources in the Control Plane (CP), i.e.,
      resources/ labels are locked/ committed in the control plane.
      Nonetheless, resources/ labels are still shared with the existing
      LSP(s) belonging to the tunnel inquiry LSP belongs to.

          |  Path (Path1)  | Path (Path1)   | Path (Path1)   |
          | with resource  | with resource  | with resource  |
          | locking in CP  | locking in CP  | locking in CP  |
          | but without DP | but without DP | but without DP |
          | activation     | activation     | activation     |
          |--------------->|--------------->|--------------->|
          |<---------------|<---------------|<---------------|
          | Resv (Resv1)   | Resv (Resv1)   | Resv (Resv1)   |
          |                |                |                |
    +-----------+
    |Inquiry LSP|
    |Passes     |
    |Evaluation |
    +-----------+
          |                |                |                |
          |  Path Change   |  Path Change   |   Path Change  |
          |    (Path2)     |    (Path2)     |    (Path2)     |
          |     for DP     |     for DP     |     for DP     |
          |   activation   |   activation   |   activation   |
          |--------------->|--------------->|--------------->|
          |<---------------|<---------------|<---------------|
          | Resv (Resv2)   | Resv (Resv2)   | Resv (Resv2)   |
          |                |                |                |
        Ingress LER      LSR A            LSR B       Egress LER

          Figure 1: Inquiry LSP Signaling with Resource Locking


   By the time Resv1 for the initial Path message (Path1) is received
   by the ingress LER, the ingress LER knows about feasibility and the
   requested attributes of the inquiry LSR. Please note that to ensure
   resource locking at the right priority, inquiry LSP needs to be
   signaled using the same setup and hold priority as existing LSP.

   After finding feasibility and the requested attributes of the
   inquiry LSP, the ingress LER evaluates inquiry LSP. E.g., if the
   inquiry LSP is signaled for reoptimization purposes, the ingress LER


   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 4]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


   determines if it would like to reoptimize the existing LSP. If
   ingress LER decides not to reoptimize existing LSP, it deletes the
   inquiry LSP (by sending Path tear message -
                                             - this option is not shown
   in Figure 1). However, if the ingress LER decides to reoptimize the
   tunnel to use the inquire LSP, it initiates activation of the
   inquiry LSP in the data plane (as shown by Path2 and Resv2 signaling
   loop in Figure 1). How ingress LER moves traffic from existing LSP
   to inquire LSP for reoptimization purpose is beyond the scope of
   this document.

   1.2. Inquiry without Resource Locking

   When inquiry is performed with resource locking, the resources used
   by the inquiry LSP are locked in control plane and cannot be used by
   any LSP other than the LSP(s) belonging to the same tunnel (of
   course resource preemption based on setup and hold priority of the
   inquiry LSP is still possible). This limits network availability in
   the event of a failure, especially when inquiry is used frequently,
   e.g., for probing purposes. This issue can be addressed by signaling
   inquiry LSP without resource locking. In this case, the resources
   used by the inquiry LSP are not locked in control plane and can be
   used by any LSP, including the existing LSP(s) belonging to the same
   tunnel. Therefore, if inquiry LSP is signaled without resource
   locking, additional signaling is required to first lock the
   resources in the control plane, before the LSP can be activated in
   the data plane. This is depicted in the following Figure.

          |  Path (Path1)  | Path (Path1)   | Path (Path1)   |
          |without resource|without resource|without resource|
          | locking in CP  | locking in CP  | locking in CP  |
          | and without DP | and without DP | and without DP |
          | activation     | activation     | activation     |
          |--------------->|--------------->|--------------->|
          |<---------------|<---------------|<---------------|
          | Resv (Resv1)   | Resv (Resv1)   | Resv (Resv1)   |
          |                |                |                |
    +-----------+
    |Inquiry LSP|
    |Passes     |
    |Evaluation |
    +-----------+
          |                |                |                |
          |  Path Change   |  Path Change   |   Path Change  |
          |    (Path2)     |    (Path2)     |    (Path2)     |
          |  for resource  |  for resource  |  for resource  |
          | locking in CP  | locking in CP  | locking in CP  |
          |--------------->|--------------->|--------------->|
          |<---------------|<---------------|<---------------|
          | Resv (Resv2)   | Resv (Resv2)   | Resv (Resv2)   |
          |                |                |                |


   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 5]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt

          |                |                |                |
          |  Path Change   |  Path Change   |   Path Change  |
          |    (Path3)     |    (Path3)     |    (Path3)     |
          |     for DP     |     for DP     |     for DP     |
          |   activation   |   activation   |   activation   |
          |--------------->|--------------->|--------------->|
          |<---------------|<---------------|<---------------|
          | Resv (Resv3)   | Resv (Resv3)   | Resv (Resv3)   |
          |                |                |                |
        Ingress LER      LSR A            LSR B       Egress LER

          Figure 2: Inquiry LSP Signaling without Resource Locking


   Initial Path message (Path1) is signaled such that resource locking
   in control plane and resource activation is data plane is skipped.
   By the time Resv1 for the initial Path message (Path1) is received
   by the ingress LER, the ingress LER knows about feasibility and the
   requested attributes of the inquiry LSR. The inquiry LSP evaluation
   process works in the same fashion as discussed in Section 1.1.

   As Path1 is signaled without resource locking, there is no guarantee
   that the resources for the inquiry LSP will be available when
   ingress LER decides to activate the inquiry LSP. Therefore, the
   ingress LER first signals a path change (Path2) to lock the resource
   in the control plane before inquiry LSP can be activated in the data
   plane.

   2. RSVP-TE signaling procedure

   This section describes the signaling procedure for LSP inquiry with
   and without resource locking.

   2.1. RSVP-TE Signaling for Inquiry with Resource Locking

      [RFC6001] specifies procedure for signaling Soft Forwarding
      Adjacency (Soft FA). It defines the Pre-Planned LSP flag in the
      Attribute Flags TLV, which can be carried in an LSP_ATTRIBUTES
      object defined in [RFC5420]. The Pre-Planned LSP flag can also be
      used to signal inquiry LSP with resource locking.

      The processing rules for the Pre-Planned LSP flag are unchanged
      from [RFC6001]. The procedures for the processing the Attribute
      Flags TLV are also unchanged from [RFC5420]. The following
      description is provided to help describe usage of the Pre-Planned
      LSP flag in the context of signaling the inquiry LSP. Example of
      Figure 1 is used to describe the usage.




   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 6]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


         .  Path1 message in Figure 1 is sent with the Pre-Planned LSP
           flag set to 1. As per [RFC6001], this enables provisioning
           of inquiry LSP in control plane only. In order to enable
           sharing if resources within the same tunnel, Path1 message
           is sent with shared explicit reservation style [RFC3209].

         .  In order to activate inquiry LSP in the data plane, Path2
           message (please see Figure 1) is sent with the Pre-Planned
           LSP flag set to 0.

   2.2. RSVP-TE Signaling for Inquiry without Resource Locking

         In order to indicate signaling of an LSP without resource
      provisioning in neither control plane nor data plane, a new flag
      in the Attribute Flags TLV, which can be carried in an
      LSP_ATTRIBUTES Object, is defined as follows:

         .  Pre-Planned LSP Without Resource Locking flag (to be
           assigned by IANA, recommended bit position TBD)

         The Pre-Planned LSP Without Resource Locking flag is
      meaningful on a Path message. The procedure for the processing
      the Attribute Flags TLV follows [RFC5420]. The flag is used as
      described in the following.



         .  If the Pre-Planned LSP Without Resource Locking flag is set
           to 1, the transit nodes SHOULD NOT reserve resources
           required by the LSP in the control plane and MUST NOT
           install any forwarding states associated with the LSP in the
           data plane. However, all LERs and LSRs are required to
           remember the resource (labels, links, etc.) assignments and
           the RSVP-TE states associated with this LSP. These resources
           are not locked and hence can be claimed by anther LSP. If
           the Pre-Planned LSP Without Resource Locking flag is set to
           1, the Pre-Planned LSP flag MUST be ignored. In our example
           of Figure 2, Path1 message is sent with the Pre-Planned LSP
           Without Resource Locking flag set to 1.

         .  If the Pre-Planned LSP Without Resource Locking flag is set
           to 0 and the Pre-Planned LSP flag is set to 1, the transit
           nodes MUST commit resources associated with the LSP in the
           control plane. However, if a resource is already claimed by
           another LSP, the processing LSR/ LER MUST send a Path Error
           with code: "Admission Control Failure (1)" and subcode "LSP
           Admission Failure (4) and Path State Removal flag. A


   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 7]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


           processing LSR/ LER MUST NOT install any forwarding states
           associated with the LSP in the data plane. Path2 message in
           Figure 2 is sent with the Pre-Planned LSP Without Resource
           Locking flag set to 0 and the Pre-Planned LSP flag is set to
           1. It is RECOMMENDED that no other modifications be made to
           other RSVP objects during this operation (signaling Path2).

         .  Activation of LSP in data plane follows the procedure
           specific in [RFC6001]. E.g., Path2 message in Figure 2 is
           sent with the Pre-Planned LSP flag set to 0.

   3. Security Considerations

      This document does not introduce any additional security issues
      above those identified in [RFC5920], [RFC2205], [RFC3209], and
      [RFC3473] and [RFC4874].

   4. IANA Considerations

   4.1. RSVP Attribute Bit Flags

         The IANA has created a registry and manages the space of
      attributes bit flags of Attribute Flags TLV as described in
      section 11.3 of [RFC5420]. It is requested that the IANA makes
      assignments from the Attribute Bit Flags defined in this
      document.

         This document introduces the following new Attribute Bit Flag:

            - Bit number: TBD

            - Defining RFC: this I-D

            - Name of bit: Pre-Planned LSP Without Resource Locking
      Flag







   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 8]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


   5. References

   5.1. Normative References

      [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 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.

      [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
                Brungard, D., and JL. Le Roux, "Generalized MPLS
                (GMPLS) Protocol Extensions for Multi-Layer and Multi-
                Region Networks (MLN/MRN)", RFC 6001, October 2010.

      [RFC5420] Farrel, A., Ed., 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.



   5.2. Informative References

      [ID.SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
                Margaria, "RSVP-TE Extensions for Collecting SRLG
                Information", draft-ietf-ccamp-rsvp-te-srlg-
                collect.txt, work in progress.

      [ID.TE-METRIC-RECORDING] Ali, Z., Swallow, G., Filsfils, C., et
                al "RSVP-TE extension for recording TE Metric of a
                Label Switched Path", draft-ali-ccamp-te-metric-
                recording, work in progress.

      [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
                "Generalized Multiprotocol Label Switching (GMPLS)
                User-Network Interface (UNI): Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Support for the
                Overlay Model", RFC 4208, October 2005.

      [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.



   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 9]


      Internet Draft      draft-ali-ccamp-lsp-inquiry-00.txt


      [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol
                (RSVP) -- Version 1 Message Processing Rules", RFC
                2209, September 1997.

      [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
                Networks", RFC 5920, July 2010.

   Authors' Addresses

      Zafar Ali
      Cisco Systems.
      Email: zali@cisco.com

      George Swallow
      Cisco Systems
      swallow@cisco.com

      Clarence Filsfils
      Cisco Systems, Inc.
      cfilsfil@cisco.com

      Ori Gerstel
      Cisco Systems
      Email: ogerstel@cisco.com

      Matt Hartley
      Cisco Systems
      Email: mhartley@cisco.com





















   Ali, Swallow, Filsfils, et al   Expires August 2013       [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/