Internet DRAFT - draft-xia-pce-hybrid-network

draft-xia-pce-hybrid-network



Network work group                                         Hongmiao Xia 
Internet Draft                                                   Dan Li 
                                                                 Huawei 
 
Intended Status: Informational 
Expires: December 2007                                   June 30, 2007 
                                      


                                      
     Path Computation in Multiple Autonomous Systems Networks with Path 
                            Computation Element 


                    draft-xia-pce-hybrid-network-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 

   This Internet-Draft will expire on December 30, 2007. 

Abstract 

   The Path Computation Element (PCE) provides functions of path 
   computation in support of traffic engineering in Multi-Protocol Label 
   Switching (MPLS) and Generalized MPLS (GMPLS) networks. 

   One key application of the PCE-based architecture is the computation
   of inter-domain Traffic Engineering Label Switched Path (TE-LSP)  
 
 
Xia & Li              Expires December 30, 2007               [Page 1] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    
 
   paths(i.e. inter-area, inter-AS, inter-provider, etc.). In this case, 
   cooperation between PCEs is desirable due to the partial topology 
   visibility available to each separate PCE. Per-domain path 
   computation is another method that can be used to determine paths for 
   inter-domain TE-LSPs when PCE cooperation is not applied in the 
   network. 

   In practice, some Service Providers may choose not to implement PCEs 
   within their network that can cooperate with PCEs that are outside 
   their network. In this case, a scenario may exist where an LSP spans 
   multiple autonomous systems (ASes), some of which have PCEs capable 
   of cooperation with external PCEs and some of which do not. For 
   example, some ASes may be PCE-enabled, while others consist of just 
   normal LSRs.  

   Another scenario arises if a PCE fails or becomes unreachable. This 
   gives rise to the same lack of inter-PCE cooperation.  

   Both cases are named Hybrid PCE Networks in this document. This 
   document describes the specific issues introduced for end-to-end path 
   computation in Hybrid PCE Networks and defines extensions to the PCE 
   Communication Protocol (PCEP) to perform inter-domain LSP computation 
   in Hybrid PCE Networks. 

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. Process......................................................4 
      2.1. Example Scenario........................................4 
      2.2. Specific and Generic Cases..............................5 
   3. Security Considerations......................................6 
   4. Manageability Considerations.................................6
   5. IANA Considerations..........................................6 
   6. Acknowledgments..............................................6 
   7. References...................................................6 
      7.1. Normative References....................................6 
      7.2. Informative References..................................7 
   8. Authors' Addresses...........................................7 
   9. Full Copyright Statement.....................................8 
   10.Intellectual Property Statement..............................8  

 
Xia & Li              Expires December 30, 2007               [Page 2] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    
    
1. Introduction 

   The Path Computation Element (PCE) [RFC4655] provides functions of 
   path computation in support of traffic engineering in Multi-Protocol 
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A PCE 
   serves path computation requests sent by Path Computation Clients 
   (PCC). 

   The PCE communication protocol (PCEP) defined in [PCEP] is designed 
   as a communication protocol between a PCC and a PCE, or between two 
   PCEs, in compliance with requirements and guidelines set forth in 
   [RFC4657]. Such interactions include path computation requests and 
   path computation replies. 

   One key application of the PCE-based architecture is the computation 
   of Label Switched Paths (LSPs) that traverse multiple Autonomous 
   Systems (ASes). These are referred to as inter-AS TE-LSPs. Inter-AS 
   MPLS TE requirements for PCEP are described in [INTERAS-TE-REQ].  

   When computing inter-AS LSPs, a PCE may not be able to supply a full 
   path because it might not have full visibility of the network 
   topology. Typically, a PCE can only see the topology within its own 
   LSA.  

   In this case there are two proposed path computation techniques 
   ([RFC4726] and [RFC4655]) that involve multiple PCEs, each with 
   visibility into a different domain or AS.   

   o The per-domain computation approach [PER-DOMAIN] can be used 
      during LSP setup to determine the inter-domain TE LSP as it 
      traverses multiple domains. In this case, it is not necessary for 
      separate or cooperating PCEs to be used in each AS. 

   o The Backward Recursive Path Computation (BRPC) method [BRPC] can 
      also be used to compute the path of an inter-domain TE LSP. In 
      this case cooperating PCEs are required. 

   In practice, some Service Providers may choose not to implement 
   separate PCEs within their network, or may choose not to offer PCE 
   cooperation with external PCEs. Additionally, a PCE set up for inter-
   PCE cooperation may fail or be unreachable 
   A network that contains some domains with cooperative PCEs and some 
   without is termed in this document a 'Hybrid PCE Network'. And a 
   multi-domain TE LSP may need to cross domains some of which offer 
   cooperating PCEs and some of which do not. Therefore, there is a 
   requirement to be able to compute paths as extensively as possible 

 
 
Xia & Li              Expires December 30, 2007               [Page 3] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    

   before signaling (using, for example, BRPC), and to rely on per-
   domain computation to fill in the gaps during signaling. 

   This document presents PCEP extensions and procedures to enable the 
   computation of paths in Hybrid PCE Networks. 

2. Process 

2.1. Example Scenario 

      +---------------------------------+   +------------------+ 
      |           Provider A            |   |    Provider B    | 
      |       PCE1           PCE2       |   |                  | 
      |        |              |         |   |                  | 
      |        V              V         |   |                  | 
      |    R1-----R3------R5-----R6-----|---|----R9-----R11    | 
      |     |     |      / |    |       |   |    |      |      | 
      |    R2-----R4----   R7---R8------|---|----R10----R12    | 
      |                                 |   |                  | 
      |   <---AS 1--->   <---AS 2--->   |   |   <---AS 3--->   | 
      |                                 |   |                  | 
      +---------------------------------+   +------------------+ 
       
          Figure 1: Mixed Provider networks with and without PCE 
    

   Suppose provider A and B are two carrier networks. The network of 
   provider A is divided into two AS, AS 1 and AS 2, each of which is 
   deployed with a PCE. Provider B is composed of just one AS, AS 3, and 
   has no PCE deployed in its network (or perhaps the PCE has failed). 

   Assume a TE-LSP is needed between R1 and R11. The head-end node, R1, 
   chooses to use PCE1 to compute the path and selects BRPC as the 
   computation method. AS1-AS2-AS3 is provided as the AS sequence.  

   R1 sends a PCReq message to PCE1. PCE1 determines that PCE2 is a PCE 
   for AS2 and relays the PCReq message to PCE2. PCE2 finds no PCE for 
   the next AS to cooperate with. 

   If PCE2 were to just return a negative PCRep message, then this reply 
   would be returned to R1 and R1 could select another approach such as 
   the per-domain method to compute the path from R1 to R11. This is a 
   complete procedure, but there are two disadvantages . First, the 
   process falls back on the per-domain mehod which does not have such a 
   good chance of selecting an optimal path. Second, the process is 
   inefficient due to the failed BRPC attempt and the negative PCRep 
   message.  

 
Xia & Li              Expires December 30, 2007               [Page 4] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    


   But a combination of BRPC and per-domain path computation can be used 
   to increase the likelihood of achieving an optimal path. PCE2, upon 
   finding that there is no PCE available for AS3, can compute a Virtual 
   Shortest Path Tree (VSPT) [BRPC] to provide a path to each of the 
   entry points into AS3, or to some selected entry points into AS3 by 
   policy. This tree will be passed to PCE1 which will update the VSPT 
   and select a path. The final path supplied to R1 will include all of 
   the strict hops as far as AS3 (through either R9 or R10) and a loose 
   hop to the destination, R11. When the LSP is signaled, the boundary 
   node of AS3 (R9 or R10) will expand the ERO using the per-domain 
   approach, and the LSP will be completed. 

2.2. Specific and Generic Cases 

   The Hybrid PCE Network can be generalized based on three specific 
   cases as follows: 

   1) Domain 1 and domain 2 have PCEs, but domain 3 does not. 
       
      This is the case described in Section 2.1. BRPC cannot be used in 
      all domains, but can be combined with the per-domain approach. 

   2) Domain 2 and domain 3 have PCEs, but domain 1 does not.  
       
      In this case, a path computation request can never be initiated 
      from domain 1, and he LSP must be signaled across domain 1 with a 
      loose hop to cover the combination of domains 2 and 3. But, when 
      the LSP is signaled as far as domain 2, then normal PCE process 
      may take place using BRPC if desired. 

   3) Domain 1 and domain 3 have PCEs, but domain 2 does not. 
       
      In this case, ASBRs between domain 1 and domain 3 may establish 
      virtual inter-AS TE links through domain 2, and PCEs in domain 1 
      and domain 3 may communicate and use the inter-AS TE links to 
      compute. If one domain has no PCE, then it can provide inter-AS TE 
      links for its neighboring domain which has PCEs. If domain 2 does 
      not have the policy to provide inter-AS TE links, then per-domain 
      method may still be used. 

   A network may be more complex than the three cases listed above, but 
   an arbitrarily complex series of domains may be composed as a 
   sequence of the specific cases. When a domain sequence is selected, 
   where some domains have PCEs and some do not, the sequence can be 
   regarded as several contiguous segments. Each segment is composed of 
   domains that all have a PCE or all do not. For each segment having 
 
 
Xia & Li              Expires December 30, 2007               [Page 5] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    

   PCEs, the BRPC method may still be used for the segment as PCE can 
   provide a better solution considering the resources of whole network 
   it serves. For each segment having not PCE, the per-domain method may 
   be used. So computation will not be backward to head node if some 
   domain has not PCE. 

   A PCC can set O-bit in RP object to indicate it is willing to accept 
   a loose path. So if a PCE find there is no PCE in downstream domain, 
   it check whether O-bit in RP object is set. If the flag is set, the 
   PCE can use the process described above. Else, it just returns an 
   error with corresponding reasons. 

3. Security Considerations 

   TBD. 

4. Manageability Considerations 

   TBD (This section is compliant with [PCE-MGBT-REQ]). 

5. IANA Considerations 

   This document defines no new protocols or extensions and makes no 
   requests to IANA for registry management.
   
6. Acknowledgments 

   We would like to thank Adrian Farrel for his useful comments. 

7. References 

7.1. Normative References 

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

   [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 
             Element (PCE)-based Architecture", RFC4655, august 2006. 

   [RFC4726] Farrel, A., Vasseur, J.P. and Ayyangar, A., " Framework for 
             Inter-Domain Multiprotocol Label Switching Traffic 
             Engineering", RFC4726, November 2006. 

   [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic    
             Engineering Requirements", RFC4216, November 2005. 


 
 
Xia & Li              Expires December 30, 2007               [Page 6] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    

   [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)    
             communication Protocol (PCEP)", draft-ietf-pce-pcep, work 
             in progress. 

   [PER-DOMAIN] Ayyangar, A., Vasseur, J., and Zhang, R., " A Per-domain 
             path computation method for establishing Inter-domain", 
             draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in 
             progress), February, 2006. 

   [BRPC] Vasseur, J., Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward 
             Recursive PCE-based Computation (BRPC) procedure to compute 
             shortest inter-domain Traffic Engineering Label Switched 
             Paths ", draft-ietf-pce-brpc-05.txt, Work in Progress, 
             January 2007. 

7.2. Informative References 

   [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 
             Generic Requirements", RFC4657, September 2006. 

   [PCE-MGBT-REQ] Farrel, A., "Inclusion of Manageability Sections in 
             PCE Working Group Drafts", draft-ietf-pce-manageability-
             requirements-01 (work in progress), March 2007. 

8. Authors' Addresses 

   Hongmiao Xia 
   Huawei Technologies Co., Ltd.  
   F3-5-B R&D Center, Huawei Base,  
   Bantian, Longgang District  
   Shenzhen 518129 P.R.China  
    
   Phone: +86-755-28973679 
   Email: xiahongmiao@huawei.com 
    
    
   Dan Li  
   Huawei Technologies Co., Ltd.  
   F3-5-B R&D Center, Huawei Base,  
   Bantian, Longgang District  
   Shenzhen 518129 P.R.China  
    
   Phone: +86-755-28973237 
   Email: danli@huawei.com 




 
Xia & Li              Expires December 30, 2007               [Page 7] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    

9. Full Copyright Statement 

   Copyright (C) The IETF Trust (2007). 

   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 THE INFORMATION HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE. 

10.Intellectual Property Statement 

   The IETF 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 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. 

   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. 



 
Xia & Li              Expires December 30, 2007               [Page 8] 

Internet-Draft           Hybrid PCE Networks                 June 2007 
    

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

    








































 
 
Xia & Li              Expires December 30, 2007               [Page 9]