Skip to main content

Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks
draft-zhang-pce-pcep-stateful-pce-gmpls-01

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 Xian Zhang , Young Lee , Ramon Casellas , Oscar Gonzalez de Dios
Last updated 2012-10-18
Replaced by draft-ietf-pce-pcep-stateful-pce-gmpls, draft-ietf-pce-pcep-stateful-pce-gmpls, RFC 9504
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-zhang-pce-pcep-stateful-pce-gmpls-01
Network Working Group                                         Xian Zhang 
Internet-Draft                                                 Young Lee 
Intended status: Standards Track                                  Huawei 
                                                          Ramon Casellas 
                                                                    CTTC 
                                                  Oscar Gonzalez de Dios 
                                                          Telefonica I+D
                                                                    
                                                    
                                                                  
Expires: April 17, 2013                                 October 18, 2012 
                                      

                                    
   Path Computation Element (PCE) Protocol Extension for Stateful PCE 
                        Usage in GMPLS Networks 
                                      
              draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF 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 17, 2013. 

    

Abstract 
 
 
 
Zhang                    Expires April 2013                   [Page 1] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   The Path Computation Element (PCE) facilitates Traffic Engineering 
   (TE) based path calculation in large, multi-domain, multi-region, or 
   multi-layer networks. PCE can be stateless or stateful. With the LSP 
   state information acquired from the network, a stateful PCE enables 
   a wide variety of applications, especially in GMPLS networks, such 
   as impairment-aware routing and wavelength assignment in wavelength-
   switched optical networks (WSON), time-based scheduling applications. 
   This memo provides extensions required for PCE communication 
   protocol (i.e. PCEP) so as to enable the usage of a stateful PCE 
   capability in GMPLS networks. To be more specific, the PCEP 
   extensions specified in this memo include not only new objects but 
   also modification of existing objects in PCEP messages.  

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 

    
   Table of Contents .............................................. 2 
   1. Introduction ................................................ 3 
   2. PCEP Extensions ............................................. 4 
      2.1. Overview ............................................... 4 
      2.2. PCEP Extension for Stateful PCE Capability Advertisement and 
      Negotiation ................................................. 4 
         2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer 
         Networks ................................................. 5 
      2.3. LSP Delegation ......................................... 5 
      2.4. PCEP Extensions for LSP Synchronization .................6 
      2.5. Modification of Existing PCEP Messages and Procedures....6 
      2.6. Application-specific PCEP extensions for stateful PCE....7 
         2.6.1. Time-based Scheduling.............................. 7 
            2.6.1.1. PCEP Extension................................ 8 
         2.6.2. RWA in Impairment-aware Wavelength-switched Optical 
         Networks (WSON) ......................................... 10 
   3. IANA Considerations ........................................ 11 
      3.1. LayerCapability TLV.................................... 11 
      3.2. SERVICE-TIME Object.................................... 11 
      3.3. Extension to METRIC Object............................. 11 
   4. Manageability Considerations................................ 11 
   5. Security Considerations..................................... 11 
   6. References ................................................. 11 
      6.1. Normative References................................... 11 
      6.2. Informative References................................. 11 
   7. Contributors' Address....................................... 12 
 
 
Zhang                   Expires April 2013                  [Page 2] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   Authors' Addresses ............................................ 13 
    
    

1. Introduction 

   [RFC 4655] presents the architecture of a Path Computation Element 
   (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 
   and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 
   Paths (TE LSPs). To perform such a constrained computation, a PCE 
   stores the network topology (i.e., TE links and nodes) and resource 
   information (i.e., TE attributes) in its TE Database (TED). To 
   request path computation services to a PCE, [RFC 5440] defines the 
   PCE Communication Protocol (PCEP) for communications between a Path 
   Computation Client (PCC) and a PCE, or between two PCEs. A PCC can 
   initiate a path computation request to a PCE through a Path 
   Computation Request (PCReq) message, and then the PCE will return 
   the computed route to the requesting PCC in response to a previously 
   received PCReq message through a PCEP Path Computation Reply (PCRep) 
   message.  

   As per [RFC 4655], a PCE can be stateless or stateful. Compared to a 
   stateless PCE, a stateful PCE stores not only the network state, but 
   also the set of computed paths and reserved resources in use in the 
   network. Note that [RFC4655] further specifies that the TED contains 
   link state and bandwidth availability as distributed by IGPs or 
   collected via other means. Even if such information can provide 
   finer granularity and more details, it is not state information in 
   the PCE context and so a model that uses it is still described as a 
   stateless PCE.  

   Stateful PCE(s) are shown to be helpful in many application 
   scenarios, especially in GMPLS networks, as illustrated in 
   [Stateful-APP]. In order for these applications to able to exploit 
   the capability of stateful PCE(s), extensions to the PCE 
   communication protocol (i.e., PCEP) are required.  

   It is expected that the PCEP extensions enabling stateful PCEs in 
   GMPLS networks will share common aspects with the extensions 
   developed for MPLS networks [Stateful-PCE]. Therefore, this document 
   focuses on the extensions unique to GMPLS networks while maintains a 
   complete picture of the PCEP extensions required for a stateful PCE 
   in general. In summary, this draft gives an overview of PCEP 
   extensions necessary for stateful PCE usage in GMPLS networks as 
   well as the details of required PCEP extension unique to stateful 
   PCE usage in GMPLS networks. 

 
 
Zhang                   Expires April 2013                  [Page 3] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

2. PCEP Extensions  

2.1. Overview 

   According to the description in [Stateful-APP], the PCEP extensions 
   required for a stateful PCE in GMPLS networks should cover, at least, 
   the following two main functional requirements: 

   o Advertisement and negotiation of stateful PCE capability;  

   o LSP synchronization; 

   Attention should be paid in terms of the general considerations as 
   discussed in [Stateful-APP]. Since the extensions to these two 
   aspects are straightforward and have already been covered in 
   [Stateful-PCE], we only cover the points that are either relevant to 
   GMPLS or still missing in [Stateful-PCE].  

   In addition, the next functional requirements   

   o LSP Delegation; 

   As explained in [Stateful-APP], the ability to collect LSP state 
   information should be mandatory. As for PCE's ability to modify the 
   LSP attributes as presented in [Stateful-PCE] as well as how it is 
   enabled (per PCE base, per LSP base, or per NE base?) should be 
   operator-dependent and is for further study.  

   o Application-specific extensions; 

   [Stateful-APP] identifies the applications that a stateful PCE 
   enables. Such applications require PCEP extensions that are provided 
   in this document.  

   Since the LSP state is part of the information that a stateful PCE 
   possesses, some simplifications to PCEP are possible and explained 
   in this draft. 

2.2. PCEP Extension for Stateful PCE Capability Advertisement and 
   Negotiation 

   Whether a PCE has stateful capability or not can be negotiated 
   during the PCEP session establishment process. It can also be 
   advertised through routing protocols as described in [RFC5088]. In 
   either case, the following additional aspects should also be 
   considered. 

 
 
Zhang                   Expires April 2013                  [Page 4] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

 2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer Networks 

   In multi-layer network scenarios where there is a PCE responsible 
   for each layer, then the PCCs should be informed of which PCE they 
   should synchronize their LSP states with as well as send path 
   computation requests to.  

   A new LayerCapability TLV is defined as shown below to denote to 
   which layer a PCE is in charge of LSP synchronization as well as 
   path computation. It can be included in the OPEN Object if 
   applicable. Alternatively, the extension to current OSPF PCED TLV is 
   needed.  

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |       Type (T.B.D.)           |           Length              |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   | LSP Enc. Type | Switching Type|             Reserved          |           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               ...                              |           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | LSP Enc. Type | Switching Type|             Reserved          |           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
2.3. LSP Delegation  

   The LSP state synchronization/update capability for LSPs that span 
   multiple domains adds additional complexity for the stateful PCE(s). 
   For instance, in a multi-domain networks where one PCE per domain is 
   adopted, each PCE is responsible for synchronizing, updating or 
   modifying the segment or part of the LSP within the network for 
   which the PCE is deployed. Moreover, a modification action of a 
   stateful PCE for partial LSP may trigger a chain of LSP updating 
   actions (e.g., informing other PCEs of the modification or 
   requesting other PCEs for additional modification).  

   This needs to be considered carefully and modification capability 
   specifications might be needed to limit the scope of LSP attribute 
   modification action to avoid conflicts. 

   [Editor Note: this needs clarification and further discussion. The 
   scenario with mixed stateful/stateless PCE might also cause 
   potential issues for LSP delegation ability. A use case and clearly 

 
 
Zhang                   Expires April 2013                  [Page 5] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   defined requirements are needed so not to try to cover all possible 
   cases, in view of concrete implementations] 

2.4. PCEP Extensions for LSP Synchronization 

   For LSP state synchronization of stateful PCE(s) in GMPLS networks, 
   the LSP attributes, such as its bandwidth, associated label as well 
   as protection information etc, should be updated by PCC(s) to PCE 
   LSP database (LSP-DB).  

   As per [Stateful-PCE], it only covers LSP attributes pertaining to 
   MPLS networks, based on [RFC5440]. Therefore, extensions of PCEP 
   protocol for stateful PCE usage in GMPLS networks are required. The 
   following presents a list of objects/TLVs that should be used by 
   stateful PCE for LSP synchronization purpose when applied in GMPLS 
   networks: 

   o GENERALIZED BANDWIDTH 

   o PROTECTION ATTRIBUTE  

   o Extended Objects to support the inclusion of label sub-object 

      - RP 

     - IRO 

     - XRO 

   Note that the list above should also be used for path computation 
   requests/replies. Refer to [PCEP-GMPLS] for the details of these 
   objects/TLVs. 

2.5.  Modification of Existing PCEP Messages and Procedures  

   One of the advantages mentioned in [Stateful-APP] is that the 
   stateful nature of a PCE simplifies the information conveyed in PCEP 
   messages, notably between PCC and PCE, since it is possible to refer 
   to PCE managed state for active LSPs. To be more specific, with a 
   stateful PCE, it is possible to refer to a LSP with a unique 
   identifier in the scope of the PCC-PCEP session and thus use such 
   identifier to refer to that LSP.  

   Example 1: a PCC (e.g. NMS) requesting for a re-optimization of one 
   or several LSPs can send the request with ''R'' bit set and only 
   provides the relevant LSP unique identifier(s). 

 
 
Zhang                   Expires April 2013                  [Page 6] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   In order to support these, the LSP identifier TLV defined in 
   [Stateful-PCE] can be used in the RP Object to specify the request 
   LSP ID(s). Upon receiving the PCReq message, PCE should be able to 
   correlate with one or multiple LSPs with their detailed state 
   information and carry out optimization accordingly. The handling of 
   RP object specified in [RFC5440] is stated as following: 

   ''The absence of an RRO in the PCReq message for a non-zero-bandwidth 
   TE LSP (when the R bit of the RP object is set) MUST trigger the 
   sending of a PCErr message with Error-Type="Required Object Missing" 
   and Error-value="RRO Object missing for reoptimization." 

   If a PCE has stateful capabilities, and such capabilities have been 
   negotiated and advertised, specific rules given in [RFC5440] may 
   need to be relaxed. In particular, the re-optimization case: if the 
   re-optimization request refers to a given LSP state, and the RRO 
   information is available, the PCE can proceed. 

   Example 2: in order to set up a LSP which has a constraint that its 
   route should not use resources used by one or more existing LSPs, a 
   PCC can send a PCReq with the identifier(s) of these LSPs. A 
   stateful PCE should be able to find the corresponding route and 
   resource information so as to meet the constraints set by the 
   requesting PCC. Hence, the LSP identifier TLV defined in [Stateful-
   PCE] can be used in XRO object for this purpose.   

2.6.  Application-specific PCEP extensions for stateful PCE  

   [Editor's Note: this is not a complete list of application-specific 
   PCEP extensions. Suggestions are welcome on expansion on this 
   section.] 

 2.6.1. Time-based Scheduling  

   [Editor's note: synchronization is complex and we cannot assume that 
   the PCE and PCC clocks are equal and issues such as whether it 
   should be kept centralized or not will be reflected in the later 
   version.] 

   To support time-based scheduling, network operators need to reserve 
   resources in advance according to customers' requests with specified 
   starting time and duration. A simple utilization example of this 
   service is to support scheduled data transmission between data 
   centers or any generic scheduled based services.  

   Traditionally, this can be supported by NMS operation through path 
   pre-establishment and activation on the agreed starting time. 
   However, this does not provide efficient network usage since the 
 
 
Zhang                   Expires April 2013                  [Page 7] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   established paths exclude the possibility of being used by other 
   services even when they are not used for undertaking any service due 
   to the lack of a time-based mechanism. It can also be accomplished 
   through GMPLS protocol extensions by carrying the related request 
   information (e.g., starting time and duration) across the network. 
   Nevertheless, this method inevitably increases the complexity of 
   signaling and routing process. 

   Since a stateful PCE needs to collect LSP related information for 
   the whole network, it can naturally support this service with 
   resource usage flexibility (i.e., only excluding the time slot(s) 
   reserved for time-based scheduling requests). Moreover, it can avoid 
   the need to add complexity on network elements in this regard. A 
   stateful PCE should also maintain a database that stores all the 
   reserved information with time reference. This can be achieved 
   either by maintaining a separate database or having all the reserved 
   information with time reference incorporated into LSP-DB. The 
   details of organizing time-based scheduling related information are 
   subject to network provider's policy and administrative 
   consideration and thus outside of the scope of this document. 

2.6.1.1. PCEP Extension 

   For a PCC to request a path computation for scheduled service, it 
   MUST be able to specify the time-related information, including the 
   starting time and LSP holding time, in PCEP request.  

   A SERVICE-TIME object is presented as follows to provide the 
   required information (i.e. service starting time and holding time). 

   The Object-Class is TBD and the Object-Type is 1.  

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |       Start-Year              |    Month      |     Day       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |     Hour      |    Minute     |    Second     |   Reserved    |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Duration (in seconds)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
     field      Length       range 

      -----      ------     --------  

 
 
Zhang                   Expires April 2013                  [Page 8] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

     Start-Year  16 bit    0..65536 

     Month       8 bit     1..12 

     Day         8 bit     1..31 

     Hour        8 bit     0..23  

     Minute      8 bit     0..59 

     Second      8 bit     0..59 

   The SERVICE-TIME object can be included in a PCEP request as 
   specified in the following manner: 

   <PCReq Message>::=<Common Header> 

                     [<SVEC-list>] 

                     <request-list> 

   Where: 

      [<svec-list>]::= <SVEC> [<svec-list>] 

     <request-list>::=<request>[<request-list>] 

     <request >::=<RP> 

                  <END-POINTS> 

                  [<LSPA>] 

                  [<BANDWIDTH>]                        

                  [<SERVICE-TIME>]                      

                  [<metric-list>] 

                  [<RRO>[<BANDWIDTH>]] 

                  [<IRO>] 

                  [<LOAD-BALANCING>] 

     WHERE: 

     <metric-list>::=<METRIC>[<metric-list>] 
 
 
Zhang                   Expires April 2013                  [Page 9] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   Upon receiving the PCReq message, PCE should compute the path taking 
   into consideration the constraints of the TED, LSP-DB as well as 
   other scheduled service information and return the computed route 
   back to the requesting PCC. If no path can be found, PCE should 
   return an error message specifying the reason.  

 2.6.2. RWA in Impairment-aware Wavelength-switched Optical Networks 
    (WSON) 

   In impairment-ware WSON networks, the routing and wavelength 
   assignment process needs to consider the constraints incurred by the 
   physical impairments. As described in [Stateful-APP], stateful PCE 
   can effectively reduce the control plane overhead by centrally 
   maintaining the impairment-information related to each LSP. 

   In order to establish an impairment-aware LSP, a path computation 
   request may need to specify the desired values and/or constraints 
   for one or more of the following parameters: 

   o Power 

   o OSNR 

   o PMD  

   o T.B.D. 

   Upon receiving the path computation request, a stateful PCE should 
   take into consideration the explicitly defined constraints as well 
   as those of the existing LSPs, stored in LSP-DB. Furthermore, a PCE 
   may need to reply in PCRep with the actual values of the one or more 
   of the above-mentioned parameters to the requesting PCC as well as 
   the adjustment needed. After receiving the reply message, the PCC 
   can take appropriate actions along the to-be-established paths in 
   tuning its power or changing other impairment-related parameters so 
   as to achieve the desired signal quality.  

   To support the above-mentioned requirements, the METRIC object 
   defined in [RFC5440] can be exploited with proper extension. A new 
   type value should be added. 

   T=T.B.D.: Impairment-aware information 

   Furthermore, as described in [PCE-IA-WSON], there are two types of 
   parameters that can be specified, i.e. path level or link level. If 
   a stateful PCE needs to reply with adjustment needed for path level 
   parameters. Then further extension to the METRIC object is desirable 
   and this will be considered in the future. 
 
 
Zhang                   Expires April 2013                 [Page 10] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

3. IANA Considerations 

   IANA is requested to allocate new Types for the TLV/Object defined 
   in this document. 

3.1. LayerCapability TLV 

3.2. SERVICE-TIME Object 

3.3. Extension to METRIC Object 

4. Manageability Considerations 

   TBD. 

5. Security Considerations 

   TBD. 

6. References 

6.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 
             requirements levels", RFC 2119, March 1997.  

   [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 
             Computation Element (PCE)-Based Architecture", RFC 4655, 
             August 2006. 

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

   [RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R., 
             ''OSPF Protocol Extensions for Path Computation Element 
             (PCE) Discovery'', RFC 5088, April 2008. 

    

6.2. Informative References 

   [Stateful-APP] Zhang, F., Zhang, X., Lee, Y., Casellas, R., Gonzalez 
             de Dios, O., "Applicability of Stateful Path Computation 
             Element (PCE) ", draft-zhang-pce-stateful-pce-app, work in 
             progress. 

 
 
Zhang                   Expires April 2013                 [Page 11] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., ''PCEP 
             Extensions for Stateful PCE'', draft-ietf-pce-stateful-pce, 
             work in progress. 

   [PCE-IA-WSON] Lee, Y., Bernstein G., Takeda, T., Tsuritani, T., 
             ''PCEP Extensions for WSON Impairments'', draft-lee-pce-
             wson-impairments, work in progress. 

   [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., ''PCEP 
             extensions for GMPLS'', draft-ietf-pce-gmpls-pcep-
             extensions, work in progress. 

7. Contributors' Address 

   Dhruv Dhody 
   Huawei Technology 
   Leela Palace 
   Bangalore, Karnataka 560008 
   INDIA 
    
   EMail: dhruvd@huawei.com
    

 
 
Zhang                   Expires April 2013                 [Page 12] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

Authors' Addresses 

   Xian Zhang 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28972913 
   Email: zhang.xian@huawei.com
    
    
   Young Lee 
   Huawei 
   1700 Alma Drive, Suite 100 
   Plano, TX  75075 
   US 
    
   Phone: +1 972 509 5599 x2240 
   Fax:   +1 469 229 5397 
   EMail: ylee@huawei.com
    
    
   Ramon Casellas 
   CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 
   Av. Carl Friedrich Gauss n7 
   Castelldefels, Barcelona 08860 
   Spain 
    
   Phone: 
   Email: ramon.casellas@cttc.es
    
    
   Oscar Gonzalez de Dios  
   Telefonica Investigacion y Desarrollo 
   Emilio Vargas 6 
   Madrid,   28045 
   Spain 
    
   Phone: +34 913374013 
   Email: ogondio@tid.es
 
    
Intellectual Property 
    

 
 
Zhang                   Expires April 2013                 [Page 13] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line 
   IPR   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr@ietf.org. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions 
   of   these Legal Provisions that are published by third parties, 
   including   those that are translated into other languages, should 
   not be   considered to be definitive versions of these Legal 
   Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect 
   and   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

    

Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are 
   provided   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 

 
 
Zhang                   Expires April 2013                 [Page 14] 


draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012 
    

   HE/SHE   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 
   SOCIETY, THE   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 
   DISCLAIM ALL   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 
   LIMITED TO ANY   WARRANTY THAT THE USE OF THE INFORMATION THEREIN 
   WILL NOT INFRINGE   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS   FOR A PARTICULAR PURPOSE. 

 
Full Copyright Statement 
 
   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. 

 
 
Zhang                   Expires April 2013                 [Page 15]