Skip to main content

Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup
draft-ali-pce-remote-initiated-gmpls-lsp-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 "Replaced".
Authors Zafar Ali , Siva Sivabalan , Clarence Filsfils , Victor Lopez , Oscar Gonzalez de Dios
Last updated 2013-01-31
Replaced by draft-ietf-pce-remote-initiated-gmpls-lsp
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-ali-pce-remote-initiated-gmpls-lsp-00
PCE Working Group                                         Zafar Ali 
     Internet Draft                                       Siva Sivabalan 
     Intended status: Standard Track                   Clarence Filsfils 
     Expires: July 31, 2013                               Cisco Systems 
                                                         
                                                            Robert Varga 
                                                   Pantheon Technologies 
      
                                                            Victor Lopez 
                                                  Oscar Gonzalez de Dios 
                                                          Telefonica I+D 
                                                                                     
                                                        February 1, 2013  
      
                                         
             Path Computation Element Communication Protocol (PCEP) 
                Extensions for remote-initiated GMPLS LSP Setup 
                draft-ali-pce-remote-initiated-gmpls-lsp-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 July 31, 2013. 
      
     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 
      
      
      
     Expires July 2013                                        [Page 1] 
      


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

     PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 
     draft [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 is focused on MPLS networks, and does not cover 
     remote instantiation of GMPLS paths.  This document complements 
     PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 
     draft by addressing the extensions required for GMPLS applications, 
     for example for OTN and WSON networks.  

     When active stateful PCE is used for managing PCE-initiated LSP, 
     PCC may not be aware of the intended usage of the LSP (e.g., in a 
     multi-layer network). PCEP Extensions for PCE-initiated LSP Setup 
     in a Stateful PCE Model draft does not address this requirement. 
     This draft also addresses the requirement to specify on how PCC 
     should use the PCEP initiated 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. Use Cases................................................. 4 
          2.1. Single-layer provisioning from Active stateful PCE.... 4 
          2.2. Bandwidth-on-demand for multi-layer networks.......... 5 
          2.3. Higher-layer signaling trigger........................ 6 
          2.4. NMS-VNTM cooperation model (separated flavor)......... 7 
                            Expires July 2013     [Page 2] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        3. GMPLS Requirements for Remote-Initiated LSPs.............. 9 
        4. Remote Initiated LSP Usage Requirement.................... 9 
        5. PCEP Extensions for Remote-Initiated GMPLS LSPs.......... 10 
          5.1. Generalized Endpoint in LSP Create Message........... 10 
          5.2. GENERALIZED-BANDWIDTH object in LSP Create Message... 11 
          5.3. Protection Attributes in LSP Create Message.......... 11 
          5.4. ERO in LSP Create Object............................. 12 
              5.4.1. ERO with explicit label control................ 12 
              5.4.2. ERO with Path Keys............................. 12 
              5.4.3. Switch Layer Object ............................13 
        6. PCEP extension for PCEP Initiated LSP Usage Specification.13 
          6.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Create Message. 13 
          6.2. Communicating LSP usage to Egress node............... 15 
          6.3. LSP delegation and cleanup ...........................15 
        7. Security Considerations.................................. 15 
        8. IANA Considerations.......................................15 
          8.1. END-POINT Object......................................15 
          8.2. PCEP-Error Object.....................................16 
        9. Acknowledgments...........................................16 
        10. References...............................................16 
          10.1. Normative References.................................16 
          10.2. Informative References...............................16 
         
     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 tunnels.  

        [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, thus 
        allowing for 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). GMPLS requirements for PCEP 
        initiated LSPs are outlined in Section 3. This document 
        complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by 
        addressing the requirements for remote-initiated GMPLS LSPs. The 
        PCEP extensions for PCEP initiated GMPLS LSPs are specified in 
        Section 5. The mechanism described in this document is 
        applicable not only to active PCEs initiating LSPs, but to any 
        entity that initiates LSPs remotely. 

                            Expires July 2013     [Page 3] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        When an active stateful PCE is used for managing remote-
        initiated LSP, the PCC may not be aware of the intended usage of 
        the remote-initiated LSP. For example, the PCC may not know the 
        target IGP instance in which the remote-initiated LSP is to be 
        used. These requirements are outlined in Section 4. [RFC6107] 
        defines LSP_TUNNEL_INTERFACE_ID Object for communicating target 
        IGP instance and usage of the forwarding and/ or routing 
        adjacency from the ingress node to the egress node. However, 
        current PCEP specifications do not include signaling of the 
        LSP_TUNNEL_INTERFACE_ID TLV in the PCEP message. Furthermore, 
        [I-D. draft-crabbe-pce-pce-initiated-lsp] does not address this 
        requirement. This draft also addresses the requirement to 
        specify on how PCC should use the PCEP initiated LSPs. This is 
        achieved by using LSP_TUNNEL_INTERFACE_ID Object defined in 
        [RFC6107] in PCEP, as detailed in Section 6.  

     2. Use Cases 

     2.1. Single-layer provisioning from active stateful PCE 

        Figure 1 shows a single-layer topology with optical nodes with a 
        GMPLS control plane. In this scenario, the active PCE can 
        dynamically create or delete L0 services between client 
        interfaces. This process can be triggered by the deployment of a 
        new network configuration or a re-optimization process. This 
        operation can be human-driven (e.g. through an NMS) or an 
        automatic process.  

         

        [Please refer to pdf version for the Figure]
        Figure 1. Single-layer provisioning from active stateful PCE.  

                            Expires July 2013     [Page 4] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        L0 PCE obtains resources information via control plane 
        collecting LSAs messages. The request contains, at least, two 
        optical transport interfaces (OT i/f), so PCE computes the path 
        and sends a message to the optical equipment with ERO path 
        information. 

         

     2.2. Bandwidth-on-demand for multi-layer networks 

        This use case assumes there is a multi-layer network composed by 
        routers and optical equipment. In this scenario, there is an 
        entity, which decides it needs extra bandwidth between two 
        routers. This certain moment a GMPLS LSP connecting both routers 
        via the optical network can be established on-the-fly. This 
        entity can be a router, an active stateful PCE or even the NMS 
        (with or without human intervention). 

        It is important to note that the bandwidth-on-demand interfaces 
        and spare bandwidth in the optical network could be shared to 
        cover many under capacity scenarios in the L3 network. For 
        example, in this use-case, if we assume all interfaces are 10G 
        and there is 10G of spare bandwidth available in the optical 
        network, the spare bandwidth in the optical network can be used 
        to connect any router, depending on bandwidth demand of the 
        router network. For example, if there are three routers, it is 
        not known a priori if the demand will make bandwidth-on-demand 
        interface at R1 to be connected to bandwidth-on-demand interface 
        at R2 or R3. For this reason, bandwidth-on-demand interfaces 
        cannot be pre-provisioned with the IP services that are expected 
        to carry.  

        According to [RFC5623], there are four options of Inter-Layer 
        Path Computation and Inter-Layer Path Control Models: (1) PCE-
        VNTM cooperation, (2) Higher-layer signaling trigger, (3) NMS-
        VNTM cooperation model (integrated flavor) and (4) NMS-VNTM 
        cooperation model (separated flavor). In all scenarios there is 
        a certain moment when entities are using an interface to request 
        for a path provisioning. In this document we have selected two 
        use cases in a scenario with routers and optical equipment to 
        obtain the requirements for this draft, but it is applicable to 
        the four options. 

         

         

         

         

         
                            Expires July 2013     [Page 5] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      

        [Please refer to pdf version for the Figure]      

        Figure 2. Use case higher-layer signaling trigger 

     2.3. Higher-layer signaling trigger 

        Figure 2 depicts a multi-layer network scenario similar to the 
        presented in section 4.2.2. [RFC5623], with the difference that 
        PCE is an active stateful PCE [I-D. draft-ietf-pce-stateful-
        pce]. 

        In this example, O1, O2 and O3 are optical nodes that are 
        connected with router nodes R1, R2 and R3, respectively. The 
        network is designed such that the interface between R1-O1, R2-O2 
        and R3-O3 are setup to provide bandwidth-on-demand via the 
        optical network.  

        The example assumes that an active stateful PCE is used for 
        setting and tearing down bandwidth-on-demand connectivity. 
        Although the simple use-case assumes a single PCE server (PCE1), 
        the proposed technique is generalized to cover multiple co-
        operating PCE case. Similarly, although the use case assumes 
        PCE1 only has knowledge of the L3 topology, the proposed 
        technique is generalized to cover multi-layer PCE case.   

        The PCE server (PCE1) is assumed to be receiving L3 topology 
        data. It is also assumed that PCE learns L0 (optical) addresses 
        associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and 
        R3-O3. These addresses are referred by OTE-IP-R1 (optical TE 
                            Expires July 2013     [Page 6] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2 
        address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at 
        R3), respectively. How PCE learns the optical addresses 
        associated with the bandwidth-on-demand interfaces is beyond the 
        scope of this document.  

        How knowledge of the bandwidth-on-demand interfaces is utilized 
        by the PCE is exemplified in the following. Suppose an 
        application requests 8 Gbps from R1 to R2 (recall all interfaces 
        in Figure 1 are assumed to be 10G). PCE1 satisfies this by 
        establishing a tunnel using R1-R4-R2 path. PCEP initiated LSP 
        using techniques specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp] can be used to establish a PSC tunnel using the 
        R1-R4-R2 path. Now assume another application requests 7 Gbps 
        service between R1 and R2. This request cannot be satisfied 
        without establishing a GMPLS tunnel via optical network using 
        bandwidth-on-demand interfaces. In this case, PCE1 initiates a 
        GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS 
        tunnel1 in the following). The PCEP initiated LSP using 
        techniques specified in document are used for this purpose.  

        As mentioned earlier, the GMPLS tunnel created on-the-fly to 
        satisfy bandwidth demand of L3 applications cannot be pre-
        provisioned in IP network, as bandwidth-on-demand interfaces and 
        spare bandwidth in the optical network are shared. Furthermore, 
        in this example, as active stateful PCE is used for managing 
        PCE-initiated LSP, PCC may not be aware of the intended usage of 
        the PCE-initiated LSP. Specifically, when the PCE1 initiated 
        GMPLS tunnel1, PCC does not know the IGP instance whose demand 
        leads to establishment of the GMPLS tunnel1 and hence does not 
        know the IGP instance in which the GMPLS tunnel1 needs to be 
        advertised. Similarly, the PCC does not know IP address that 
        should be assigned to the GMPLS tunnel1. In the above example, 
        this IP address is labeled as TUN-IP-R1 (tunnel IP address at 
        R1). The PCC also does not know if the tunnel needs to be 
        advertised as forwarding and/ or routing adjacency and/or to be 
        locally used by the target IGP instance. Similarly, egress node 
        for GMPLS signaling (R2 node in this example) may not know the 
        intended usage of the tunnel (tunnel1 in this example). For 
        example, the R2 node does not know IP address that should be 
        assigned to the GMPLS tunnel1. In the above example, this IP 
        address is labeled as TUN-IP-R2 (tunnel IP address at R2). 
        Section 6 of this draft addresses the requirement to specify on 
        how PCC and egress node for signaling should use the PCEP 
        initiated LSPs.  

     2.4. NMS-VNTM cooperation model (separated flavor) 

        Figure 3 depicts NMS-VNTM cooperation model. This is the 
        separated flavor, because NMS and VNTM are not in the same 
        location. 

                            Expires July 2013     [Page 7] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        A new L3 path is requested from NMS, because there is an 
        automated process in the NMS or after human intervention. NMS 
        does not have information about all network information, so it 
        consults L3 PCE. For shake of simplicity L3-PCE is used, but any 
        other multi-layer cooperating PCE model is applicable. In case 
        that there are enough resources in the L3 layer, L3-PCE returns 
        a L3 only path. On the other hand, if there is a lack of 
        resources at the L3 layer, the response does not have any path 
        or may contain a multilayer path with L3 and L0 (optical) 
        information in case of a ML-PCE. In case of there is not a path 
        in L3; NMS sends a message to the VNTM to create a GMPLS LSP in 
        the lower layer. When the VNTM receives this message, based on 
        the local policies, accepts the suggestion and sends a similar 
        message to the router, which can create the lower layer LSP via 
        UNI signaling in the routers, like in use case in section 2.3.1. 
        Similarly, VNTM may talk with L0-PCE to set-up the path in the 
        optical domain (section 2.2). This second option looks more 
        complex, because it requires VNTM configuring inter-layer TE-
        links.   

        Requirements for the message from VNTM to the router are the 
        same than in the previous use case (section 2.3.1). Regarding 
        NMS to VNTM message, the requirements here depends on who has 
        all the information. Three different addresses are required in 
        this use case: (1) L3, (2) L0 and (3) inter-layer addressing. In 
        case there is a non-cooperating L3-PCE, information about inter-
        layer connections have to be stored (or discovered) by VNTM. If 
        there is a ML-PCE and this information is obtained from the 
        network, the message would be the same than in section 2.3.1. 

                            Expires July 2013     [Page 8] 
                                                  


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        [Please refer to pdf version for the Figure]   

        Figure 3. Use case NMS-VNTM cooperation model 

         

     3. GMPLS Requirements for Remote-Initiated 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.  

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

     4. Remote Initiated LSP Usage Requirement 

        The requirement to specify usage of the LSP to the PCC includes 
        but not limited to specification of the following information.  
                            Expires July 2013     [Page 9] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        -  The target IGP instance for the Remote-initiated LSP needs to 
          be specified.  

        -  In the target IGP instance, should the PCE-initiated LSP be 
          advertised as a forwarding adjacency and/ or routing adjacency 
          and/ or to be used locally by the PCC?   

        -  Should the as Remote-initiated LSP be advertised an IPv4 FA/ 
          RA, IPv6 FA/ RA or as unnumbered FA/ RA.  

        -  If Remote-initiated LSP is to be advertised an IPv4 FA/ RA, 
          IPv6 FA/ RA, what is the local and remote IP address is to be 
          used for the advertisement.  

     5. PCEP Extensions for Remote-Initiated GMPLS LSPs 

        Section 3 outlines GMPLS and application requirements that need 
        to be satisfied in order for a PCE to initiate GMPLS LSPs under 
        the active stateful PCE model. The section provides PCEP 
        protocol extensions required to meet these requirements.  

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

     5.1. Generalized Endpoint in LSP Create 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''. PCCreate 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.  

        As mentioned earlier, the PCE server is assumed to be receiving 
        topology data. In the use case of higher-layer signaling 
        trigger, the addresses associated with bandwidth-on-demand 
        interfaces are included, e.g., OTE-IP-R1, OTE-IP-R2 and OTE-IP-
        R3, in the use case example. These addresses and R1, R2 and R3 
        router IDs are used to derive source and destination address of 
        the END-POINT object. As previously mentioned, in the case of 
        NMS-VNMT cooperation model with L3 PCE, VNTM must receive such 
        inter-layer interface association to configure the whole path. 

        The unnumbered endpoint TLV can be used to specify unnumbered 
        endpoint addresses for the LSP being instantiated by the PCE. 
                            Expires July 2013     [Page 10] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        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 
        Error-type= TBA and Error-value= TBA. [may be already defined].

     5.2. GENERALIZED-BANDWIDTH object in LSP Create Message 

        LSP create 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 PCCreate message. Specifically, GENERALIZED-BANDWIDTH object 
        MAY be included in the PCCreate message. The GENERALIZED-
        BANDWIDTH object in PCCreate message is used to specify 
        technology specific Tspec and asymmetrical bandwidth values for 
        the LSP being instantiated by the PCE.  

     5.3. Protection Attributes in LSP Create 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 
        Create 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 PCCreate 
        message can be used to specify protection attributes of the LSP 
        being instantiated by the PCE.  

                            Expires July 2013     [Page 11] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
     5.4. ERO in LSP Create 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. 

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

        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 PCCreate message can be used to 
        specify label along with ERO to PCC for the LSP being 
        instantiated by the active stateful PCE.  

     5.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 Create 
        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.  

                            Expires July 2013     [Page 12] 


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

         

     5.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 
        extensions for PCEP, suggests using the SWITCH-LAYER object. 
        Thus, SWITCH-LAYER object can be used in the PCCreate message to 
        specify the switching layer (or layers) of the LSP being 
        remotely initiated. 

        

     6. PCEP extension for PCEP Initiated LSP Usage Specification 

        The requirement to specify on how PCC should use the PCEP 
        initiated LSPs in outlined in Section 4. This subsection 
        specifies PCEP extension used to satisfy this requirement.  

        PCEP extensions specified in this section are equally applicable 
        to PCEP initiated MPLS as well as GMPLS LSPs.  

     6.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Create Message 

        [RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for 
        communicating usage of the forwarding or routing adjacency from 
        the ingress node to the egress node. This document extends the 
        LSP Create Message to include LSP_TUNNEL_INTERFACE_ID object 
        defined in [RFC6107]. Object class and type for the 
        LSP_TUNNEL_INTERFACE_ID object are as follows:  

        Object Name: LSP_TUNNEL_INTERFACE_ID 

        Object-Class Value: TBA by Iana (suggested value: 40)  

        Object-type: 1 

        The contents of this object are identical in encoding to the 
        contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined 
        in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE 
        LSP_TUNNEL_INTERFACE_ID object are acceptable in this object. 
                            Expires July 2013     [Page 13] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond 
        to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please 
        note that use of TLV type 1 defined in [RFC3477] is not 
        specified by this document.  

        TLV   TLV 
        Type  Description                                     Reference 
        --  ------------------------------------------------- ---------- 
        2  IPv4 interface identifier with target IGP instance [RFC6107] 

        3  IPv6 interface identifier with target IGP instance [RFC6107] 

        4  Unnumbered interface with target IGP instance      [RFC6107] 

        The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID 
        object are identical to those defined for the RSVP-TE 
        LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the 
        fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV 
        are identical to those defined for the corresponding RSVP-TE 
        LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have 
        slightly different usage.  

       -  IPv4 Interface Address field in IPv4 interface identifier 
          with target IGP instance TLV: This field indicates the local 
          IPv4 address to be assigned to the tunnel at the PCC (ingress 
          node for RSVP-TE signaling). In the example use case of 
          Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is 
          carried in this field (if TUN-IP-R1 is a v4 address).  

       -  IPv6 Interface Address field in IPv4 interface identifier 
          with target IGP instance TLV: This field indicates the local 
          IPv6 address to be assigned to the tunnel at the PCC (ingress 
          node for RSVP-TE signaling). In the example use case of 
          Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is 
          carried in this field (if TUN-IP-R1 is a v6 address).  

       -  LSR's Router ID field in Unnumbered interface with target IGP 
          instance: The PCC SHOULD use the LSR's Router ID in Unnumbered 
          interface with target IGP instance in advertising the LSP 
          being initiated by the PCE. In the example use case of Section 
          2, this field carries router-id of R1 in the target IGP 
          instance.  

       -  Interface ID (32 bits) field in unnumbered interface with 
          target IGP instance: All bits of this field MUST be set to 0 
          by the PCE server and MUST be ignored by PCC. PCC SHOULD 
          allocate an Interface ID that fulfills Interface ID 
          requirements specified in [RFC3477].  

        When the Ingress PCC receives an LPS Request Message with 
        LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained 
        in the TLV to drive the IGP instance, treatment of the LSP being 
                            Expires July 2013     [Page 14] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        initiated in the target IGP instance (e.g., FA, RA or local 
        usage), the local IPv4 or IPv6 address or router-id for 
        unnumbered case to be used for advertisement of the LSP being 
        instantiated.  

     6.2. Communicating LSP usage to Egress node 

        PCE does not need to send LSP Create message to egress node 
        (node R2 in the example of section 2) to communicate LSP usage 
        information. Instead PCC (Ingres signaling node) uses RSVP-TE 
        signaling mechanism specified in [RFC6107] to send the LSP usage 
        to Egress node. Specifically, when the Ingress PCC receives an 
        LPS Request Message with LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD 
        add LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For 
        this purpose, it is RECOMMENDED that the ingress PCC uses 
        content of the LSP_TUNNEL_INTERFACE_ID TLV in LSP Create Message 
        in PCEP to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This 
        document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object 
        in RSVP-TE signaling as specified in [RFC6107].  

        The egress node uses information contained in the 
        LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive 
        the IGP instance, treatment of the LSP being initiated in the 
        target IGP instance (e.g., FA, RA or local usage), the local 
        IPv4 or IPv6 address or router-id for unnumbered case to be used 
        for advertisement of the LSP being instantiated.  

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

     7. Security Considerations 

        To be added in future revision of this document.  

     8. IANA Considerations 

     8.1. END-POINT Object  

        This document extends the LSP Create Message to include 
        LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object 
        class and type for the LSP_TUNNEL_INTERFACE_ID object are as 
        follows:  

        Name                       Class value                      Type   
        ----                       -----------                      ----   
        LSP_TUNNEL_INTERFACE_ID    TBA by Iana (Suggested:40)        1 

                            Expires July 2013     [Page 15] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
     8.2. PCEP-Error Object  

        This document defines the following new Error-Value: 

        Error-Type  Error Value 

        6           Error-value=TBA:  LSP Request TLV missing 

     9. Acknowledgments 

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

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

        [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 
                  for Dynamically Signaled Hierarchical Label Switched 
                  Paths", RFC 6107, February 2011. 

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

                            Expires July 2013     [Page 16] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        [RFC 5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and 
                  J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional 
                  Label Switched Paths (LSPs)", RFC 5467, March 2009.  

         

        [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, July 2009.  

      

         

     Authors' Addresses 

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

                            Expires July 2013     [Page 17] 


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-00.txt 
      
        Robert Varga 
        Pantheon Technologies 
         
        Victor Lopez 
        Telefonica I+D 
        Email: vlopez@tid.es 
         
        Oscar Gonzalez de Dios  
        Telefonica I+D  
        Email: ogondio@tid.es 
      
      

                            Expires July 2013     [Page 18]