Internet DRAFT - draft-ali-pce-remote-initiated-gmpls-lsp

draft-ali-pce-remote-initiated-gmpls-lsp










     PCE Working Group                                         Zafar Ali 
     Internet Draft                                       Siva Sivabalan 
     Intended status: Standard Track                   Clarence Filsfils 
     Expires: August 13, 2014                              Cisco Systems 
                                                            Robert Varga 
                                                   Pantheon Technologies 
                                                            Victor Lopez 
                                                  Oscar Gonzalez de Dios 
                                                          Telefonica I+D 
                                                              Xian Zhang 
                                                                  Huawei 
                                                       February 14, 2014 
      
                                         
             Path Computation Element Communication Protocol (PCEP) 
                Extensions for remote-initiated GMPLS LSP Setup 
                draft-ali-pce-remote-initiated-gmpls-lsp-03.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 13, 2014. 
      
     Copyright Notice 

     Copyright (c) 2014 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 
      
      
      
     Expires January 2014                                      [Page 1] 
      






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
     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 
     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 

     Draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies 
     procedures that can be used for creation and deletion of PCE-
     initiated LSPs in the active stateful PCE model. However, this 
     specification focuses on MPLS networks, and does not cover remote 
     instantiation of paths in GMPLS-controlled networks. This document 
     complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by addressing 
     the requirements for remote-initiated GMPLS LSPs.  

      
     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 .............................................3 
        2. Requirements for Remote-Initiated GMPLS LSPs .............3 
        3. PCEP Extensions for Remote-Initiated GMPLS LSPs ..........4 
          3.1. Generalized Endpoint in LSP Initiate Message .........4 
          3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message .5 
          3.3. Protection Attributes in LSP Initiate Message ........5 
          3.4. ERO in LSP Initiate Object ...........................5 
              3.4.1. ERO with explicit label control ................5 
              3.4.2. ERO with Path Keys .............................6 
              3.4.3. Switch Layer Object ............................6 
          3.5. LSP delegation and cleanup ...........................7 
        4. Security Considerations ..................................7 
        5. IANA Considerations ......................................7 
          5.1. PCEP-Error Object ....................................7 
        6. Acknowledgments ..........................................7 
        7. References ...............................................7 
          7.1. Normative References .................................7 
                        Expires August 2014                  [Page 2] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
          7.2. Informative References ...............................8 
         
     1. Introduction 

        The Path Computation Element communication Protocol (PCEP) 
        provides mechanisms for Path Computation Elements (PCEs) to 
        perform route computations in response to Path Computation 
        Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP 
        Setup in a Stateful PCE Model draft [I-D. draft-ietf-pce-
        stateful-pce] describes a set of extensions to PCEP to enable 
        active control of MPLS-TE and GMPLS network.  

        [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup 
        and teardown of PCE-initiated LSPs under the active stateful PCE 
        model, without the need for local configuration on the PCC. This 
        enables realization of a dynamic network that is centrally 
        controlled and deployed. However, this specification is focused 
        on MPLS networks, and does not cover the GMPLS networks (e.g., 
        WSON, OTN, SONET/ SDH, etc. technologies). This document 
        complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by 
        addressing the requirements for remote-initiated GMPLS LSPs. 
        These requirements are covered in Section 2 of this draft. The 
        PCEP extensions for remote initiated GMPLS LSPs are specified in 
        Section 3.  

     2. Requirements for Remote-Initiated GMPLS LSPs 

        [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures 
        that can be used for creation and deletion of PCE-initiated LSPs 
        under the active stateful PCE model. However, this specification 
        does not address GMPLS requirements outlined in the following: 

        -  GMPLS support multiple switching capabilities on per TE link 
          basis. GMPLS LSP creation requires knowledge of LSP switching 
          capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 
          [RFC3471], [RFC3473].  

        -  GMPLS LSP creation requires knowledge of the encoding type 
          (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) 
          to be used by the LSP [RFC3471], [RFC3473].  

        -  GMPLS LSP creation requires information of the generalized 
          payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473].  

        -  GMPLS LSP creation requires specification of data flow 
          specific traffic parameters (also known as Tspec), which are 
          technology specific.  

                        Expires August 2014                  [Page 3] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        -  GMPLS also specifics support for asymmetric bandwidth 
          requests [RFC6387].  

        -  GMPLS extends the addressing to include unnumbered interface 
          identifiers, as defined in [RFC3477].  

        -  In some technologies path calculation is tightly coupled with 
          label selection along the route. For example, path calculation 
          in a WDM network may include lambda continuity and/ or lambda 
          feasibility constraints and hence a path computed by the PCE 
          is associated with a specific lambda (label). Hence, in such 
          networks, the label information needs to be provided to a PCC 
          in order for a PCE to initiate GMPLS LSPs under the active 
          stateful PCE model. I.e., explicit label control may be 
          required.  

        -  GMPLS specifics protection context for the LSP, as defined in 
          [RFC4872] and [RFC4873].  

     3. PCEP Extensions for Remote-Initiated GMPLS LSPs 

        LSP initiate (PCInitiate) message defined in [I-D. draft-crabbe-
        pce-pce-initiated-lsp] needs to be extended to include GMPLS 
        specific PCEP objects as follows:  

     3.1. Generalized Endpoint in LSP Initiate Message 

        This document does not modify the usage of END-POINTS object for 
        PCE initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage as specified below.  

        END-POINTS object has been extended by [I-D. draft-ietf-pcep-
        gmpls-ext] to include a new object type called "Generalized 
        Endpoint". PCInitiate message sent by a PCE to a PCC to trigger 
        a GMPLS LSP instantiation SHOULD include the END-POINTS with 
        Generalized Endpoint object type. Furthermore, the END-POINTS 
        object MUST contain "label request" TLV. The label request TLV 
        is used to specify the switching type, encoding type and GPID of 
        the LSP being instantiated by the PCE.  

        The unnumbered endpoint TLV can be used to specify unnumbered 
        endpoint addresses for the LSP being instantiated by the PCE. 
        The END-POINTS MAY contain other TLVs defined in [I-D. draft-
        ietf-pcep-gmpls-ext].  

        If the END-POINTS Object of type Generalized Endpoint is missing 
        the label request TLV, the PCC MUST send a PCErr message with 
        Error-type=6 (Mandatory Object missing) and Error-value= TBA 
        (LSP request TLV missing). 

        If the PCC does not support the END-POINTS Object of type 
        Generalized Endpoint, the PCC MUST send a PCErr message with 
                        Expires August 2014                  [Page 4] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        Error-type = 3 (Unknown Object), Error-value = 2(unknown object 
        type).  

     3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 

           LSP initiate message defined in [I-D. draft-crabbe-pce-pce-
        initiated-lsp] can optionally include the BANDWIDTH object. 
        However, the following possibilities cannot be represented in 
        the BANDWIDTH object: 

           - Asymmetric bandwidth (different bandwidth in forward and 
        reverse direction), as described in [RFC6387]. 

           - Technology specific GMPLS parameters (e.g., Tspec for 
        SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 

        GENERALIZED-BANDWIDTH object has been defined in [I-D. draft-
        ietf-pcep-gmpls-ext] to address the above-mentioned limitation 
        of the BANDWIDTH object.  

        This document specifies the use of GENERALIZED-BANDWIDTH object 
        in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH 
        object MAY be included in the PCInitiate message. The 
        GENERALIZED-BANDWIDTH object in PCInitiate message is used to 
        specify technology specific Tspec and asymmetrical bandwidth 
        values for the LSP being instantiated by the PCE.  

     3.3. Protection Attributes in LSP Initiate Message 

        This document does not modify the usage of LSPA object for PCE 
        initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage of LSPA object in LSP 
        Initiate Message to carry the end-to-end protection context this 
        also includes the protection state information.  

        The LSP Protection Information TLV of LSPA in the PCInitiate 
        message can be used to specify protection attributes of the LSP 
        being instantiated by the PCE.  

     3.4. ERO in LSP Initiate Object  

        This document does not modify the usage of ERO object for PCE 
        initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage as specified in the 
        following sections. 

     3.4.1. ERO with explicit label control  

        As mentioned earlier, there are technologies and scenarios where 
        active stateful PCE requires explicit label control in order to 
        instantiate an LSP.  

                        Expires August 2014                  [Page 5] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        Explicit label control (ELC) is a procedure supported by RSVP-
        TE, where the outgoing label(s) is (are) encoded in the ERO. [I-
        D. draft-ietf-pcep-gmpls-ext] extends the <ERO> object of PCEP 
        to include explicit label control. The ELC procedure enables the 
        PCE to provide such label(s) directly in the path ERO.  

        The extended ERO object in PCInitiate message can be used to 
        specify label along with ERO to PCC for the LSP being 
        instantiated by the active stateful PCE.  

     3.4.2. ERO with Path Keys 

        There are many scenarios in packet and optical networks where 
        the route information of an LSP may not be provided to the PCC 
        for confidentiality reasons.  A multi-domain or multi-layer 
        network is an example of such networks. Similarly, a GMPLS User-
        Network Interface (UNI) [RFC4208] is also an example of such 
        networks.  

        In such scenarios, ERO containing the entire route cannot be 
        provided to PCC (by PCE). Instead, PCE provides an ERO with Path 
        Keys to the PCC. For example, in the case UNI interface between 
        the router and the optical nodes, the ERO in the LSP Initiate 
        Message may be constructed as follows:  

       - The first hop is a strict hop that provides the egress 
          interface information at PCC. This interface information is 
          used to get to a network node that can extend the rest of the 
          ERO. (Please note that in the cases where the network node is 
          not directly connected with the PCC, this part of ERO may 
          consist of multiple hops and may be loose).  
       - The following(s) hop in the ERO may provide the network node 
          with the path key [RFC5520] that can be resolved to get the 
          contents of the route towards the destination.  
       - There may be further hops but these hops may also be encoded 
          with the path keys (if needed).  
        
       This document does not change encoding or processing roles for 
       the path keys, which are defined in [RFC5520].  

     3.4.3. Switch Layer Object 

        [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER 
        object which defines and specifies the switching layer (or 
        layers) in which a path MUST or MUST NOT be established. A   
        switching layer is expressed as a switching type and encoding 
        type. [I-D. draft-ietf-pcep-gmpls-ext], which defines the GMPLS 

                        Expires August 2014                  [Page 6] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        extensions for PCEP, suggests using the SWITCH-LAYER object. 
        Thus, SWITCH-LAYER object can be used in the PCInitiate message 
        to specify the switching layer (or layers) of the LSP being 
        remotely initiated. 

     3.5. LSP delegation and cleanup 

        LSP delegation and cleanup procedure specified in [I-D. draft-
        ietf-pcep-gmpls-ext] are equally applicable to GMPLS LSPs and 
        this document does not modify the associated usage.  

     4. Security Considerations 

        To be added in future revision of this document.  

     5. IANA Considerations 

     5.1. PCEP-Error Object  

        This document defines the following new Error-Value: 

        Error-Type  Error Value 

        6           Error-value=TBA:  LSP Request TLV missing 

     6. Acknowledgments 

        The authors would like to thank George Swallow and Jan Medved 
        for their comments. 
          
     7. References 

       
     7.1. Normative References 

         [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate                
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 

         [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, 
                  I., Sivabalan, S., Varga, R., "PCEP Extensions for 
                  PCE-initiated LSP Setup in a Stateful PCE Model", 
                  draft-crabbe-pce-pce-initiated-lsp, work in progress.  

         [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 
                  Computation Element (PCE) Communication Protocol 
                  (PCEP)", RFC 5440, March 2009. 

         [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 
                  "Framework for PCE-Based Inter-Layer MPLS and GMPLS 
                  Traffic Engineering", RFC 5623, September 2009. 

                        Expires August 2014                  [Page 7] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 
                  for Dynamically Signaled Hierarchical Label Switched 
                  Paths", RFC 6107, February 2011. 

     7.2. Informative References 

         [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 
                  Switching (GMPLS) Signaling Functional Description", 
                  RFC 3471, January 2003. 

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

        [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 
                  Links in Resource ReSerVation Protocol - Traffic 
                  Engineering (RSVP-TE)", RFC 3477, January 2003.  

      
        [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 
                  Ed., "RSVP-TE Extensions in Support of End-to-End 
                  Generalized Multi-Protocol Label Switching (GMPLS) 
                  Recovery", RFC 4872, May 2007.  

        [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 
                  Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.  

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

        [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 
                  "Preserving Topology Confidentiality in Inter-Domain 
                  Path Computation Using a Path-Key-Based Mechanism", 
                  RFC 5520, April 2009. 

     Author's Addresses 

         
        Zafar Ali 
        Cisco Systems 
        Email: zali@cisco.com 
      
        Siva Sivabalan 
        Cisco Systems 
        Email: msiva@cisco.com 
         
        Clarence Filsfils  

                        Expires August 2014                  [Page 8] 






     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 
      
        Cisco Systems 
        Email: cfilsfil@cisco.com 
      

        Robert Varga 
        Pantheon Technologies 
         
        Victor Lopez 
        Telefonica I+D 
        Email: vlopez@tid.es 
         
        Oscar Gonzalez de Dios  
        Telefonica I+D  
        Email: ogondio@tid.es 
      
        Xian Zhang 
        Huawei Technologies 
        Email: zhang.xian@huawei.com 
         
      































                        Expires August 2014                  [Page 9]