Internet DRAFT - draft-bitar-zhang-interas-pceE-req

draft-bitar-zhang-interas-pceE-req







  Network Working Group                            Nabil Bitar (Editor) 
  Internet Draft                                                Verizon 
                                                                         
                                                 Raymond Zhang (Editor) 
                                                         BT Infornet 
                                                                     
                                                  Kenji Kumaki (Editor) 
                                                        KDDI Corporation 
                                                                        
                                                                        
                                                                        
  Category: Informational                                               
  Expires: April 2006                                                   
                                                           October 2005 
    
    
                      Inter-AS PCE Requirements 
    
                 draft-bitar-zhang-interas-PCE-req-01.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. 
    
    
    
    
    
    
 
Bitar et al.                                                    [Page 1] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


    
    
Abstract 
    
   This document discusses requirements for the support of the Path 
   Computation Element (PCE) in inter-AS applications.  Its main 
   objective is to present a set of requirements which would result in 
   guidelines for the definition, selection and specification 
   development for any technical solution(s) meeting these 
   requirements. 
    
   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. 
    
Table of Contents 
    
   1. Introduction.....................................................3 
   2. Definitions and Requirements Statement...........................4 
   2.1. Definitions....................................................4 
   2.2. Objectives and Requirements of Inter-AS Traffic Engineering 
   using PCE...........................................................5 
   3. Reference Model..................................................5 
   4. Example Application Scenarios....................................8 
   4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-
   regional Networks...................................................8 
   4.2. Inter-AS Path Computation over a GMPLS Transport Core.........10 
   5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE...............10 
   5.1. Requirements within one SP Administrative Domain..............11 
   5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability.........11 
   5.1.2. PCC/PCE-PCE Communication Protocol Requirements.............11 
   5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP..............13 
   5.1.2.2. PCE responses.............................................14 
   5.1.3. PCE Discovery...............................................15 
   5.1.3.1. Static configuration......................................15 
   5.1.3.2. Dynamic Discovery.........................................16 
   5.1.4. PCE: Path Computation.......................................17 
   5.1.4.1. Routing...................................................17 
   5.1.4.2. Optimality................................................18 
   5.1.4.3. Path Re-optimization......................................18 
   5.1.4.4. Support of diversely routed inter-AS TE LSP...............19 
   5.1.5. Hierarchical MPLS...........................................19 
   5.1.6. Scalability and Performance Requirements....................19 
   5.1.7. Complexity and Risks........................................20 
   5.1.8. Management, Aliveness Detection and Recovery Requirements...20 
   5.2. Requirements Across SP Administrative Domains.................21 
   5.2.1. Confidentiality.............................................21 
   5.2.2. Policy Controls.............................................22 
   5.2.2.1. Inter-AS PCE Peering Policy Controls......................22 
   5.2.2.2. Inter-AS PCE Reinterpretation Polices.....................23 
 
Bitar et al.                                                  [Page 2] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   6. Security Considerations.........................................24 
   7. Author's Addresses..............................................25 
   8. Normative References............................................25 
   9. Informative References..........................................26 
   10. Full Copyright Statement.......................................26 
   11. Intellectual Property..........................................27 
           
    
1. Introduction 
    
   MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ] 
   defined the scenarios motivating the deployment of inter-AS MPLS 
   traffic engineering. [INTERAS-TE-REQ] also specified the 
   requirements for inter-AS MPLS traffic engineering when the ASes 
   are under one Service Provider (SP) administration or the 
   administration of different SPs. 
                
   Today there are three signaling options in setting up an inter-AS 
   TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2) 
   Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE 
   LSP as in [LSP-HIERARCHY].  In addition, [INTERD-TE-PDPC] defines 
   mechanisms for inter-domain path computation using network elements 
   along the signaling and data paths.  The mechanisms in [INTERD-TE-
   PDPC] do not provide the capability to guarantee an optimum TE path 
   across multiple ASes.  An G)MPLS-TE optimum path for an LSP is one 
   that has the smallest cost, according to a normalized TE metric 
   (based upon a TE-metric or IGP metric adopted in each transit AS), 
   among all possible paths that satisfy the LSP TE constraints. 
    
   This document extends on the requirements defined in [INTERAS-TE-
   REQ] as applied to the PCE [PCE-ARCH], providing an approach for a 
   more optimum inter-AS TE path computation and potentially 
   minimizing signaling crankbacks.   
             
   The requirements for a PCE have risen from SP needs to compute a 
   more optimum path than that can be achieved by those provided in 
   [INTERD-TE-PDPC] and the capability to separate the path 
   computation elements from the forwarding elements.   
             
   Generic requirements for the PCE discovery protocol (PCEDP) and 
   PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP- 
   REQ] and [PCECP-REQ] respectively.  Complementary to these already 
   defined generic requirements, this document provides a set of 
   requirements that are specific for inter-AS path computation using 
   a PCE-based approach. Some of these requirements will become 
   generic requirements if they apply to other PCE applications.  
             
   Section 2 of this document states some definitions. Section 3 
   defines a reference model, while section 4 describes use cases of 
   inter-AS path computation using a PCE-based approach. Section 5 
   states inter-AS PCE requirements when the ASes are under a single 
   SP administrative domain.  Specifically, the requirements on PCECP, 
 
Bitar et al.                                                  [Page 3] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   PCEDP, path optimization and re-optimization, routing, hierarchical 
   MPLS, scalability, backward compatibility and management for a 
   single SP inter-AS PCE applications are described. Section 5 also 
   discusses additional requirements for inter-AS multi-SP PCE 
   applications related to confidentiality and policies. Section 6 
   discusses security issues. 
    
2. Definitions and Requirements Statement 
    
2.1. Definitions 
    
   The following provides a list of abbreviations or acronyms 
   specifically pertaining to this document: 
    
      SP: Service Providers including regional or global providers 
       
      SP Administrative Domain: a single SP administration over a 
      network or networks that may consist of one AS or multiple 
      ASes. 
       
      IP/MPLS networks: SP's network where MPLS switching 
      capabilities and signaling controls are activated in addition 
      to IP routing protocols. 
       
      Intra-AS TE: A generic definition for traffic engineering 
      mechanisms operating over IP-only and/ or IP/(GMPLS network 
      within an AS. 
       
      Inter-AS TE: A generic definition for traffic engineering 
      mechanisms operating over IP-only and/or IP/(G)MPLS network 
      across one or multiple ASes.  Since this document only 
      addresses IP/(G)MPLS networks, any reference to Inter-AS TE in 
      this document refers only to IP/(G)MPLS networks and is not 
      intended to address IP-only TE requirements. 
       
      TE LSP: MPLS Traffic Engineering Label Switched Path. 
       
      Intra-AS MPLS-TE: An MPLS Traffic Engineering mechanism where 
      its Label Switched Path (LSP), Head-end Label Switching Router 
      (LSR), and Tail-end LSR reside in the same AS for traffic 
      engineering purposes. 
       
      Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where 
      its TE LSPs, Head-end LSR and Tail-end LSR do not reside within 
      the same AS  
       
      ASBR Routers: Border routers used to connect to another AS of a 
      different or the same Service Provider via one or more links 
      between the ASes. 
       
      Inter-AS TE Path: An TE path traversing multiple ASes and 
      ASBRs, e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn. 
 
Bitar et al.                                                  [Page 4] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


       
      Inter-AS TE Path Segment: A portion of the Inter-AS TE path. 
       
      Inter-AS DS-TE: Diffserv-aware Inter-AS TE. 
       
      SRLG: A set of links may constitute a 'shared risk link group' 
      (SRLG) if they share a resource whose failure may affect all 
      links in the set as defined in [GMPLS-ROUT]. 
      PCE: Path computation element 
       
      PCC: Path computation client 
       
      PCECP: PCE communication protocol 
       
      PCEDP: PCE Discovery Protocol 
       
      Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths 
      traversing a single AS. 
       
      Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-
      TE and/or intra-AS(G)MPLS-TE paths, by possibly cooperating 
      with intra-AS PCEs, across  one or more AS(es) 
    
2.2. Objectives and Requirements of Inter-AS Traffic Engineering using 
  PCE 
    
   All applications and associated requirements cited in sections 3.2 
   and 4 in [INTERAS-TE-REQ] for inter-AS traffic engineering hold for 
   inter-AS PCE. The following key areas must be addressed in inter-AS 
   PCE solutions: 1) Inter-AS bandwidth guarantees; 2)Inter-AS 
   Resource Optimization, 3) Fast Recovery across ASes, i.e. Recovery 
   in presence of Inter-AS Link/SRLG and ASBR Node failures, and (4) 
   path optimality. The detailed requirements for PCE-based Inter-AS 
   (G)MPLS-TE path computation are discussed in section 5. 
    
3. Reference Model 
    
   Figure 1 depicts the reference model for PCEs in an inter-AS 
   application. In this document, we define two types of PCE 
   functions: inter-AS PCEs and intra-AS PCEs. Figure 1 shows the case 
   where there are three ASes, each having an inter-AS PCE. Each 
   inter-AS PCE communicates with inter-AS PCEs of neighboring ASes to 
   compute inter-AS (G)MPLS-TE paths. An inter-AS PCE may also 
   communicate with intra-AS PCEs within the scope of its AS to 
   compute a path segment within its AS. An inter-AS PCE can be an 
   external server that is not part of the routing topology or an LSR 
   (e.g., ASBR), know as composite PCE, as described in [PCE-ARCH]). 
    
           
    
    
    
 
Bitar et al.                                                  [Page 5] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


         Inter-AS        Inter-AS              Inter AS 
           PCE1<---------->PCE2<-------------->  PCE3 
            ::              ::                    :: 
      R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 
      |      |        |            |        |           |     
      |      |        |            |        |           | 
      R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 
                            :: 
                          Intra-AS 
                            PCE 
      <==AS1=>       <====AS2======>      <=====AS3===> 
    
   Figure 1 Inter and Intra-AS PCE Reference Model 
    
   In general, an inter-AS PCE is associated with one ore more ASes 
   that define its scope. It receives path computation requests for 
   (G)MPLS-TE LSPs from PCCs or other inter-AS PCEs and responds to 
   these requests. An intra-AS PCE (e.g., inter-area PCE) is one 
   responsible for path computation within a single AS. It should be 
   emphasized that the differentiation between these two PCE types is 
   functional as both can be implemented and enabled on the same 
   physical device, but scalability requirements and/or security 
   considerations may require their separation. An inter-AS PCE can be 
   an intermediate-PCE or a terminating-PCE for a given LSP. An 
   intermediate-PCE is associated with transit ASes whereas a 
   terminating-PCE is associated with the AS originating or 
   terminating the path computation request. If the head-end and tail-
   end of an LSP are in ASes within the scope of a single inter-AS 
   PCE, the full path computation can be solely done by that inter-AS 
   PCE, possibly cooperating with other intra-AS PCEs if it does not 
   have the full topological and TE knowledge of the ASs within its 
   scope. Otherwise, multiple inter-AS PCEs need to cooperate to 
   compute the LSP path as described in [PCE-ARCH].  
    
   The LSR at the head-end of an LSP or a proxy on its behalf (either 
   being a PCC) sends a path computation request to one of its inter-
   AS PCEs upon determining, via configuration or dynamic routing, 
   that the tail-end is an AS-external destination. There could be one 
   or more inter-AS PCEs associated with a given LSR AS. The choice of 
   an inter-AS PCE among many can be based on the corresponding 
   destination AS, configuration, and/or load-balancing criteria. An 
   inter-AS PCE in the originating AS sends a path computation request 
   to one or more neighboring AS-PCEs based on the AS through which it 
   learned reachability (maybe the best path ) to the destination 
   tail-end and/or based on policy. Each neighboring inter-AS PCE that 
   receives the request determines its neighbor inter-AS PCE that it 
   progresses the path request to. In determining the inter-AS PCE to 
   which the path request must be sent, an inter-AS PCE may first 
   qualify the path to an ASBR associated with that inter-AS PCE and 
   may exclude paths that do not satisfy the constraints of the LSP 
   (e.g., by excluding ASBRs and inter-AS links between the two 
   neighboring ASs when there is not sufficient bandwidth on the paths 
 
Bitar et al.                                                  [Page 6] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   to these ASBRs or ASes to sastisfy the LSP bandwidth constraints). 
   Before an inter-AS PCE decides to send a path computation request 
   to a neighbor inter-AS PCE, it may also qualify the paths to the 
   neighbor AS by consulting its intra-AS PCE(s). When setting up a 
   bi-directional LSP using GMPLS signaling, a PCE may qualify the 
   path in both directions according to the LSP constraints.   
    
   In an all-PCE enabled environment, the last inter-AS PCE, serving 
   the AS of the LSP tail-end computes one or more path in the AS(es) 
   within its scope by cooperating with intra-AS PCEs. If the 
   immediate requestor (e.g., the previous inter-AS PCE) is under 
   another SP administrative domain, the inter-AS PCE may not return a 
   path with strict hops (i.e., LSP tail-end). What could be returned 
   in the path computation response is generally controlled by policy 
   configuration. The inter-AS PCE may return one or more paths, each 
   of which is composed of a list of one or more ASBRs and/or ASes as 
   loose hops and a cost associated with each path. The returned 
   path(s) must at least include ASBRs connected to the ASes 
   affiliatied with the responding PCE. This process recourses until 
   the inter-AS PCE serving the LSP head-end receives a response to 
   its request(s) from the immediate inter-AS PCE(s) it sent requests 
   to. Every time an inter-AS PCE responds to a requestor it 
   concatenates each path it computes with a path it received from the 
   next immediate PCE, composes a cost for the total path and returns 
   the concatenated path(s) to the previous immediate requestor. It 
   should be noted that the path(s) computed by a PCE will be 
   constrained by the path(s) received from the next inter-AS PCE(s) 
   and any other constraints in the received request.   
    
   If the original PCC (LSR at the head-end of the LSP or proxy) 
   selects a path out of the received ones and the path is composed of 
   all strict hops, the head-end LSR will use the signaling procedures 
   defined in [ITERD-TESIG] to signal the LSP with an explicit route 
   object (ERO) consisting of these strict hops. There will be no need 
   for computing path segments to loose hops at intermediate nodes. If 
   the path selected by the head-end LSR is composed of strict and 
   loose hops, there needs to be a way for an intermediate node to 
   complete the path between that node and the next loose hop with 
   strict hops. How this is most efficiently done SHOULD be subject 
   for further study. Some possible mechanisms include: 
    
   (1) A node that needs to acquire a path of strict hops to reach a 
   loose hop specified in the ERO, requests an inter-AS PCE or intra-
   AS PCE, depending on the situation, to compute that path. In this 
   case, the original path computation triggered by the head-end LSR 
   would have computed that path and the path gets recomputed again 
   during the (G)MPLS-TE signaling phase.   
             
   (2) In order to avoid the path-segment re-computation in option 
   (1), an inter-AS PCE involved in the LSP path computation may store 
   the LSP path-segment it computes for a limited time. Signaling may 
   carry a PCE identifier (in case there is more than one PCE serving 
 
Bitar et al.                                                  [Page 7] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   the ASBR), and another path-identifier to enable an ASBR to 
   retrieve the path segment from the PCE. The path-identifier can be 
   an LSP identifier that when coupled with the requesting ASBR and 
   the next hop in the ERO can uniquely identify the path-segment. 
   This approach may require a signaling extension. When a path is 
   retrieved, all other path(s) associated with that LSP at the PCE 
   could be deleted immediately. In order to avoid permanent storage 
   of path-segment(s) at the PCE, there could be a timer associated 
   with each path-segment or with the LSP at the PCE that causes 
   deletion of these path(s) when the timer expires. 
             
   (3) Alternatively, the inter-AS PCE may communicate to an ASBR the 
   path segment(s) rooted at that ASBR along with the associated LSP        
   identifier. When the ASBR receives a (G)MPLS-TE path message, it        
   performs a lookup based on the LSP identifier to identify the path         
   segment between itself and the next hop in the received ERO. Unused         
   path segments at the ASBR could be deleted immediately. The path-       
   segment(s) associated with a given LSP could have a timer 
   associated with them so that when the ASBR does not get a path 
   message for that LSP within a timeout interval, the timer expires 
   and all the associated path segments are deleted.  Please note that 
   this ASBR may or may the inter-AS PCE itself, in other words, a LSR 
   selected as a PCE does not necessarily have to be on the TE LSP 
   Path it computes. 
     
   Other mechanisms may also exist. Each of these mechanisms will have       
   associated tradeoffs and may drive requirements on PCECP and/or        
   signaling. Those types of requirements driven by specific solutions 
   are not defined in this document.  
             
   In certain operating environments, PCEs may not be available end to        
   end. Added to that, inter-AS traffic engineering capabilities may 
   not be available end-end. This document addresses requirements to 
   deal with these situations.   
    
4. Example Application Scenarios 
    
4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional 
    Networks 
    
   A number of application scenarios are discussed in section 4 of 
   [INTERAS-TE-REQ] where computing an inter-AS TE LSP path could rely 
   on per-domain path computation using procedures documented in 
   [INTERD-TE-PDPC].  However, as noted above, a per-domain computing 
   method does not always yield optimum paths. In this section, we 
   present a similar inter-AS TE application scenario using PCEs with 
   inter-AS scope to compute optimum paths across AS boundaries. 
    
   Section 4.1.1 and section 4.2.2 of [INTERAS-TE-REQ] have presented 
   two cases where a global service provider (SP1) would like to 
   extend its reach into a region using a regional network (SP2) as 
   MPLS transport.  SP1 in these cases would either co-locate its 
 
Bitar et al.                                                  [Page 8] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   regional POP as a virtual PoP within SP2's POP or link its own sub-
   regional network back to SP1's main backbone over SP2's network. 
   This is further illustrated in the diagram of Figure 2: 
    
            <=Inter-AS MPLS TE Tunnel T1(R13,R15)=> 
                                              R16(PCE)  
                                                |  
   R11(PCC)-R13(PCC)<===>R21-R23-R26(PCE)<===>R15(PCC)-R19-R112  
       \    /|      \     |\     /    |  \   /  | \    /     |  
        \  / |       \    | \   /     |   \ /   |  \_R110    |  
         \/  |        \   |  \ /      |    \    |   \/       |   
         /\  |         \  |   R24(PCE)|   / \   | _ R111     |  
        /  \ |          \ |  /  \R25  |  /   \  |  /    \    | 
       /    \|           || /     \   | /     \ | /      \   |  
   R12(PCC)-R14(PCC)<===>R22----R27(PCE)<===>R17(PCC)----R113(PCC)  
                                               |  
                                             R18(PCE)                               
            <=Inter-AS MPLS TE Tunnel T2(R14,R17)=>     
   <=============Inter-ASS TE Tunnel T3(R11,R113)============>  
   +=SP1 VPOP/sub=+     +===SP2 As2===+   +=SP1 backbone AS1=+  
     network AS1  
    
   Figure 2: SP1 extended reach linking vPOP or Sub-regional network 
   over SP2 MPLS Transport  
    
   In the above example diagram, ASBR R13 and R14 as PCCs, dynamically 
   or statically discover their corresponding PCE R16 and R18 which 
   maintain meshed peering with AS2 PCE R26 and R27, respectively.   
   They then send PCC/PCE path requests to their own primary PCEs (R16 
   or R18) for two optimum yet diversified inter-AS paths for 
   T1(R13,R15) and T2(R14,R17) across AS2.  In addition, R11 would 
   require to build a separate inter-TE tunnel to R113 directly to 
   support a customer voice trunk, for example.   
    
   With per-domain path computation, the three tunnels would be built 
   with paths as shown below assuming all links with metric value of 1 
   and inter-AS links between ASes with the same maximum reservable 
   bandwidth: 
    
    - T1's path: (R21,R15) expanding at R21 to have the path R13-R21-
   R23-R26-R15; 
    - T2's path: (R22,R17) expanding at R22 to have the path R14-R22-
   R27-R17; 
    - T3's path: (R21,R113) expanding at R21 to have the path R11-R13-
   R21-R23-R26-R15-R17-R113 
     
   For T1 and T2, the requirement for diversifications is paramount 
   where R26 and R27 will need to maintain both synchronized states of 
   both T1 and T2 in order to compute two diverse routes between these 
   two inter-AS TE LSPs where their HEAD-ENDs and TAIL-ENDs are 
   terminated on the same pair of ASes (exactly the same ASN in this 
   case). 
 
Bitar et al.                                                  [Page 9] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


    
   For T3, a more optimum path should be R11-R14-R22-R27-R17-R114 
   which can be obtained through AS1 PCEs (R16 or R17) where R22 and 
   R17 are selected as better exits for neighbor ASes. 
    
   In this environment, PCE R24 in AS2 is only for intra-AS TE path 
   computation while R26 and R27 are intra-AS PCEs as well as inter-AS 
   PCEs for AS1 among others. R16 and R17 are dedicated routers 
   running PCE process for AS2. 
 
   Please note that we could also configure R13 and R14 as PCEs as 
   well with direct peering to R26 and R27.  In this case, the ASBR 
   routers function as the PCE, PCC and the inter-AS tunnel-head end 
   or tail-end at the same time. 
    
4.2. Inter-AS Path Computation over a GMPLS Transport Core  
    
   This section illustrates a simplified case where inter-AS scoped 
   PCEs are used for path computations across a GMPLS transport core.   
        
   (PCC)                                                     (PCC) 
   R1--ASBR1(PCE)<==>ASBR2(PCE)-GMPLS-ASBR3(PCE)<==>ASBR4(PCE)--R2  
       MPLS(PSC)     GMPLS(PSC)       GMPLS(PSC)    MPLS(PSC)    
   +===SP1 AS1===+  +=======SP2 As2=============+  +===SP3 AS3===+   
    
   Figure 3 Inter-AS TE LSP over a GMPLS Transport Core 
    
   In Figure 3, R1, a PCC sends an MPLS-TE based request message to 
   its own PCE ASBR1 for an inter-As TE LSP between R1 and R2.  ASBR1 
   in turns requests a path computation from its downstream peering 
   PCE ASBR2 for this path to AS3 via AS2.  This would require ASBR2 
   to have the ability to receive MPLS-TE based request messages and 
   reinterpret the portion corresponding to GMPLS specific attributes 
   (if any) for carrying out path computations. 
    
   In this application scenario, AS2 is a pure GMPLS core.  It is 
   worth noting that AS2 could have outer MPLS edge where the inter-AS 
   TE LSPs may get aggregated onto the GMPLS TE LSP on the core GMPLS 
   PSC. 
    
5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE 
    
   This section discusses detailed requirements in two principal areas 
   for inter-AS (G)MPLS-TE using a PCE-based approach: 1) requirements 
   for inter-AS (G)MPLS-TE in the same SP administrative domain (i.e., 
   intra-provider) and 2) requirements for inter-AS (G)MPLS-TE/ across 
   different SP administrative domains (i.e., inter-provider). 
    
    
    
    
    
 
Bitar et al.                                                 [Page 10] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


.5.1. Requirements within one SP Administrative Domain 
    
   This section presents detailed PCE requirements for inter-AS 
   (G)MPLS-TE within the same SP administrative domain. It should be 
   noted that ASes in a single SP administrative domain can have 
   various restrictions and policies among the ASes, as in the inter-
   provider case. The additional PCE requirements for the inter-
   provider case are documented in section 5.2. 
    
  5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability 
    
   The PCE solution for inter-AS applications SHOULD be consistent 
   with the requirements discussed in [TE-REQ] and [INTERAS-TE-REQ]. 
   The derived solution MUST be such that it will interoperate 
   seamlessly with current intra-area and inter-domain (inter-area and 
   inter-AS)(G)MPLS-TE mechanisms.  
       
   The inter-AS PCE-based solutions MUST interoperate with other 
   mechanisms for path computation to ensure that a path for an LSP 
   with TE constraints can be set up across ASes with and without PCE 
   capabilities.  
    
   The proposed solution SHOULD allow the setup of an inter-AS TE-LSP 
   by provisioning the TE LSP at the head-end and using (G)MPLS-TE 
   signaling to signal the LSP to the tail-end residing in another AS 
   traversing, without any further provisioning requirement, 
   intermediate points along the transit path. 
    
  5.1.2. PCC/PCE-PCE Communication Protocol Requirements 
    
   Operations in an all-PCE-enabled environment are described in [PCE-
   ARCH] and, in the case of inter-AS PCE-based path computation, in 
   section 3. There are cases, as stated in section 3, where the 
   environment may not be an all-PCE environment. Figure 4 depicts 
   such a case where AS1 does not have PCEs, whereas AS2 and AS3 do. 
   Thus, when a TE-LSP is being signaled from an originating node (R1) 
   in AS1 and terminating in AS3, R1 uses mechanisms described in 
   [INTERD-TE-PDPC] and [INTERD-TESIG] to compute and signal a path to 
   the AS1 ASBR connecting to AS2 (ASBR1). ASBR1 will send a path 
   message to the connected ASBR in AS2 (ASBR3). ASBR3 can make a 
   request to an inter-AS PCE for a path that satisfies the LSP 
   Constraints to the destination. In this case,   
    
    
    
    
    
    
    
    
    
    
 
Bitar et al.                                                 [Page 11] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


      Non PCE          PCE                   PCE 
      Inter-AS Path    Inter-AS Path         Inter-AS Path 
      Computaion       Computation           Computation 
      Scope            Scope: AS2/AS3        Scope: AS3/AS2 
      <------>       <-------------->       <-----------> 
    
                         Inter-AS               Inter AS 
                           PCE<------------------>PCE 
                           ::                    :: 
      R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 
      |      |        |            |        |           |     
      |      |        |            |        |           | 
      R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 
                            :: 
                         Intra-AS 
                           PCE 
      <===AS1=>       <=====AS2=====>       <======AS3==> 
    
      Figure 4. Non-PCE and PCE path computation scopes 
    
   This diagram illustrates an inter-AS (G)MPLS-TE environment 
   composed of ASs with PCE capability and ASes without PCE 
   capability. Specifically, AS1 has no PCEs while AS2 and AS3 have 
   inter-AS and intra-AS PCEs. ASBR3 will be a PCC to the inter-AS 
   PCE .. serving AS2. 
    
   Requirements specific to requests or responses are discussed in the 
   next subsections. Following are additional generic requirements to 
   those described in [PCECP-REQ] for PCC/PCE-PCE communication. Some 
   of these requirements apply to the process handling PCC/PCE-PCE 
   communication and not the protocol itself: 
    
   - An inter-AS PCE must be able to locally prioritize messages on an 
   AS basis in addition to message-level priority.  
    
   - An inter-AS PCE must be able to change the message priority when        
   sending a path computation request from the priority it received 
   for the same LSP. A notification message should be sent to the 
   requestor indicating that change. Such notification must be 
   suppressed by configuration action on a neighboring inter-AS PCE 
   basis. 
    
   - An inter-AS PCE must be able to perform translation on class of 
   service identifiers carried in a request/response for a DS-TE 
   packet LSP when the two ASes attempting to set an LSP or LSP 
   segment between them use different class type identifier values. 
   Such a situation may rrise when ASes become part of one service 
   provider domain as a result of mergers and acquisitions.  
    
   - A PCE must be able to protect itself against DOS attacks 
   initiated by malicious (could be pretender) PCEs/PCCs who attempt 
   to initiate these attacks via PCE communication protocol messages. 
 
Bitar et al.                                                 [Page 12] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   The aversion of such attacks could also be achieved via a network-
   wide set of policies that extend beyond the PCE and are out of the 
   scope of this document. In inter-AS operation, an inter-AS PCE must 
   be able to drop PCECP messages arriving from an AS that it does not 
   wish to communicate with. It must also be able to limit the 
   aggregate rate of PCECP requests/responses arriving from PCEs 
   affiliated with one ore more ASes or from a group of one or more 
   ASes.    
    
   5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP 
    
   Path computation requests must be able to carry all constraint 
   attributes necessary for setting up an LSP via (G)MPLS-TE signaling 
   as stated in [PCECP-REQ]. A path computation request to an inter-AS 
   PCE must be able to specify ASBRs and ASes as strict and loose 
   nodes in the path of the LSP to the destination. A PCE must also be 
   able to specify a preferred ASBR for exiting to the next AS for 
   reaching the destination through a neighboring AS.  
    
   An inter-AS PCE must also be able specify in its request a list of 
   ASes and/or ASBRs to be excluded in the path computation. In the 
   intra-provider case, it may also include links with specific 
   affinity in the exclude list. 
    
   If an inter-AS PCE learns reachability to a destination from 
   different ASes, it should be able to send simultaneous requests to 
   the inter-AS PCEs associated with these ASes. The maximum number of 
   inter-AS PCEs, an inter-AS PCE may send simultaneous requests to, 
   SHOULD be configurable. The choice of inter-AS PCEs could be 
   influenced by policies which prefer some paths over others or some 
   PCEs over others. When sending simultaneous requests, the tradeoff 
   between signaling and path computation activity on one hand and the 
   likelihood of setting an end-end optimum path should be considered.  
    
   The PCC/PCE-PCE communication protocol must enable an inter-AS PCE 
   to specify the AS on whose behalf it is sending the request. This 
   is specifically important when the inter-AS PCE has identified many 
   ASes within its scope to the other inter-AS PCE at the other end of 
   the communication.  
     
   A PCC or PCE (including inter-AS PCE) must be able to specify in 
   its request the need for computing an end-end inter-AS path with 
   protection against node and/or link failure using 1:1 detours or 
   facility backup. An inter-AS PCE may itself ask for a similarly 
   protected path. In addition, it may ask for protection across all 
   ASes the path can traverse or across specific ASes. A path 
   computation client must also be able to ask for a minimum of two 
   paths that are diversified (i.e., do not share common nodes, links 
   or SRLGs) it is request to an inter-AS PCE.  
     
   An inter-AS PCE must be able to reject a request based on policies 
   applied at a neighboring AS basis. Such policies may include any 
 
Bitar et al.                                                 [Page 13] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   valid request attributes, including class-types for packet LSPs, 
   bandwidth that exceeds a preset threshold per LSP, preemption 
   priorities, setup priorities, restriction on links with certain 
   affinities, and desired protection. When a path request is 
   rejected, the requestor must be informed of the rejection reason 
   along with any information that may help the requestor avoid the 
   points and/or reasons of rejections.    
     
   5.1.2.2. PCE responses 
    
   A path computation response must be able to include nodes (e.g., 
   ASBRs), abstract nodes such as ASes, and links as described in 
   [PCE-ARCH]. In inter-AS intra-provider path computation, there may 
   not be any confidentiality issues or restrictions that prevent one 
   AS from returning a path with strict hops and no loose hops (i.e., 
   nodes and links) within its AS to the requesting inter-AS PCE. In 
   this case, the head-end of an LSP could receive, as a result of the 
   work of multiple cooperating intra-AS and inter-AS PCEs, a path 
   that contains nodes and links as strict hops from LSP head-end to 
   tail-end.  
    
   An inter-AS PCE, when it finds more than one path that satisfies 
   the constraints for an LSP, must be able to return a number of 
   these paths to the requestor. This requirement presumes that the 
   path computation algorithm can compute and return more than one 
   path. The number of returned paths must be configurable at the 
   requesting PCE and the responding PCE to limit the amount of 
   computation and total returned paths to the original PCC as 
   computation recourses toward the AS of that PCC at the expense of 
   possibly not computing the shortest path. Each path must contain 
   the ASBR that connects to the requestor AS at a minimum.  In 
   addition, a cost associated with each path should be returned to 
   enable selection of an optimum end-end path. The cost could reflect 
   the cumulative administrative cost within a path. The PCC/PCE-PCE 
   communication protocol must be able to carry this information. 
    
   In its response, an inter-AS PCE must identify disjoint paths, when 
   it is requested to compute such paths. End-end disjoint paths are 
   paths that do not share nodes, links or SRLGs except for the LSP 
   head-end and tail-end. In cases, where disjoint path segments are 
   desired within one or more ASs, the disjoint path segments may 
   share only the ASBRs of the first AS and the ASBR of the last AS 
   across these ASes.  
    
   If an inter-AS PCE cannot find a path to the destination or it 
   cannot find a path that satisfies the LSP constraints, it must send 
   a reject-type message to the requestor with a reject reason. Upon 
   receiving this reject message, an inter-AS PCE or a PCC SHOULD 
   attempt an alternative path by sending a request to an alternative 
   AS-PCE. If it exhausted all AS-PCEs it SHOULD send a reject message 
   to the previous requestion inter-AS PCE. 
    
 
Bitar et al.                                                 [Page 14] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   5.1.2.2. PCE Discovery 
    
   In this section the requirement for PCE discovery are discussed. 
   There are two types of PCE discovery that SHOULD be supported: (1) 
   static via manual configuration, and (2) dynamic. In each case, the 
   discovery of an inter-AS PCE within an AS and across ASes is 
   addressed. 
    
  5.1.2.3. Static configuration 
    
   An intra-AS inter-area PCE or a PCC MUST be configurable with one 
   or more inter-AS PCEs that serve the respective PCE/PCC AS. An 
   inter-AS PCE MUST also be configurable with the set of other inter-
   AS PCEs that it can have a session with and the ASes that these 
   inter-AS PCEs cover. For simplicity, each inter-AS PCE should have 
   a relationship with at least one inter-AS PCE that serves an AS it 
   connects directly or indirectly at some cases with and not under 
   its own jurisdiction. Each PCECP relationship between two inter-AS 
   PCEs MUST be configurable with the ASes that the inter-AS PCE at 
   the other end serves. In addition, other attributes for PCECP 
   between two PCEs must be configurable. Such attributes include: 
    
   - The IP address of the inter-AS PCE at the other end of the 
   session and the locally used IP address to exchange IP address with 
   inter-AS PCE. This IP address may differ from the one used for 
   communicating with other PCEs/PCCs. 
    
   - The type of the PCE at the other end of the session (e.g., inter-
   area intra-AS, intra-area intra-AS, or inter-AS). 
     
   - The authentication policy for that session and key when 
   authentication is required. This assumes that the transport 
   protocol supports authentication. Alternatively, the session should 
   be configurable over an IPsec tunnel with null encryption but with 
   packet authentication. The IPsec tunnel can be in tunnel mode or 
   transport mode.  
    
   - A map for the class type (CT) and TE-class translation when the 
   inter-AS PCE computes paths for packet LSPs. 
    
   - The priority that a given inter-AS PCE serves the messages from 
   the inter-AS PCE at the other end of the session as a matter of 
   policy. 
    
   - The message priorities that it can accept, and whether messages 
   related to the path computation requests it receives from an inter-
   AS PCE should be initiated/progressed with a different locally 
   defined priority map. The priority map must be configurable. In 
   addition, enabling the notification of a requestor that the 
   priority for a given message was changed should be enabled/disabled 
   by configuration. 
    
 
Bitar et al.                                                 [Page 15] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   - The capability of the inter-AS PCE at the other end of the 
   session to compute multiple paths and the maximum number of paths 
   it can return.  
    
   The maximum number of paths that a local inter-AS PCE can accept 
   and specify in a path computation request 
    
   - The total number of inter-AS messages that an inter-AS PCE can 
   simultaneously accept from the inter-AS PCE at the other end should 
   be configurable. An inter-AS PCE should be able to send a 
   backpressure message via the PCC/PCE-PCE communication protocol to 
   another inter-AS PCE to hold off the transmission of new requests. 
   This should be triggered by the threshold set on PCE-PCE pair basis 
   or the overall overload condition on the system, whatever triggers 
   first. In addition the request rate should be configurable and 
   enforceable.  
           
  5.1.2.4. Dynamic Discovery 
    
   [PCEDP-REQ] states generic requirements for the PCE dynamic 
   discovery protocol. In this section, additional dynamic PCE 
   discovery requirements specific to inter-AS operations are 
   discussed. An inter-AS PCE must be able to dynamically discover 
   other types of PCEs in the ASes that fall within its scope. In 
   addition other PCCs or PCEs must be able to discover an inter-AS 
   PCE that serves them. The dynamic discovery protocol must also 
   enable the detection and advertisement of the failure or non-
   reachability of an inter-AS PCE as well other PCEs within an AS and 
   across ASs. The dynamic discovery protocol must allow an inter-AS 
   PCE to identify itself as an inter-AS PCE and to identify the ASes 
   that it supports. In addition, it must be able to identify its 
   capabilities to the degree necessary for another PCE or PCC to 
   decide to initiate a PCECP session to it. More detailed 
   capabilities could be negotiated in PCC/PCE-PCE communication 
   protocol messages. 
    
   An inter-AS PCE may not be an inter-provider inter-AS PCE. In 
   addition, it may be desired for an inter-AS PCE not to be 
   discovered by a set of ASes or some of its capabilities not be 
   known by a set of ASes.  Thus, the capability to limit the scope of 
   an inter-AS PCE advertisement for the purpose of dynamic discovery 
   by other PCCs/PCEs must be provided. Furthermore, the ability to 
   define the capabilities of an inter-AS PCE that can be advertised 
   to another inter-AS PCE must be provided.  
    
   A PCC/PCE must allow the configuration of local policies that 
   control which inter-AS PCE it can communicate with when it 
   discovers PCEs. Such policies may be based on PCE capabilities, 
   specific PCEs or ASes that the PCE is affiliated with.  
    
   The inter-AS PCE discovery mechanisms must commonly apply to both 
   intra-provider and inter-provider cases.  
 
Bitar et al.                                                 [Page 16] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


    
  5.1.3. PCE: Path Computation 
    
   This section discusses the path computation requirements, including 
   the requirements on routing, optimality, and path re-optimization. 
    
   5.1.3.1. Routing  
    
   An inter-AS PCE could be a composite PCE or a standalone server. In 
   either case, an inter-AS PCE must have reachability information to 
   the LSP tail-end and head-end. At minimum, this reachability 
   information must include the AS path to the LSP tail-end, and the 
   AS in which the tail-end and head-end of the LSP reside. In 
   addition, it needs to have knowledge of the ASBRs that interconnect 
   the ASes within its scope to each other and to other ASes outside 
   of its scope and the various attributes associated with the routes 
   advertised by these ASBRs. One simple way to obtain this 
   information is to have an iBGP session with each ASBR in the ASes 
   it is serving. Using this information, an inter-AS PCE can 
   determine whether it can itself fully handle the path computation 
   request. Otherwise, the inter-AS PCE determines the next inter-AS 
   PCE it needs to send a request to in order to complete the path 
   computation to the tail-end. The inter-AS PCE needs to interact 
   with intra-area PCEs and inter-area PCEs in the ASes within its 
   scope to compute a path segment between the head-end and tail-end 
   of the LSP. The separation between inter-AS (inter-provider and 
   intra-provider), inter-area, and intra-area PCEs is a functional 
   separation. A single physical element may have all the functions 
   and therefore the interaction will be platform-internal. Thus, a 
   composite PCE or a server can implement all PCE functions and 
   acquire inter-AS information as well as topological information, 
   including the TED, for ASes within its scope. Similarly a PCE 
   server can acquire this information in many ways. 
    
   For an inter-AS PCE to compute multiple paths, especially between 
   two ASes for instance that peer at two or more ASBRs, it must be 
   able to maintain all the BGP advertisements from each ASBR and use 
   this raw information to compute a path. 
    
   The exact procedure(s) that govern the interaction between an 
   inter-AS PCE and intra/inter-area PCEs in the ASes within its scope 
   for the purpose of path computation shall be specified and shall 
   result in an optimum way of computing an inter-AS TE-LSP path. 
   Optimality measures are discussed in the next section. The 
   procedures could depend on who triggers the initial path 
   computation request and could vary between the AS of the LSP head-
   end, a transit AS and the AS of the LSP tail-end. These procedures 
   shall also take into account the scalability of the overall 
   solution (i.e., number of PCC and PCE relationships from the point 
   of view of the PCC/PCE-PCE PCECP, the amount of information that 
   need to be stored at an inter-AS PCE, etc.) 
    
 
Bitar et al.                                                 [Page 17] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   5.1.3.2. Optimality 
    
   The inter-AS PCE solution SHOULD allow the set-up of an inter-AS 
   (G)MPLS-TE LSP that complies with a set of TE constraints defined 
   in [TE-REQ]), respectively, and follows an optimal path. The 
   definition of “optimal path” for a TE LSP path can be found in 
   section 5.1.3 of [INTERAS-TE-REQ] and Section 1 of this document. 
   An optimal solution is also one that results in the fastest 
   computation of an LSP path when compared to other solutions under 
   the same PCE topologies, network topologies, and PCC/PCE topology.  
    
  5.1.3.3. Path Re-optimization 
    
   When there are resource changes within any AS on the path of an 
   already-established LSP, a more optimal path may have become 
   available. In this case, the head-end of an LSP in another AS may 
   not be able to detect these changes unless they affect the BGP 
   announcements that include reachability to the LSP-tail end.  
    
   Triggering path re-optimization for an inter-AS LSP can be done via 
   a management action in reaction to the network event or via a 
   periodic re-optimization attempt by the LSP head-end. 
   Alternatively, this trigger can be dynamic in reaction to network 
   events. If solutions allow relaying a re-optimization trigger via 
   PCEs, and specifically inter-AS PCEs, using the PCC/PCE 
   communication protocol messaging, such solutions must be designed 
   with scalability in mind as multiple LSPs could become eligible for 
   re-optimization at the same time.  
    
   If re-optimization is triggered dynamically by network events, a 
   large number of LSP head-ends may simultaneously attempt to 
   initiate path re-optimization for many LSPs, potentially 
   overloading PCCs and PCEs, specifically, inter-AS PCEs. Similarly, 
   if path re-optimization is attempted periodically at the head-end 
   of an LSP or a proxy to the LSP head-end that launches path 
   computation requests on its behalf (i.e., a PCC), PCCs and PCEs 
   could become overloaded. Therefore, PCCs that initiate requests for 
   path computation should implement mechanisms that pace path re-
   optimization requests and avoid network activity synchronization. 
   This should be a generic requirement on PCC behavior. For instance, 
   when periodic re-optimization is used for re-optimization attempt, 
   the number of LSPs that could be re-optimized in a given period 
   should be configurable. In addition, the re-optimization period 
   itself should be configurable. A re-optimization request to a PCE 
   must be identified as such. Policies on the PCE must be 
   configurable to allow or prevent re-optimization to/from certain 
   ASes, or based upon {class type, preemption} in the case of DS-TE, 
   where a policy exists, to give priority to certain TE LSPs when re-
   optimization is identified. Re-optimization should be configurable 
   to be enabled/disabled on a PCC basis, PCE-basis, and per-LSP.  
    

 
Bitar et al.                                                 [Page 18] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


  5.1.3.4. Support of diversely routed inter-AS TE LSP  
    
   The head of the LSP or a proxy (either being a PCC) on its behalf 
   may desire to setup two or more LSPs with diversified paths between 
   the same tail-end and head-end. A diversified path avoids the 
   sharing of nodes and links along the path between the two LSPs and 
   optionally seeks to minimize the number of shared ASes across the 
   two paths. The solution shall provide ways for computing such 
   diversified paths. 
    
   The head-end of an LSP or a proxy (PCC) on its behalf may desire to 
   setup a hot-standby path for an LSP that is diversified from the 
   primary path. The inter-AS PCE solution should provide for this 
   capability. 
      
   Inter-AS MPLS Fast Reroute 
    
   The inter-AS PCE-based solution SHOULD provide the capability of 
   MPLS fast reroute around a link or node failure. The link or node 
   could be internal to an AS or at an AS boundary.  
    
  5.1.4. Hierarchical MPLS 
    
   The inter-AS PCE solution SHOULD allow for tunneling inter-AS LSPs 
   within other intra-AS and inter-AS LSPs. Such tunneling is expected 
   to be transparent to an inter-AS PCE when it happens within an AS. 
   In other cases, an inter-AS LSP may be configured between two ASBRs 
   separated by one or more ASes. If such an LSP is made available to 
   the inter-AS PCE, serving the AS of the head-end, along with 
   available resource information the inter-AS PCE SHOULD be able to 
   consider this LSP as shortcut between the ASes of the head-end and 
   tail-end ASBRs and consider it a link between the two ASes for path 
   computation purposes. If this tunnel is used as an IP link and the 
   two nodes at the head-end and tail-end of that LSP are direct BGP 
   peers over that tunnel, then normal procedures for inter-AS path 
   computation are used. Such tunnels may exists between any ASes, 
   including intermediate ASes and terminating ASes. 
    
   The need for supporting hierarchical MPLS in a single provider 
   environment could stem from the need to provide a scalable 
   solution, by reducing the number of LSPs exposed in intermediate 
   ASes and the associated state and dynamism.  
       
  5.1.5. Scalability and Performance Requirements 
    
   When evaluating a particular solution or comparing solutions that 
   address aspects of inter-AS PCE, the following scalability and 
   performance criteria SHOULD be considered: 
    
   - Message load on the inter-AS PCEs and intra-AS PCEs. 
    

 
Bitar et al.                                                 [Page 19] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   - Resulting optimality of the computed end-end LSP path under 
   stated network conditions and constraints and comparison to 
   [INTERD-TE-PDPC] mechanisms 
    
   - Inter-AS (G)MPLS-TE LSP setup time 
    
   - Minimization of the need for crankback 
    
   - Ensuring that the LSP will be setup if there is a path that 
   satisfies the constraints set for that LSP 
   - Node and link protection capability including ASBR and inter-ASBR 
   link failures using MPLS fast reroute mechanisms, end-end path 
   protection via paths with disjoint routes, segment-based protection 
   via disjoint path segments across one or more ASs. 
    
   - The capability to operate in a PCE-enabled and PCE-free 
   environment and interworking with existing(G)MPLS-TE mechanisms 
    
   - No added complexity to network routing by the inter-AS PCE 
    
   - Scalability with network size and its effect on PCC/PCE-PCE 
   sessions 
    
   - Added complexity and features to the PCC/PCE-PCE communication 
   protocol 
    
   - Added complexity and features to the inter-AS PCE discovery 
   protocol  
   Added complexity and features on signaling    
    
  5.1.6. Complexity and Risks 
    
   The proposed solution(s) SHOULD NOT introduce unnecessary 
   complexity to the current operating network to such a degree that 
   it would affect the stability and diminish the benefits of 
   deploying such a solution over SP networks.  
    
  5.1.7. Management, Aliveness Detection and Recovery Requirements 
    
   Especially, in terms of MIB, inter-AS PCEs should support a 
   specific inter-AS traffic engineering MIB as specified in section 
   5.1.10.1 of [INTERAS-TE-REQ]. This MIB relates to security 
   consideration in this document. The new MIB module must provide 
   trap functions when thresholds are crossed or when important events 
   occur for inter-AS PCEs. 
    
   The built-in diagnostic tools must detect failures of PCC/PCE-PCE 
   PCECP and allow checking the status of PCECP related to inter-AS 
   PCEs. The new MIB module should support the status of PCECP related 
   to inter-AS PCEs. Here, it is assumed that inter-AS PCEs exist in 
   different AS or different SP administrative domains.  
    
 
Bitar et al.                                                 [Page 20] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   Basic aliveness detection for PCC/PCE-PCE communication is 
   described in [PCECP-REQ]. Specifically, the PCECP must allow an 
   inter-AS PCE to check the liveliness of the neighboring inter-AS 
   PCE(s) it is using for an inter-AS TE path computation, and a 
   neighboring inter-AS PCE(s) to check the liveliness of an inter-AS 
   PCE it is serving. 
    
   Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an 
   inter-AS PCE must address inter-AS PCE-inter-AS PCE communication 
   failure response. It must be defined how an inter-AS PCE deals with 
   the failures of neighboring inter-AS PCEs. It is recommended that 
   an inter-AS PCE selects another neighboring inter-AS PCE that serve 
   the same or group of ASes so that to obtain equivalent coverage, on 
   detection of an inter-AS PCE failure or non-rechability of an 
   inter-AS PCE. But note that inter-AS PCE selection procedure is out 
   of the scope in this document.  
    
   Basic protocol recovery is described in [PCECP-REQ]. PCC/PCE-PCE 
   communication protocol must support resynchronization of 
   information and requests between inter-AS PCEs, and this should be 
   arranged in order to minimize repeated data transfer.  
    
     
5.2. Requirements Across SP Administrative Domains 
    
   The inter-AS PCE requirements for PCECP for inter-providers case 
   SHOULD include all requirements discussed in section 6.1 above in 
   addition to those discussed in this section here. 
    
   Please also note that the SP with multiple ASes may choose not to 
   include inter-provider inter-AS PCE requirements presented here in 
   its inter-AS TE implementation within its own administrative 
   domain. 
    
  5.2.1. Confidentiality 
    
   Each SP will in most cases maintain its own PCEs, some scoped for 
   intra-provider inter-AS within its own administrative domain and 
   some are specifically designated for inter-provider inter-As TE LSP 
   path computation.  Among the inter-provider scoped inter-AS PCEs in 
   each SP domain, there may also be a subset of the PCEs specifically 
   enabled for path computation across one or specific set of ASes of 
   different SPs.    
    
   In addition to the generic requirement of limiting discovery scope 
   and inter-domain path computation capability for both PCCs and PCEs 
   covered in section 5.1 and 5.2 of [PCEDP-REQ], and specifically to 
   the inter-provider inter-AS application, the PCE discovery 
   mechanism SHOULD have the ability to support the following 
   requirements: 
    

 
Bitar et al.                                                 [Page 21] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   - Hiding all intra-AS PCEs or PCEs with internal scope and 
   capability information not required for inter-AS path computation 
   for one or a set of peering AS(es).  This requirement may be 
   enforced in conjunction with the inter-PCE policies across the AS 
   boundaries as detailed in the next section, Policy Controls. 
    
   - Also as required in section 5.2.1 of [INTERAS-TE-REQ], the PCE 
   solutions SHOULD include the ability to carry out path computations 
   for an optimum inter-AS TE LSP across AS boundaries while 
   preserving the path confidentiality in its own AS.   
    
   In other words, the PCE should be able to compute the inter-AS TE 
   LSP across AS boundaries without detailed knowledge of the list of 
   hops, TE link metrics and paths within each transit AS.  For each 
   partial inter-AS LSP path a PCE computes, it should return to its 
   peering PCE in the upstream neighbor AS(es) an inter-AS TE LSP 
   segment from its own AS without detailing the explicit intra-AS 
   hops plus partial paths with an aggregated TE LSP cost it receives 
   from its downstream PCE.  
     
  5.2.2. Policy Controls 
    
   Section 5.2.2. of [INTERAS-TE-REQ] discusses the policy control 
   requirements on the inter-AS RSVP-TE signaling at the AS boundaries 
   for the enforcement of interconnect agreements, attribute/parameter 
   translation and security hardening.   
    
   This section discusses those policy control requirements 
   specifically for PCECP at the PCE control plane level.  Please note 
   that SPs may still require ingress policy controls on the actual 
   signaling paths mentioned above to enforce their bilateral or 
   multi-lateral agreements at the AS boundaries. 
    
  5.2.2.1. Inter-AS PCE Peering Policy Controls 
    
   As mentioned in section 5.2.1 above, the PCE discovery protocol 
   SHOULD have the ability to control PCE scope and inter-AS 
   computation capabilities to be discovered by PCCs or PCEs from 
   other AS(es).  The following provides some parameters which could 
   be controlled during discovery for PCCs or PCEs from upstream 
   neighboring AS(es): 
    
   - PCE scope and path computation domains: one or a set of ASNs for 
   which it can compute inter-AS TE LSP paths    
    
   - The capability to compute inter-AS TE paths with other ASes that 
   are not part of the originating AS transit path; for example, AS1 
   has requested AS2 to be the transit to AS3 but not AS4, therefore 
   AS2 will exclude the path computation capability to AS4 during the 
   PCE discovery between AS1 and AS2. 
    

 
Bitar et al.                                                 [Page 22] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   - Certain type of link and path constraints; for example, AS2 only 
   agrees to allow its PCEs scoped for AS1 only considering bandwidth 
   with certain sets of affinities and DS-TE class types - then all 
   other capabilities of AS2's PCE will be excluded during the 
   discovery between AS1 and AS2 
    
   - Re-optimization capabilities: for example, if the inter-AS TE 
   segment is a statically stitched or nested LSP-segments which would 
   not allow for re-optimization. 
    
   - FRR capabilities for inter-AS paths: link, node or bandwidth 
   protection for inter-AS TE LSP paths 
   DS-TE TE class <class-type, Preemptions>: SPs may have their own 
   class-type and preemption definitions. Thus, advertised TE class 
   capability should be translated to ones native to the requesting 
   ASes. This is discussed in previous sections 
    
   The PCE communications protocol SHOULD have the ability to enforce 
   on the incoming PCE requests policies on a set of parameters listed 
   in section 5.2.2.1 of [INTERAS-TE-REQ] in addition to the PCE scope 
   and path computation domains. 
    
   Please note that the PCEDP and PCECP SHOULD provide the ability to 
   allow the discovery and enforcement of different information sets 
   for PCCs and PCEs from different AS(es). 
    
   For path computation requests that are not compliant with 
   configured policies, the policy enforcing PCE SHOULD generate a 
   path error message to the requesting PCC or PCE indicating the 
   cause of errors. 
    
  5.2.2.2. Inter-AS PCE Reinterpretation Polices 
    
   Each SP may have different definitions in its use of for example, 
   RSVP-TE session attributes, DS-TE TE classes, etc.  The PCEs 
   receiving these path requests need to be able to reinterpret some 
   of attributes and adapt them to the native environment in its own 
   AS for path computation.  A list of such parameters subject to 
   policy reinterpretation can be found in section 5.2.2.2 of 
   [INTERAS-TE-REQ].  Also the transit SPs along the inter-AS TE path 
   may be a GMPLS transport provider which may require 
   reinterpretation of MPLS specific PCE path request message for path 
   computation over a GMPLS network.  
    
   The PCECP implementation SHOULD allow for the policy enforcing PCEs 
   to reinterpret some of these parameters in the incoming PCC or PCE 
   requests from other AS(es) for its own AS TE implementations or to 
   signal to PCEs in the downstream AS(es).   
    
    
    

 
Bitar et al.                                                 [Page 23] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


6. Security Considerations 
    
   Security concerns arise between any two communicating elements 
   especially when the elements belong to different administrative 
   entities. In this case, there are security concerns that need to be 
   addressed for communication among inter-AS PCEs and other PCEs in a 
   single SP administrative domain as well among inter-AS PCEs under 
   different SP administrative domains. To address these security 
   conerns, Inter-AS PCEs should have the following means for setting 
   up inter-AS traffic engineering LSPs: 
    
   authentication, permission and rejection for path computation 
   requests: 
    
   In a multi-SP administrative domain environment, SPs want to 
   authenticate inter-AS path computation requests to confirm whether 
   they should trust the requests or  not. They also want to allow or 
   deny the requests after inter-AS PCEs authenticate them.   
    
   In case multiple ASes exist within a single SP administrative 
   domain, the SP may authenticate inter-AS path computation requests 
   to confirm whether they should trust the requests or not depending 
   on SP's policy. And they may allow or deny the requests after 
   inter-AS PCEs authenticate them. 
    
   Inter-AS PCEs should be able to authenticate inter-AS path 
   computation requests and confirm whether they should allow or deny 
   them.  
     
   - Confidentiality: in a multi-SP administrative domain environment, 
   SPs want to hide their network topologies for security reasons. 
   Inter-AS PCEs should be able to hide the set of the hops within an 
   AS. See the section 5.2.1 in this document and section 5.2.1 of 
   [INTERAS-TE-REQ].  
    
   - Policy control: In a multi-SP administrative domain environment, 
   each SP itself has some policies for a (G)MPLS-TE enabled network. 
   An inter-AS PCE sends path computation requests which with some 
   parameter to its neighboring inter-AS PCEs. In terms of parameters, 
   see section 5.2.2.1 of [INTERAS-TE-REQ]. In this case, an inter-AS 
   PCE enforces some policies applied to its neighboring inter-AS PCEs 
   that may include rewriting some of the parameter values or 
   rejecting requests based on some parameters’ values. Inter-AS PCEs 
   should have the ability to exclude and/or filter internal scope and 
   capability information. In case multiple ASes exist within a SP 
   administrative domain, the above may be applied. 
    
   - Traffic policing: In multi-SP administrative domain environment 
   or in case multiple ASes exist within a single SP administrative 
   domain, inter-AS PCEs may receive a large number of PCE requests 
   within a short time. inter-AS PCEs should be able to limit the 
   amount of PCE requests. 
 
Bitar et al.                                                 [Page 24] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


    
   - Protection from DoS attacks: In multi-SP administrative domain 
   environment, inter-AS PCEs may be subject to malicious DoS attacks. 
   They should have functions to protect from such attacks. 
    
   - PCC/PCE spoofing: In multi-SP administrative domain enviornmrnt, 
   inter-AS PCEs have the possibility of spoofing the PCE-PCE 
   communication. Inter-AS PCEs should have functions to avoid 
   spoofing a PCE-PCE communication. 
    
7. Author’s Addresses 
       
      Nabil Bitar 
      Verizon 
      40 Sylvan Road 
      Waltham, MA 02145 
      Email: nabil.bitar@verizon.com 
    
      Dean Cheng 
      Cisco Systems Inc. 
      3700 Cisco Way 
      San Jose CA 95134 USA 
      Phone: +1 408 527 0677 
      Email: dcheng@cisco.com 
      
      Kenji Kumaki 
      KDDI Corporation 
      Garden Air Tower 
      Iidabashi, Chiyoda-ku, 
      Tokyo 102-8460, JAPAN 
      Phone: +81-3-6678-3103 
      Email: ke-kumaki@kddi.com 
    
      Eiji Oki  
      NTT  
      Midori-cho 3-9-11  
      Musashino-shi, Tokyo 180-8585,   
      JAPAN  
      Email: oki.eiji@lab.ntt.co.jp 
    
      Raymond Zhang 
      BT INFONET Services Corporation 
      2160 E. Grand Ave. 
      El Segundo, CA 90245 USA 
      Email: Raymond_zhang@bt.infonet.com 
    
8. Normative References 
    
   [INTERAS-TE-REQ] Zhang and Vasseur, “MPLS Inter-AS Traffic 
   Engineering requirements”, draft-ietf-tewg-interas-mpls-te-req-
   09.txt, March 2005 (Work in Progress; RFC Editor’s Queue) 
       
 
Bitar et al.                                                 [Page 25] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


   [PCE-ARCH] Farrel, Vasseur & Ash, “Path Computation Element (PCE) 
   Architecture”, draft-ietf-pce-architecture-02.txt, March 2006 (Work 
   in Progress) 
    
   [PCECP-REQ] J. Ash, J.L Le Roux et al., “PCE Communication Protocol 
   Generic Requirements”, draft-ietf-pce-comm-protocol-gen-reqs (work 
   in progress). 
    
   [PCEDP-REQ] J.L. Le Roux et al., “Requirements for Path Computation 
   Element (PCE) Discovery”, draft-ietf-pce-discovery-reqs (work in 
   progress). 
    
   [TE-REQ] Awduche et. al., "Requirements for Traffic Engineering 
   over MPLS", RFC2702, September 1999. 
    
    
   [TE-RSVP] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP 
   Tunnels", RFC 3209, December 2001 
    
   [INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, “A Per-domain path 
   computation method for computing Inter-domain Traffic Engineering 
   (TE) Label Switched Path (LSP)”, draft-ietf-ccamp-inter-domain-pd-
   path-comp-00.txt , October 2005, (Work in Progress) 
    
9. Informative References 
    
   [INTERD-TESIG] Ayyangar and Vasseur, “Inter domain GMPLS Traffic 
   Engineering - RSVP-TE extensions”, draft-ietf-ccamp-inter-domain-
   rsvp-te-02.txt, April 2006 (Work in Progress) 
    
   [ISP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with 
   Generalized MPLS TE", (work in progress). 
    
   [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with 
   Generalized MPLS TE", (work in progress)) 
    
   [GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label 
   Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
   Engineering (RSVP-TE) Extensions, RFC 3473, January 2003.  
       
10. Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005).  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 AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
 
Bitar et al.                                                 [Page 26] 
  
Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt  October 2005 


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






















 
Bitar et al.                                                 [Page 27]