INTERNET-DRAFT                                           Tomohiro Otani 
Intended status: Informational                            Kenichi Ogaki 
Expires:March 2009                                        KDDI R&D Labs 
                                                         Diego Caviglia 
                                                               Ericsson 
                                                          Sept 17, 2008 
 
 
                Requirements for GMPLS applications of PCE 
 
               Document: draft-ietf-pce-gmpls-aps-req-00.txt 
 
 
 
Status of this Memo 
 
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of 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. 
 
 
Abstract 
 
   The initial effort of PCE WG is specifically focused on MPLS (Multi-
   protocol label switching). As a next step, this draft describes 
   functional requirements for GMPLS (Generalized MPLS) application of 
   PCE (Path computation element). 
 
 
Table of Contents 
 
   Status of this Memo................................................ 1 
   Abstract........................................................... 1 
   1. Introduction.................................................... 3 
   2. Conventions used in this document............................... 3 
   3. GMPLS applications of PCE....................................... 3 
   4. Requirement for GMPLS application of PCE........................ 4 
   5. Security consideration.......................................... 5 
     
T. Otani et al.   Informational - Expires March 2009           [Page 1] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
   6. IANA Considerations............................................. 5 
   7. Acknowledgement................................................. 5 
   8. Intellectual property considerations............................ 5 
   9. Informative references.......................................... 6 
   Author's Addresses................................................. 7 
   Document expiration................................................ 7 
   Copyright statement................................................ 7 
    
T. Otani et al.   Informational - Expires March 2009           [Page 2] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
1. Introduction 
 
   The initial effort of PCE WG is focused on solving the path 
   computation problem over 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 photonics, 
   TDM-based or Ethernet-based networks as well. 
    
   [PCE-ARCH] and [PCECP-REQ] 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 consideration of GMPLS applications in the inter-
   domain networking environment and indicating a set of requirements 
   for the extended definition of series of PCE related protocols. 
 
   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 LSPs [MPLS-AS], 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 type and 
   switching type for the end points, appropriately. 
 
   This document provides the investigated results of GMPLS applications 
   of PCE especially for the support of GMPLS inter-domain path 
   computation. This document also outlines GMPLS inter-domain 
   architecture, and provides requirements for GMPLS applications of PCE 
   in the GMPLS inter-domain environment. 
 
 
2. 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]. 
 
 
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 
   GMPLS inter-domain connections, and D5 has only one GMPLS inter-
   domain connection. These domains follow the definition in [RFC4726]. 
 
 
                    +---------+ 
          +---------|GMPLS  D2|----------+ 
          |         +----+----+          | 
     +----+----+         |          +----+----+   +---------+ 
    
T. Otani et al.   Informational - Expires March 2009           [Page 3] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
     |GMPLS  D1|         |          |GMPLS  D4|---|GMPLS  D5| 
     +----+----+         |          +----+----+   +---------+ 
          |         +----+----+          | 
          +---------|GMPLS  D3|----------+ 
                    +---------+ 
 
                Figure 1: GMPLS Inter-domain network model. 
 
   Each domain is configured using various switching and link 
   technologies defined in [Arch] and an end-to-end route needs to 
   respect TE link attributes like multiplexing type, 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.  
    
    
             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 .) must be 
           consistent with each other. 
       (2) SC 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 table of switching capability, encoding 
   type and bandwidth at the ingress link, transiting links and the 
   egress link which need to be satisfied with the created LSP. 
 
 
4. Requirement for GMPLS application of PCE 
 
   In this section, we describe requirements for GMPLS applications of 
   PCE in order to establish GMPLS LSP over domains. 
    
   4.1 PCE requirements 
    
T. Otani et al.   Informational - Expires March 2009           [Page 4] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
    
   As for path computation in GMPLS networks as discussed in section 3, 
   the PCE needs to 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 needs to contain the information specifying 
   appropriate attributes. Additional attributes to those already 
   defined in [PCECP] are as follows. 
    
   (1) Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC 
   (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, 
   SONET/SDH, Lambda, etc. 
   (3) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 
   protection, 1:1 protection, (pre-planned) rerouting, etc. 
   (4) Administrative group: as defined in [RFC3630] 
   (5) Link Protection type: as defined in [RFC4203] 
    
   4.2 PCC requirements 
    
   As described above, a PCC needs to support to initiate path 
   computation request specifying abovementioned attributes. Afterwards, 
   GMPLS signaling will be invoked according to the responded messages 
   from the PCE. 
    
   4.3 GMPLS PCE Management 
 
   PCE related Management Information Bases need to consider extensions 
   to be satisfied with requirements for GMPLS applications. For 
   extensions, [GMPLS-TEMIB] 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 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. Intellectual property considerations 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
    
T. Otani et al.   Informational - Expires March 2009           [Page 5] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
   pertain to the implementation or use of the technology described in 
   this 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.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
 
   Copies of IPR 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 
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org. 
 
 
9. Informative references 
  [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate 
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 
  [PCE-ARCH]     A. Farrel, et al, "A Path Computation Element (PCE)-
                  Based Architecture", RFC4655, Aug., 2006. 
  [PCECP-REQ]    J. Ash, et al, "Path computation element (PCE) 
                  communication protocol generic requirements", RFC4657, 
                  Sept., 2007. 
  [MPLS-AS]      R. Zhan, et al, "MPLS Inter-Autonomous System (AS) 
                  Traffic Engineering (TE) Requirements", RFC4216, 
                  November 2005. 
  [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. 
  [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. 
  [RFC4726]      A. Farrel, et al, "A framework for inter-domain MPLS 
                  traffic engineering", RFC4726, November 2006. 
  [Arch]         E. Mannie, et al, "Generalized Multi-Protocol Label 
                  Switching Architecture", RFC3945, October, 2004. 
  [PCECP]        J.P. Vasseur, et al, "Path Computation Element (PCE) 
                  Communication Protocol (PCEP)", draft-ietf-pce-pcep-
                  15.txt, March 2008. 
  [RFC4202]      K. Kompella, and Y. Rekhter, "Routing Extensions in 
                  Support of Generalized Multi-Protocol Label 
                  Switching", RFC4202, Oct. 2005. 
    
T. Otani et al.   Informational - Expires March 2009           [Page 6] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
  [RFC4203]      K. Kompella, and Y. Rekhter, "OSPF Extensions in 
                  Support of Generalized Multi-Protocol Label 
                  Switching", RFC4203, Oct. 2005. 
  [RFC4872]      J.P. Lang, Ed., "RSVP-TE Extensions in Support of 
                  End-to-End Generalized Multi-Protocol Label Switching 
                  (GMPLS) Recovery", RFC4872, May 2007. 
  [GMPLS-TEMIB]   T. Nadeau and A. Farrel, Ed., "Generalized 
                  Multiprotocol Label Switching (GMPLS) Traffic 
                  Engineering Management Information Base", RFC4802, 
                  Feb. 2007. 
  [RFC3630]      D. Katz et al, "Traffic Engineering (TE) Extensions 
                  to OSPF Version 2", RFC3630, September 2003. 
 
 
Author's Addresses 
 
   Tomohiro Otani 
   KDDI R&D Laboratories, Inc. 
   2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 
   Phone:  +81-49-278-7357 
   Email:  otani@kddilabs.jp 
 
   Kenichi Ogaki 
   KDDI R&D Laboratories, Inc. 
   2-1-15 Ohara Kamifukuoka 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 
 
 
Document expiration 
 
   This document will be expired in March 31, 2009, unless it is updated. 
 
 
Copyright statement 
    
   Copyright (C) The IETF Trust (2008).  
    
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
    
   This document and the information contained herein 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 
    
T. Otani et al.   Informational - Expires March 2009           [Page 7] 
Internet Drafts  draft-ietf-pce-gmpls-aps-req-00.txt         Sept. 2008 
    
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
T. Otani et al.   Informational - Expires March 2009           [Page 8]