CCAMP Working Group                            Vishnu Pavan Beeram (Ed)
 Internet Draft                                         Juniper Networks
 Intended status: Standards Track                      Igor Bryskin (Ed)
                                                 ADVA Optical Networking
 
 Expires: April 20, 2014                                October 20, 2013
 
 
 
                        RSVP Graceful Setup Procedure
                draft-beeram-ccamp-rsvp-graceful-setup-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), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    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."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html
 
    This Internet-Draft will expire on April 20, 2014.
 
 Copyright Notice
 
    Copyright (c) 2013 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
 
 
 
 
 
 Beeram, et al           Expires April 20, 2014                 [Page 1]


 Internet-Draft      RSVP Graceful Setup Procedure          October 2013
 
 
    Section 4.e of the Trust Legal Provisions and are provided without
    warranty as described in the Simplified BSD License.
 
 Abstract
 
    The GMPLS RSVP-TE setup procedure for transport LSPs outlined in
    [RFC3473] involves a single iteration signaling sequence. However
    there are certain scenarios, where it is not feasible to make an LSP
    fully operational and ready for use via the existing single-step
    setup procedure. This document proposes a 2-iteration setup
    procedure for gracefully bringing up transport LSPs in such cases.
 
 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
    2. Graceful Setup Procedure.......................................3
    3. Use Case.......................................................4
       3.1. Lambda LSP setup..........................................4
    4. Security Considerations........................................4
    5. IANA Considerations............................................4
    6. Normative References...........................................4
    7. Acknowledgments................................................5
 
 1. Introduction
 
    The GMPLS RSVP-TE extensions required for setting up transport LSPs
    are discussed in [RFC3473]. As per the existing setup procedure, the
    signaling sequence commences with the ingress sending a PATH message
    downstream. The PATH message traverses through all the intermediate
    nodes and reaches the egress. The egress responds to the setup
    request by sending a RESV message upstream. The setup iteration is
    completed when the RESV reaches the ingress. At the end of this
    iteration, the LSP is deemed operational and ready for use at the
    ingress. Optionally, if the egress desires a confirmation, the
    ingress would send a RESV-CONFIRM message downstream. The LSP is
    deemed operational at the egress as soon as it receives the RESV-
    CONFIRM.
 
 
 
 
 
 Beeram, et al           Expires April 20, 2014                 [Page 2]


 Internet-Draft      RSVP Graceful Setup Procedure          October 2013
 
 
    However, in certain cases (Section 3) there is no guarantee that the
    LSP is operational and ready for use at the end of this first
    iteration. This document proposes the use of a 2-iteration setup
    procedure to cater to those cases. By the end of this Graceful Setup
    Procedure, the end-points are guaranteed that the LSP is operational
    and ready for immediate use.
 
 2. Graceful Setup Procedure
 
    The RSVP graceful setup procedure (illustrated in Figure 1) proposed
    by this document involves two distinct steps. This setup procedure
    is similar in spirit to the 2-step RSVP graceful deletion procedure
    outlined in [RFC3473].
 
    In the first step, the LSP is signaled as "non-operational" - the
    PATH is sent out with the "A" (Administratively Down) bit set in the
    ADMIN_STATUS object. All the resources along the path of the LSP are
    allocated and bound during this iteration.
 
    The LSP is made "operational" only in the second step - the PATH is
    sent out with the "A" bit cleared in the ADMIN_STATUS. The LSP is
    deemed fully operational by the egress when it receives the PATH
    with the "A" bit cleared in the ADMIN_STATUS. Similarly, the LSP is
    deemed ready for immediate use by the ingress when it receives the
    RESV with the "A" bit cleared in the ADMIN_STATUS.
 
      +---+               +---+             +---+               +---+
      | A |---------------| B |-------------| C |---------------| D |
      +---+               +---+             +---+               +---+
 
      Step 1: Prepare the resources along the path of the LSP
 
         PATH
           Admin Status (A, R)
           -------------->   PATH
                               Admin Status (A, R)
                               ------------>   PATH
                                                 Admin Status (A, R)
                                                 -------------->
                                               RESV
                                                 Admin Status (A)
                             RESV                <--------------
                               Admin Status (A)
         RESV                  <------------
           Admin Status (A)
           <--------------
 
 
 
 Beeram, et al           Expires April 20, 2014                 [Page 3]


 Internet-Draft      RSVP Graceful Setup Procedure          October 2013
 
 
 
      Step 2: Make the LSP operational
 
         PATH
           Admin Status (R)
           -------------->   PATH
                               Admin Status (R)
                               ------------>   PATH
                                                 Admin Status (R)
                                                 -------------->
                                               RESV
                                                 Admin Status
                             RESV                <--------------
                               Admin Status
         RESV                  <------------
           Admin Status
           <--------------
 
 
          Figure 1: Graceful Setup Procedure - Signaling Sequence
 
 3.   Use Case
 
 3.1. Lambda LSP setup
 
    After all the cross-connects are set up in both directions at each
    node along the path of the LSP and the lasers are turned on at both
    the ends, the Lambda LSP may still not be ready for immediate use.
    Certain provisioning operations would need to be performed at each
    node along the path of the LSP before it is deemed operational. By
    adopting the Graceful Setup Procedure for Lambda LSPs, operations
    like "enabling alarm monitoring" and "equalizing power-levels" can
    get executed in the second step.
 
 4. Security Considerations
 
    TBD
 
 5. IANA Considerations
 
    None.
 
 6. Normative References
 
    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
 
 
 
 Beeram, et al           Expires April 20, 2014                 [Page 4]


 Internet-Draft      RSVP Graceful Setup Procedure          October 2013
 
 
                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                 Signaling Resource Reservation Protocol-Traffic
                 Engineering Extensions", RFC 3473, January 2003
 
 7. Acknowledgments
 
    TBD
 
 
 Authors' Addresses
 
    Vishnu Pavan Beeram
    Juniper Networks
    Email: vbeeram@juniper.net
 
    John Drake
    Juniper Networks
    Email: jdrake@juniper.net
 
    Gert Grammel
    Juniper Networks
    Email: ggrammel@juniper.net
 
    Igor Bryskin
    ADVA Optical Networking
    Email: ibryskin@advaoptical.com
 
    Pawel Brzozowski
    ADVA Optical Networking
    Email: pbrzozowski@advaoptical.com
 
    Daniele Ceccarelli
    Ericsson
    Email: daniele.ceccarelli@ericsson.com
 
 
 
 
 
 
 
 
 
 
 
 Beeram, et al           Expires April 20, 2014                 [Page 5]