Skip to main content

Document:
draft-ietf-pce-gmpls-aps-req-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7025.
Authors Diego Caviglia , Fatai Zhang , Kenichi Ogaki , Tomohiro Otani
Last updated 2012-01-05 (Latest revision 2011-06-08)
Replaces draft-otani-pce-gmpls-aps-req
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7025 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pce-gmpls-aps-req-05
Network Working Group                                    Tomohiro Otani 
Internet-Draft                                                     KDDI 
Intended status: Informational                            Kenichi Ogaki 
                                                          KDDI R&D Labs 
                                                         Diego Caviglia 
                                                               Ericsson 
                                                            Fatai Zhang 
                                                                 Huawei 
Expires: July 06, 2012                                 January 06, 2012 
                                      

                                    
               Requirements for GMPLS applications of PCE  
                                      
               Document: draft-ietf-pce-gmpls-aps-req-05.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 July 06, 2012. 

    

Abstract 

   The initial effort of PCE WG is specifically focused on MPLS (Multi-
   protocol label switching). As a next step, this draft describes 
 
 
 
T. Otani et al.           Expires July 2012                   [Page 1] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   functional requirements for GMPLS (Generalized MPLS) application of 
   PCE (Path computation element).  

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [RFC2119]. 

Table of Contents 

   1. Introduction ................................................. 2 
   2. Terminology .................................................. 3 
   3. GMPLS applications of PCE..................................... 3 
      3.1. GMPLS network model...................................... 3 
      3.2. Path computation in GMPLS network ........................4 
      3.3. Unnumbered Interfaces.................................... 6 
      3.4. Asymmetric Bandwidth Path Computation ................... 6 
   4. Requirements for GMPLS application of PCE .................... 6 
      4.1. Requirements of Path Computation Request ................ 6 
      4.2. Requirements of Path Computation Reply .................. 8 
      4.3. GMPLS PCE Management..................................... 9 
   5. Security consideration........................................ 9 
   6. IANA Considerations .......................................... 9 
   7. Acknowledgement .............................................. 9 
   8. References ................................................... 9 
   9. Authors' Addresses ........................................... 12 
    
1. Introduction 

   The initial effort of PCE WG is focused on solving the path 
   computation problem within a domain or over different domains in 
   MPLS networks. As the same case with MPLS, service providers (SPs) 
   have also come up with requirements for path computation in GMPLS 
   networks such as wavelength, TDM-based or Ethernet-based networks as 
   well. 

   [RFC4655] and [RFC4657] discuss the framework and requirements for 
   PCE on both packet MPLS networks and (non-packet switch capable) 
   GMPLS networks. This document complements these documents by 
   providing some considerations of GMPLS applications in the intra-
   domain and inter-domain networking environments and indicating a set 
   of requirements for the extended definition of series of PCE related 
   protocols. 

 
 
T. Otani et al.           Expires July 2012                   [Page 2] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   Note that the requirements for inter-layer traffic engineering 
   described in [PCE-INTER LAYER-REQ] are outside of the scope of this 
   document. 

   Constraint based shortest path first (CSPF) computation within a 
   domain or over domains for signaling GMPLS Label Switched Paths 
   (LSPs) is more stringent than that of MPLS TE LSPs [RFC4216], 
   because the additional constraints, e.g., interface switching 
   capability, link encoding, link protection capability and so forth 
   need to be considered to establish GMPLS LSPs [CSPF]. GMPLS 
   signaling protocol [RFC3471, RFC3473] is designed taking into 
   account bi-directionality, switching type, encoding type, SRLG, and 
   protection attributes of the TE links spanned by the path, as well 
   as LSP encoding and switching type for the end points, appropriately. 

   This document provides the investigated results of GMPLS 
   applications of PCE for the support of GMPLS path computation. This 
   document also provides requirements for GMPLS applications of PCE in 
   GMPLS intra-domain and inter-domain environments. 

2. Terminology  

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

3. GMPLS applications of PCE  

3.1. GMPLS network model  

   Figure 1 depicts a typical network, consisting of several GMPLS 
   domains, assumed in this document. D1, D2, D3 and D4 have multiple 
   inter-domain links, while D5 has only one inter-domain link. These 
   domains follow the definition in [RFC4726]. 

                      +---------+ 
            +---------|GMPLS  D2|----------+ 
            |         +----+----+          | 
       +----+----+         |          +----+----+   +---------+ 
       |GMPLS  D1|         |          |GMPLS  D4|---|GMPLS  D5| 
       +----+----+         |          +----+----+   +---------+ 
            |         +----+----+          | 
            +---------|GMPLS  D3|----------+ 
                      +---------+ 
    
 
 
T. Otani et al.           Expires July 2012                   [Page 3] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

                Figure 1: GMPLS Inter-domain network model. 
    
   Each domain is configured using various switching and link 
   technologies defined in [RFC3945] and an end-to-end route needs to 
   respect TE link attributes like switching capability, encoding type, 
   etc., making the problem a bit different from the case of classical 
   (packet) MPLS. In order to route from one GMPLS domain to another 
   GMPLS domain appropriately, each domain manages traffic engineering 
   database (TED) by PCE, and exchanges or provides route information 
   of paths, while concealing its internal topology information. 

3.2. Path computation in GMPLS network  

   [CSPF] describes consideration of GMPLS TE attributes during path 
   computation. Figure 2 depicts a typical GMPLS network, consisting of 
   an ingress link, a transit link as well as an egress link, to 
   investigate a consistent guideline for GMPLS path computation. Each 
   link at each interface has its own switching capability, encoding 
   type and bandwidth. 

             Ingress             Transit             Egress 
   +-----+   link1-2   +-----+   link2-3   +-----+   link3-4   +-----+ 
   |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 
   |     |<------------|     |<------------|     |<------------|     | 
   +-----+   link2-1   +-----+   link3-2   +-----+   link4-3   +-----+ 
    
               Figure 2: Path computation in GMPLS networks. 
    
   For the simplicity in consideration, the below basic assumptions are 
   made when the LSP is created. 

   (1) Switching capabilities of outgoing links from the ingress and 
   egress nodes (link1-2 and link4-3 in Figure 2) must be consistent 
   with each other. 

   (2) Switching capabilities of all transit links including incoming 
   links to the ingress and egress nodes (link2-1 and link3-4) should 
   be consistent with switching type of a LSP to be created. 

   (3) Encoding-types of all transit links should be consistent with 
   encoding type of a LSP to be created. 

   [CSPF] indicates the possible tables of switching capability, 
   encoding type and bandwidth at the ingress link, transiting links 

 
 
T. Otani et al.           Expires July 2012                   [Page 4] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   and the egress link which need to be satisfied with GMPLS path 
   computation of the created LSP. 

   The non-packet GMPLS networks (e.g., GMPLS-based TDM networks) are 
   usually responsible for transmitting data for the client layer. 
   These GMPLS networks can provide different types of connections for 
   customer services based on different service bandwidth requests. 

   The applications and the corresponding additional requirements for 
   applying PCE to non-packet networks, for example, GMPLS-based TDM 
   networks, are described in Figure 3. In order to simplify the 
   description, this document just discusses the scenario in SDH 
   networks as an example. The scenarios in SONET or G.709 ODUk layer 
   networks are similar to this scenario. 

                     N1                    N2 
    
    +-----+       +------+              +------+ 
    |     |-------|      |--------------|      |       +-------+ 
    +-----+       |      |---|          |      |       |       | 
       A1         +------+   |          +------+       |       | 
                     |       |             |           +-------+ 
                     |       |             |              PCE 
                     |       |             | 
                     |      +------+       | 
                     |      |      |       | 
                     |      |      |-----| | 
                     |      +------+     | | 
                     |         N5        | | 
                     |                   | | 
                  +------+              +------+ 
                  |      |              |      |        +-----+ 
                  |      |--------------|      |--------|     | 
                  +------+              +------+        +-----+ 
                     N3                    N4              A2 
    
                      Figure 3: A simple TDM(SDH) network 
    
   Figure 3 shows a simple TDM(SDH) network topology, where N1, N2, N3, 
   N4 and N5 are all SDH switches. Assume that one Ethernet service 
   with 100M bandwidth is required from A1 to A2 over this network. The 
   client Ethernet service could be provided by a VC4 connection from 

 
 
T. Otani et al.           Expires July 2012                   [Page 5] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   N1 to N4, and it could also be provided by three concatenated VC3 
   connections (Contiguous or Virtual concatenation) from N1 to N4. 

   In this scenario, when the ingress node (e.g., N1) receives a client 
   service transmitting request, the type of connections (one VC4 or 
   three concatenated VC3) could be determined by PCC (e.g., N1 or NMS), 
   but could also be determined by PCE automatically based on policy 
   [RFC5394]. If it is determined by PCC, PCC should be capable of 
   specifying the ingress node and egress node, signal type, the type 
   of the concatenation and the number of the concatenation in a PCReq 
   message. PCE should consider those parameters during path 
   computation. The route information (co-route or separated-route) 
   should be specified in a PCRep message if path computation is 
   performed successfully. 

3.3. Unnumbered Interfaces 

   GMPLS supports unnumbered interface ID that is defined in [RFC 3477], 
   which means that the endpoints of the path may be unnumbered. It 
   should also be possible to request a path consisting of the mixture 
   of numbered links and unnumbered links, or a P2MP path with 
   different types of endpoints. Therefore, the PCC should be capable 
   of indicating the unnumbered interface ID of the endpoints in the 
   PCReq message. 

3.4. Asymmetric Bandwidth Path Computation 

   As per [RFC5467], GMPLS signaling can be used for setting up an 
   asymmetric bandwidth bidirectional LSP. If a PCE is responsible for 
   the path computation, the PCE should be capable of computing a path 
   for the bidirectional LSP with asymmetric bandwidth. It means that 
   the PCC should be able to indicate the asymmetric bandwidth 
   requirements in forward and reverse directions in the PCReq message. 

4. Requirements for GMPLS application of PCE  

   In this section, we describe requirements for GMPLS applications of 
   PCE in order to establish GMPLS LSP. 

4.1. Requirements of Path Computation Request  

   As for path computation in GMPLS networks as discussed in section 3, 
   the PCE should consider the GMPLS TE attributes appropriately 
   according to tables in [CSPF] once a PCC or another PCE requests a 
   path computation. Indeed, the path calculation request message from 
   the PCC or the PCE must contain the information specifying 
   appropriate attributes. According to [RFC5440],[PCEP-EXT],[ PCE-
 
 
T. Otani et al.           Expires July 2012                   [Page 6] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   WSON-REQ] and to RSVP procedures like explicit label 
   control(ELC),the additional attributes introduced are as follows: 
   [RFC5440] 

   (1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], 802_1 PBB-TE 
   [RFC6060], TDM, LSC, FSC 

   (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., 
   Ethernet, SONET/SDH, Lambda, etc. 

   (3) Signal Type: Indicates the type of elementary signal that 
   constitutes the requested LSP. A lot of signal types with different 
   granularity have been defined in SONET/SDH and G.709 ODUk, such as 
   VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in 
   G.709 ODUk. See[RFC4606] , [RFC4328]and [OSPF-G709] or [RSVP-TE-
   G709]. 

   (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two 
   kinds of concatenation modes are defined: contiguous concatenation 
   which requires co-route for each member signal and requires all the 
   interfaces along the path to support this capability, and virtual 
   concatenation which allows diverse routes for the member signals and 
   only requires the ingress and egress interfaces to support this 
   capability. Note that for the virtual concatenation, it also may 
   specify co-routed or separated-routed. See [RFC4606] and [RFC4328] 
   about concatenation information. 

   (5) Concatenation Number: Indicates the number of signals that are 
   requested to be contiguously or virtually concatenated. Also see 
   [RFC4606] and [RFC4328]. 

   (6) Technology specific label(s) such as wavelength label as defined 
   in [RFC6205]. 

   (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 
   protection, 1:1 protection, (pre-planned) rerouting, etc. 

   (8) Administrative group: as defined in [RFC3630]. 

   (9) Link Protection type: as defined in [RFC4203]. 

   (10)Support for unnumbered interfaces: as defined in [RFC3477]. 

   (11)Support for asymmetric bandwidth request: as defined in 
   [RFC5467]. 

   (12)Support for explicit label control during the path computation. 
 
 
T. Otani et al.           Expires July 2012                   [Page 7] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

4.2. Requirements of Path Computation Reply  

   As described above, a PCC must support to initiate a PCReq message 
   specifying above mentioned attributes. The PCE should compute the 
   path that satisfies the constraints which are specified in the PCReq 
   message. Then the PCE should send a PCRep message including the 
   computation result to the PCC. For Path Computation Reply message 
   (PCRep) in GMPLS networks, there are some additional requirements. 
   The PCEP PCRep message must be extended to meet the following 
   requirements. 

   (1) Concatenation path computation 

   In the case of concatenation path computation, when a PCE receives 
   the PCReq message specifying the concatenation constraints described 
   in section 4.1, the PCE should compute the path which satisfies the 
   specified concatenation constraints. 

   For contiguous concatenation path computation, the routes of each 
   member signal must be co-routed and all the interfaces along the 
   route should support contiguous concatenation capability. Therefore, 
   the PCE should compute a path based on the contiguous concatenation 
   capability of each interface and only one ERO which should carry the 
   route information for the response. 

   For virtual concatenation path computation, only the ingress/egress 
   interfaces need to support virtual concatenation capability and 
   maybe there are diverse routes for the different member signals. 
   Therefore, multiple EROs may be needed for the response. Each ERO 
   may represent the route of one or multiple member signals. In the 
   case that one ERO represents several member signals among the total 
   member signals, the number of member signals along the route of the 
   ERO must be specified. 

   (2) Wavelength label 

   In the case that a PCC doesn't specify the wavelength when 
   requesting a wavelength path and the PCE is capable of performing 
   the route and wavelength computation procedure, the PCE should be 
   able to specify the wavelength of the path in a PCRep message. 

   (3) Roles of the routes 

   When a PCC specifies the protection type of an LSP, the PCE should 
   compute the working route and the corresponding protection route(s). 
   Therefore, the PCRep should be capable of indicating which one is 
   working or protection route.  
 
 
T. Otani et al.           Expires July 2012                   [Page 8] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

4.3. GMPLS PCE Management 

   PCE related Management Information Bases must consider extensions to 
   be satisfied with requirements for GMPLS applications. For 
   extensions, [RFC4802] are defined to manage TE database and may be 
   referred to accommodate GMPLS TE attributes in the PCE. 

5. Security consideration  

   PCE extensions to support GMPLS should be considered under the same 
   security as current PCE work. This extension will not change the 
   underlying security issues.  

6. IANA Considerations 

   This document has no actions for IANA.  

7. Acknowledgement 

   The author would like to express the thanks to Shuichi Okamoto for 
   his comments. 

8. References 

8.1. Normative References 

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

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

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

   [RFC3477] K.Kompella,et al,"Signalling Unnumbered Links in Resource 
             ReSerVation Protocol-Traffic Engineering(RSVP-TE)",January 
             2003. 

   [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to 
             OSPF Version 2", RFC3630, September 2003. 

   [RFC3945] E. Mannie, et al, "Generalized Multi-Protocol Label 
             Switching Architecture", RFC3945, October, 2004. 

 
 
T. Otani et al.           Expires July 2012                   [Page 9] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   [RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in 
             Support of Generalized Multi-Protocol Label Switching", 
             RFC4202, Oct. 2005. 

   [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support 
             of Generalized Multi-Protocol Label Switching", RFC4203, 
             Oct. 2005. 

   [RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Signaling Extensions for G.709 Optical 
             Transport Networks Control", RFC4328, January 2006. 

   [RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-
             Protocol Label Switching (GMPLS) Extensions for 
             Synchronous Optical Network (SONET) and Synchronous 
             Digital Hierarchy (SDH) Control", RFC4606, August 2006. 

   [RFC4657] J. Ash, et al, "Path computation element (PCE) 
             communication protocol generic requirements", RFC4657, 
             Sept., 2007. 

   [RFC4802]   T. Nadeau and A. Farrel, Ed., "Generalized Multiprotocol 
             Label Switching (GMPLS) Traffic Engineering Management 
             Information Base", RFC4802, Feb. 2007. 

   [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to-
             End Generalized Multi-Protocol Label Switching (GMPLS) 
             Recovery", RFC4872, May 2007. 

   [RFC5476] B.Claise,Ed,"Packet Sampling(PSAMP) Protocol 
             Specifications",March 2009. 

   [RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE) 
             Communication Protocol (PCEP)", RFC5440, March 2009. 

   [RFC6002] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel 
             Switching Capable (DCSC) and Channel Set Label Extensions", 
             RFC6002, October 2010. 

   [RFC6060] Don Fedyk, et al., "Generalized Multiprotocol Label 
             Switching (GMPLS) control of Ethernet PBB-TE", RFC6060, 
             March 2011. 

   [RFC6205] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
             Switching Capable Label Switching Routers", RFC6205, March 
             2011 

 
 
T. Otani et al.           Expires July 2012                  [Page 10] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

8.2. Informative References 

   [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS 
             traffic engineering", RFC4726, November 2006. 

   [RFC5394] I. Bryskin et al., "Policy-Enabled Path Computation 
             Framework", RFC5394, December 2008. 

   [RFC6457] T.Takeda,et al,"PCC-PCE Communication and PCE               
             Discovery Requirements for Inter-Layer             
             Engineering",RFC6457,December 2011. 

   [CSPF]  T. Otani, et al, "Considering Generalized Multiprotocol 
             Label Switching Traffic Engineering Attributes During Path 
             Computation", draft-otani-ccamp-gmpls-cspf-constraints-
             07.txt, Feb., 2008. 

   [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf-
             pce-gmpls-PCEP-EXTs, in progress. 

   [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and 
             Wavelength Assignment",draft-ietf-pce-wson-routing-
             wavelength, in progress. 

   [OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to 
             OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709 
             OTN Networks", in progress. 

   [RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label 
             Switching(GMPLS) Signaling Extensions for the evolving 
             G.709 Optical Transport Network Control", in progress. 

    

    

         

 
 
T. Otani et al.           Expires July 2012                  [Page 11] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

9. Authors' Addresses 

   Tomohiro Otani 
   KDDI Corporation 
   2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan 
   Phone:  +81-3-3347-6006 
   Email:  tm-otani@kddi.com 
    
   Kenichi Ogaki 
   KDDI R&D Laboratories, Inc. 
   2-1-15 Ohara Fujimino-shi, Saitama 356-8502 Japan 
   Phone:  +81-49-278-7897 
   Email:  ogaki@kddilabs.jp 
    
   Diego Caviglia 
   Ericsson 
   16153 Genova Cornigliano, ITALY 
   Phone: +390106003736 
   Email: diego.caviglia@ericsson.com 
    
   Fatai Zhang 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
   Phone: +86-755-28972912 
   Email: zhangfatai@huawei.com 
    
    
    
Intellectual Property 
    

   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   

 
 
T. Otani et al.           Expires July 2012                  [Page 12] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   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 
   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) 2010 IETF Trust and the persons identified as the   
   document authors.  All rights reserved. 

 
 
T. Otani et al.           Expires July 2012                  [Page 13] 


Internet Drafts       Reqs for GMPLS apps of PCE           January 2012 
    

   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. 

 
 
T. Otani et al.           Expires July 2012                  [Page 14]