PCE Working Group                                                D. King
Internet Draft                                        Old Dog Consulting
Intended status: Informational                                 J. Meuric
Expires: October 18, 2011                                      O. Dugeon
                                                          France Telecom
                                                                 Q. Zhao
                                                     Huawei Technologies
                                                  Oscar Gonzalez de Dios
                                          Francisco Javier Jimenex Chico
                                                          Telefonica I+D
                                                          April 18, 2011

     Applicability of the Path Computation Element to Inter-Area and
           Inter-AS MPLS and GMPLS Traffic Engineering

          draft-ietf-pce-inter-area-as-applicability-01


   Abstract

   The Path Computation Element (PCE) may be used for computing services
   that traverse multi-area and multi-AS Multiprotocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.

   This document examines the applicability of the PCE architecture,
   protocols, and protocol extensions for computing multi-area and
   multi-AS paths in MPLS and GMPLS networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 18, 2011.



D. King, et al.        Expires October 18, 2011              [Page 1]


Internet-Draft                                           April   2011


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1. Introduction.................................................3
   1.1. Domains....................................................4
   1.2. Path Computation...........................................5
   1.3. Traffic Engineering Aggregation and Abstraction............5
   1.4. Traffic Engineered Label Switched Paths....................5
   1.5. Inter-area and Inter AS Connectivity Discovery.............5
   2. Terminology..................................................6
   3. Issues and Considerations....................................6
      3.1 Multi-homed domains......................................6
      3.2 Domain meshes............................................6
      3.3 Destination location.....................................6
   4. Applicability of the PCE to Inter-area Traffic Engineering...7
      4.1. Inter-area Routing......................................7
      4.1.1. Area Inclusion and Exclusion..........................7
      4.1.2. Strict Explicit Path and Loose Path...................7
      4.1.3. Inter-Area Diverse Path Computation...................7
      4.2. Control and Recording of Area Crossing..................7
      4.3. Inter-Area Policies ....................................7
      4.4. Loop Avoidance .........................................7
   5. Applicability of the PCE to Inter-AS Traffic Engineering.....7
      5.1. Inter-AS Routing........................................8
      5.1.1. AS Inclusion and Exclusion............................8
      5.1.2. Strict Explicit Path and Loose Path...................8
      5.1.3. AS Inclusion and Exclusion............................8
      5.2. Inter-AS Bandwidth Guarantees...........................8
      5.3. Inter-AS Recovery.......................................9
      5.4. Inter-AS PCE Peering Policies...........................9
   6. Multi-Domain PCE Deployment..................................9
      6.1 Overview of Techniques...................................10
      6.2 Traffic Engineering Database.............................10


D. King, et al.        Expires October 18, 2011              [Page 2]


Internet-Draft                                             April 2011


      6.3 Provisioning Techniques..................................11
      6.4 Pre-Planning and Management-Based Solutions..............11
      6.5 Per-Domain Computation...................................11
      6.6 Cooperative PCEs.........................................11
      6.7 Hierarchical PCEs  ......................................12
   7. Domain Topologies............................................12
      7.1 Selecting Domain Paths...................................12
      7.2 Multi-Homed Domains......................................12
      7.3 Domain Meshes............................................12
      7.4 Route Diversity..........................................12
      7.5 Synchronized Path Computations...........................12
   8. Domain Confidentiality.......................................13
      8.1 Loose Hops...............................................13
      8.2 Confidential Path Segments and Path Keys.................13
   9. Point-to-Multipoint..........................................13
   10. Optical Domains.............................................13
   10.1. PCE applied to the ASON Architecture......................14
   11.1. Policy Control............................................14
   11.1.1 Inter-AS PCE Peering Policy Controls.....................14
   12. IANA Considerations.........................................15
   13. References..................................................15
   13.1. Normative References......................................15
   13.2. Informative References....................................15
   14. Acknowledgements............................................16
   15. Author's Address............................................17


1. Introduction

   Computing paths across large multi-domain environments may
   require special computational components and cooperation between
   entities in different domains capable of complex path computation.
   The Path Computation Element (PCE) [RFC4655] provides an architecture
   and a set of functional components to address this problem space.

   Computing optimal routes for LSPs that cross domains in MPLS-TE and
   GMPLS networks presents a problem because no single point of path
   computation is aware of all of the links and resources in each
   domain. A solution may be achieved using the PCE architecture
   [RFC4655].

   A domain can be defined as a separate administrative, geographic, or
   switching environment within the network. A domain may be further
   defined as a zone of routing or computational ability. Under these
   definitions a domain might be categorized as an Antonymous System
   (AS) or an Interior Gateway Protocol (IGP) area ( as per [RFC4726]
   and [RFC4655]).




D. King, et al.        Expires October 18, 2011                [Page 3]


Internet-Draft                                               April 2011


   A PCE may be used to compute end-to-end paths across multi-domain
   environments using a per-domain path computation technique [RFC5152].
   The so called backward recursive path computation (BRPC) mechanism
   [RFC5441] defines a PCE-based path computation procedure to compute
   inter-domain constrained (G)MPLS TE LSPs. However, both per-domain
   and BRPC techniques assume that the sequence of domains to be crossed
   from source to destination is known, either fixed by the network
   operator or obtained by other means. In more advanced deployments
   (including multi-area and multi-AS environments) the sequence of
   domains may not be known in advance and the choice of domains in the
   end-to-end domain sequence might be critical to the determination of
   an optimal end-to-end path

   In this case the use of the Hierarchical PCE [H-PCE] architecture and
   mechanisms may be used to discovery the intra-area path and select
   the optimal end-to-end domain sequence.

   This document examines the applicability and describes the processes
   and procedures available when using the PCE architecture, protocols
   and protocol extensions for computing inter-area and inter-AS MPLS
   Traffic Engineered paths.

1.1 Domains

   For the purposes of this document, a domain is considered to be a
   collection of network elements within an area or AS that has a common
   sphere of address management or path computational responsibility.
   Wholly or partially overlapping domains are not within the scope of
   this document.

   In the context of GMPLS, a particularly important example of a domain
   is the Automatically Switched Optical Network (ASON) subnetwork
   [G-8080]. In this case, computation of an end-to-end path requires
   the selection of nodes and links within a parent domain where some
   nodes may, in fact, be subnetworks. Furthermore, a domain might be an
   ASON routing area [G-7715]. A PCE may perform the path computation
   function of an ASON routing controller as described in [G-7715-2].

   It is assumed that the PCE architecture should be applied to small
   inter-domain topologies and not to solve route computation issues
   across large groups of domains, I.E. the entire Internet.

1.2 Path Computation

   For the purpose of this document it is assumed that the
   path computation is the sole responsibility of the PCE as per the
   architecture defined in [RFC4655]. When a path is required the Path
   Computation Client (PCC) will send a request to the PCE. The PCE will
   apply the required constraints and compute a path and return a


D. King, et al.        Expires October 18, 2011                [Page 4]


Internet-Draft                                               April 2011


   response to the PCC. In the context of this document it maybe
   necessary for the PCE to co-operate with other PCEs in adjacent
   domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE
   (as per [H-PCE]).

   It is entirely feasible that an operator could compute a path across
   multiple domains without the use of a PCE if the relevant domain
   information is available to the network planner or network management
   platform. The definition of what relevant information is required to
   perform this network planning operation and how that information is
   discovered and applied is outside the scope of this document.

1.3 Traffic Engineering Aggregation and Abstraction

   Networks are often constructed from multiple areas or ASs that are
   interconnected via multiple interconnect points. To maintain
   network confidentiality and scalability TE properties of each area
   and AS are not generally advertized outside each specific area or AS.

   TE aggregation or abstraction provide mechanism to hide information
   but may cause failed path setups or the selection of suboptimal
   end-to-end paths [RFC4726]. The aggregation process may also have
   significant scaling issues for networks with many possible routes
   and multiple TE metrics. Flooding TE information breaks
   confidentiality and does not scale in the routing protocol.

   The PCE architecture and associated mechanisms provide a solution
   to avoid the use of TE aggregation and abstraction.

1.4 Traffic Engineered Label Switched Paths

   This document highlights the PCE techniques and mechanisms that exist
   for establishing TE packet and optical LSPs across multiple areas
   (inter-area TE LSP) and ASs (inter-AS TE LSP). In this context and
   within the remainder of this document, we consider all LSPs to be
   constraint-based and traffic engineered.

   Three signaling options are defined for setting up an inter-area or
   inter-AS LSP [RFC4726]:

      - Contiguous LSP
      - Stitched LSP
      - Nested LSP

   All three signaling methods are applicable to the architectures and
   procedures discussed in this document.

1.5 Inter-area and Inter AS Connectivity Discovery



D. King, et al.        Expires October 18, 2011              [Page 5]


Internet-Draft                                             April 2011


   When using a PCE-based approach for inter-area and inter-AS path
   computation, a PCE in one area or AS may need to learn information
   related to inter-AS capable PCEs located in other ASs. The PCE
   discovery mechanism defined in [RFC5088] and [RFC5089] allow
   the discovery of PCEs and disclosure of information related to
   inter-area and inter-AS capable PCEs across area and AS boundaries.


2. Terminology

   Terminology used in this document.

   ABR: IGP Area Border Router, a router that is attached to more than
   one IGP area.

   ASBR: Autonomous System Border Router, a router used to connect
   together ASs of a different or the same Service Provider via one or
   more inter-AS links.

   Inter-area TE LSP: A TE LSP whose path transits through two or more
   IGP areas.

   Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or
   more ASs or sub-ASs (BGP confederations

   LSP: Traffic Engineered Label Switched Path.

   LSR: Label Switching Router.

   TED: Traffic Engineering Database, which contains the topology and
   resource information of the domain.  The TED may be fed by Interior
   Gateway Protocol (IGP) extensions or potentially by other means.

   This document also uses the terminology defined in [RFC4655] and
   [RFC5440].


3. Issues and Considerations

3.1 Multi-homed domains

3.2 Domain meshes

3.3 Destination location


4. Applicability of the PCE to Inter-area Traffic Engineering




D. King, et al.        Expires October 18, 2011              [Page 6]


Internet-Draft                                             April 2011


   As networks increase in size and complexity it may be required to
   introduce scaling methods to reduce the amount information flooded
   within the network and make the network more manageable. An IGP
   hierarchy is designed to improve IGP scalability by dividing the
   IGP domain into areas and limiting the flooding scope of topology
   information to within area boundaries. This restricts visibility of
   the area to routers in a single area. If a router needs to compute a
   route to destination located in another area a method is required to
   compute a path across area boundaries.

   In order to support multiple vendors in a network, in cases where
   data and/or control plane technologies cannot interoperate, it is
   useful to divide the network in vendor domains. Each vendor domain is
   an IGP area, and the flooding scope of the topology (as well as any
   other relevant information) is limited to the area boundaries.

   Per-domain path computation [RFC5152] exists to provide a method of
   inter-area path computation. The per-domain solution is based on
   loose hop routing with an Explicit Route Object (ERO) expansion on
   each Area Border Router (ABR).  This allows an LSP to be established
   using a constrained path, however at least two issues exist:

   - This method does not guarantee an optimal constrained path

   - The method may require several crankback signaling messages
     increasing signaling traffic and delaying the LSP setup

   The PCE-based architecture [RFC4655] is designed to solve inter-area
   path computation problems. The issue of limited topology visibility
   is resolved by introducing path computation entities that are able to
   cooperate in order to establish LSPs with source and destinations
   located in different areas.

4.1. Inter-area Routing

4.1.1. Area Inclusion and Exclusion

4.1.2. Strict Explicit Path and Loose Path

4.1.3. Inter-Area Diverse Path Computation

4.2. Control and Recording of Area Crossing

4.3. Inter-Area Policies

4.4. Loop Avoidance


5. Applicability of the PCE to Inter-AS Traffic Engineering


D. King, et al.        Expires October 18, 2011              [Page 7]


Internet-Draft                                             April 2011


   As discussed in section 4 (Applicability of the PCE to Inter-area
   Traffic Engineering) it is necessary to divide the network into
   smaller administrative domains, or ASs. If an LSR within an AS needs
   to compute a path across an AS boundary it must also use an inter-AS
   computation technique. [RFC5152] defines mechanisms for the
   computation of inter-domain TE LSPs using network elements along the
   signaling paths to compute per-domain constrained path segments.

   The PCE was designed to be capable of computing MPLS and GMPLS paths
   across AS boundaries. This section outlines the features of a
   PCE-enabled solution for computing inter-AS paths.

5.1 Inter-AS Routing

5.1.1. AS Inclusion and Exclusion

5.1.2. Strict Explicit Path and Loose Path

   During path computation, the PCE architecture and BRPC algorithm
   allow operators to specify if the resultant LSP must follow a strict
   or a loose path. By explicitly specify the path, the operator
   request a strict explicit path which must pass through one or many
   LSR. If this behaviour is well define and appropriate for inter-area,
   it implies some topology discovery for inter-AS. So, this feature
   when the operator owns several ASs (and so, knows the topology of
   its ASs) or restricts to the well-known ASBR to avoid topology
   discovery between operators. The loose path, even if it does not
   allow granular specification of the path, protects topology
   disclosure as it not obligatory for the operator to disclose
   information about its networks.

5.1.3. AS Inclusion and Exclusion

   Like explicit and loose path, [RFC5441] allows to specify inclusion
   or exclusion of respectively an AS or and ASBR. Using this method,
   an operator might decide if an AS must be include or exclude from
   the inter-AS path computation. Exclusion and/or inclusion could also
   be specified at any step in the LSP path computation process by a PCE
   (within the BRPC algorithm) but the best practice would be to specify
   them at the edge. In opposition to the strict and loose path, AS
   inclusion or exclusion doesn't impose topology disclosure as ASs are
   public entity as well as their interconnection.

5.2 Inter-AS Bandwidth Guarantees

   Many operators with multi-AS domains will have deployed MPLS-TE
   Diffserv either across their entire network or at the domain
   edges on CE-PE links. In situations where strict QOS bounds are
   required, admission control inside the network may also be required.


D. King, et al.        Expires October 18, 2011              [Page 8]


Internet-Draft                                             April 2011


   When the propagation delay can be bounded, the performance targets,
   such as maximum one-way transit delay may be guaranteed by providing
   bandwidth guarantees along the Diffserv-enabled path.

   One typical example of this requirement is to provide bandwidth
   guarantees over an end-to-end path for VoIP traffic classified as EF
   (Expedited Forwarding) class in a Diffserv-enabled
   network. In the case where the EF path is extended across multiple
   ASs, inter-AS bandwidth guarantee would be required.

   Another case for inter-AS bandwidth guarantee is the requirement for
   guaranteeing a certain amount of transit bandwidth across one or
   multiple ASs.

5.3 Inter-AS Recovery

   During path computation, a PCCReq may contains backup LSP
   requirements in order to setup in the same time the primary and
   backup LSPs. It is also possible to request a backup LSP for a group
   of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So,
   the PCE could be used to trigger computation of backup tunnels in
   order to protect Inter-AS connectivity. Inter-AS recovery
   requirements needs not only PCE protection and redundancy but also
   LSP tunnels protection through FRR mechanisms. Inter-AS PCE
   computation must support the FRR mechanisms and the patch computation
   for backup tunnels for protection and fast recovery.

5.4 Inter-AS PCE Peering Policies

   Like BGP peering policies, inter-AS PCE peering policies is a
   requirement for operator. In inter-AS BRPC process, PCE must
   cooperate in order to compute the end-to-end LSP. So, the AS path
   must not only follow technical constraints e.g. bandwidth
   availability, but also policies define by the operator.

   Typically PCE interconnections at an AS level must follow contract
   obligations, also known as peering agreements. The PCE peering
   policies are the result of the contract negotiation and govern
   the relation between the different PCE.

6. Multi-domain PCE Deployment Options

   The PCE provides the architecture and mechanisms to compute
   inter-area and inter-AS LSPs. The objective of this document is not
   to reprint the techniques and mechanisms available, but to highlight
   their existence and reference the relevant documents that introduce
   and describe the techniques and mechanisms necessary for computing
   inter-area and inter-AS LSP based services.

   An area or AS may contain multiple PCEs:

D. King, et al.        Expires October 18, 2011                [Page 9]


Internet-Draft                                              April 2011


   - The path computation load may be balanced among a set of PCEs to
     improve scalability.

   - For the purpose of redundancy, primary and backup PCEs may be used.

   - PCEs may have distinct path computation capabilities (P2P or P2MP).

   Discovery of PCEs and capabilities per area or AS is defined in
   [RFC5088] and [RFC5089].

   Each PCE per domain can be deployed in a centralized or distributed
   architecture, the latter model having local visibility and
   collaborating in a distributed fashion to compute a path across the
   domain. Each PCE may collect topology and TE information from the
   same sources as the LSR, such as the IGP TED.

   When the PCC sends a path computation request to the PCE, the PCE
   will compute the path across a domain based on the required
   constraints. The PCE will generate the full set of strict hops from
   source to destination. This information, encoded as an ERO, is then
   sent back to the PCC that requested the path. In the event that a
   path request from a PCC contains source and destination nodes that
   are located in different domains the PCE is required to co-operate
   between multiple PCEs, each responsible for its own domain.

   Techniques for inter-domain path computation are described in
   [RFC5152] and [RFC5441], both techniques assume that the sequence of
   domains to be crossed from source to destination is well known. In
   the event that the sequence of domains is not well known, [H-PCE]
   might be used. The sequence could also be retrieve locally from
   information previously stored in the PCE database (preferably in
   the TED) by OSS management or other protocols.

6.1 Overview of Techniques

6.2 Traffic Engineering Database

   TEDs are automatically populated by the IGP-TE like IS-IS-TE or
   OSPF-TE. However, no information related to AS path are provided
   by such IGP-TE. It could be helpful for BRPC algorithm as AS path
   helper, to populate a TED with suitable information regarding
   inter-AS connectivity. Such information could be obtain from
   various sources, such as BGP protocol, peering policies, OSS of the
   operator or from neighbor PCE. In any case, no topology disclosure
   must be impose in order to provide such information.

   In particular, for both inter-area and inter-AS, the TED must be
   populated with all boundary node information suitable to
   establish PCEP protocol with the next PCE in the path.


D. King, et al.        Expires October 18, 2011              [Page 10]


Internet-Draft                                              April 2011


6.3 Provisioning Techniques

   As PCE algorithms rely on information contained in the TED, it
   is possible to populate TED information by means of provisioning. In
   this case, the operator must regularly update and store all suitable
   information in the TED in order for the PCE to correctly compute LSP.
   Such information range from policies (e.g. avoid this LSR, or use
   this ASBR for a specific IP prefix) up to topology information (e.g.
   AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s
   are reserved for EF traffic). Operators may choose the type and
   amount of information they can use to manage their traffic engineered
   network.

   However, some LSPs might be provisioned to link ASs or areas. In this
   case, these LSP must be announced by the IGP-TE in order to
   automatically fulfill the TED.

6.4 Pre-Planning and Management-Based Solutions

   Offline path computation is performed ahead of time, before the LSP
   setup is requested.  That means that it is requested by, or performed
   as part of, a management application.  This model can be seen in
   Section 5.5 of [RFC4655].

   The offline model is particularly appropriate to long-lived LSPs
   (such as those present in a transport network) or for planned
   responses to network failures.  In these scenarios, more planning is
   normally a feature of LSP provisioning.

   This model may also be used where the network operator wishes to
   retain full manual control of the placement of LSPs, using the PCE
   only as a computation tool to assist the operator, not as part of an
   automated network.

   The management based solutions could also be used in conjunction
   with the BRPC algorithm. Operator just computes the AS-Path as
   parameter for the inter-AS path computation request and let each
   PCE along the AS path compute the LSP part on its own domain.

6.5 Per-Domain Computation

   [RFC5152] define the mechanism to compute per-domain path and must be
   used in that condition. Otherwise, BRPC [RFC5441] will be used.

6.6 Cooperative PCEs

   When PCE cooperate to compute an inter-area or inter-AS LSP, both
   [RFC5152] and [RFC5441] could be used.



D. King, et al.        Expires October 18, 2011              [Page 11]


Internet-Draft                                              April 2011


6.7 Hierarchical PCEs

   The [H-PCE] draft defines how a hierarchy of PCEs may be used. An
   operator must define a parent PCE and each child PCE. A parent PCE
   can be announced in the other areas or ASs in order for the parent
   PCE to contact remote child PCEs. Reciprocally, childs PCEs are
   announced in remote areas or ASs in order to be contacted by a
   remote parent PCE. Parent and each child PCE could also be
   provisioned in the TED if they are not announced.


7. Domain Topologies

7.1 Selecting Domain Paths

7.2 Multi-Homed Domains

7.3 Domain Meshes

   Very frequently network domains are composed by dozens or hundreds of
   network elements. These network elements are usually interconnected
   between them in a partial-mesh fashion, to provide survivability
   against dual failures, and to benefit from the traffic engineering
   capabilities from MPLS and GMPLS protocols. A typical node degree
   ranges from 3 to 10 (4-5 is quite common), being the node degree the
   number of neighbors per node.

   Networks are sometimes divided into domains. Some reasons for it
   range from manageability to separation into vendor-specific domains.
   The size of the domain will be usually limited by control plane, but
   it can also be stated by arbitrary design constraints.

7.4 Route Diversity

   Whenever an specific connectivity service is required to have 1+1
   protection feature, two completely disjoint paths must be
   established on an end to end fashion. In a multi-domain environment
   without, this can be accomplished ither by selecting domain
   diversity, or by ensuring divere connection within a domain. In order
   to compute the route diversity, it could be helpful to have SRLG
   information in the domains.


7.5 Synchronized Path Computations

   In some scenarios, it would be beneficial for the operator to rely on
   the capability of the PCE to perform synchronized path computation.

   A non comprehensive list of such cases could be the following:


D. King, et al.        Expires October 18, 2011              [Page 12]


Internet-Draft                                              April 2011


   o Route diversity: computation of two disjoint paths from a source to
     a destination (as drafted in the previous section).

   o Synchronous restoration: joint computation of a set of alternative
     paths for a set of affected LSPs as a consequence of a failure
     event. Note that in this case, the requests will potentially
     involve different source-destination pairs. In this scenario, the
     different path computation requests may arrive at different time
     stamps.

   o Batch provisioning: It is common that the operator sends a set of
     LSPs requests together, e.g in a daily of weekly basis, mainly in
     case of long lived LSPs. In order to optimize the resource usage,
     a synchronized path computation is needed.

   o Network optimization: After some time of operation, the
     distribution of the established LSP paths results in a non optimal
     use of resources. Also, inter-domain policies/agreements may have
     been changed. In such cases, a full (or partial) network planning
     action regarding the interdomain connections will be triggered.
     This will involve the request of potentially a big amount of
     connections.


8. Domain Confidentiality

8.1 Loose Hops

8.2 Confidential Path Segments and Path Keys


9. Point-to-Multipoint

   For the Point-to-Multipoint application scenarios for MPLS-TE LSP,
   the complexity of domain sequences, domain policies, choice and
   number of domain interconnects is magnified comparing to
   P2P path computations. Also as the size of the network grows,
   the number of leaves and branches increase and it in turn puts the
   scalability of the path computation and optimization into a bigger
   issue. A solution for the point-to-multipoint path computations may
   be achieved using the PCEP protocol extension for P2MP
   [RFC6006] and using the PCEP P2MP procedures defined in
   [PCEP-P2MP-INTER-DOMAIN].


10. Optical Domains

   The International Telecommunications Union (ITU) defines the ASON
   architecture in [G-8080]. [G-7715] defines the routing architecture


D. King, et al.        Expires October 18, 2011              [Page 13]


Internet-Draft                                              April 2011


   for ASON and introduces a hierarchical architecture. In this
   architecture, the Routing Areas (RAs) have a hierarchical
   relationship between different routing levels, which means a parent
   (or higher level) RA can contain multiple child RAs. The
   interconnectivity of the lower RAs is visible to the higher level RA.

10.1. PCE applied to the ASON Architecture

   In the ASON framework, a path computation request is termed a Route
   Query. This query is executed before signaling is used to establish
   an LSP termed a Switched Connection (SC) or a Soft Permanent
   Connection (SPC). [G-7715-2] defines the requirements and
   architecture for the functions performed by Routing Controllers (RC)
   during the operation of remote route queries - an RC is synonymous
   with a PCE.

   In the ASON routing environment, a RC responsible for an RA may
   communicate with its neighbor RC to request the computation of an
   end-to-end path across several RAs. The path computation components
   and sequences are defined as follows:

   o Remote route query. An operation where a routing controller
     communicates with another routing controller, which does not have
     the same set of layer resources, in order to compute a routing
     path in a collaborative manner.

   o Route query requester. The connection controller or RC that sends a
     route query message to a routing controller requesting for one or
     more routing path that satisfies a set of routing constraints.

   o Route query responder. An RC that performs path computation upon
     reception of a route query message from a routing controller or
     connection controller, sending a response back at the end of
     computation.

   When computing an end-to-end connection, the route may be computed by
   a single RC or multiple RCs in a collaborative manner and the two
   scenarios can be considered a centralized remote route query model
   and distributed remote route query model. RCs in an ASON environment
   can also use the hierarchical PCE [H-PCE] model to fully match the
   ASON  hierarchical routing model.


11. Security

11.1. Policy Control

11.1.1 Inter-AS PCE Peering Policy Controls



D. King, et al.        Expires October 18, 2011              [Page 14]


Internet-Draft                                              April 2011


   Each PCE cooperating with another PCE in a neighboring AS will need
   to request or enforce policies applicable to the sender of the
   request.

   Parameters that are subject to policy include bandwidth,
   setup/holding priority, Fast Reroute request, Differentiated Services
   Traffic Engineering (DS-TE) Class Type (CT), and others as specified
   in Section 5.2.2.1 of [RFC4216].

11.2. Confidentiality

11.3. Denial of Service Attacks


12. IANA Considerations

   This document makes no requests for IANA action.


13. References

13.1. Normative References

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

     [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
               A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
               "Path Computation Element (PCE) Communication Protocol
               (PCEP)", RFC 5440, March 2009.

13.2. Informative References

     [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
               Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
               2005.

     [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
               Autonomous System (AS) Traffic Engineering (TE)
               Requirements", RFC 4216, November 2005.

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

     [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
               "OSPF Protocol Extensions for Path Computation Element
               (PCE) Discovery", RFC 5088, January 2008.



D. King, et al.        Expires October 18, 2011              [Page 15]


Internet-Draft                                              April 2011


     [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
               Zhang, "IS-IS Protocol Extensions for Path Computation
               Element (PCE) Discovery", RFC 5089, January 2008.

     [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
               Path Computation Method for Establishing Inter-Domain
               Traffic Engineering (TE) Label Switched Paths (LSPs)",
               RFC 5152, February 2008.

     [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
               Computation (BRPC) procedure to compute shortest inter-
               domain Traffic Engineering Label Switched Paths",
               RFC5441, April 2009.

     [G-8080]  ITU-T Recommendation G.8080/Y.1304, Architecture for
               the automatically switched optical network (ASON).

     [G-7715]  ITU-T Recommendation G.7715 (2002), Architecture
               and Requirements for the Automatically Switched
               Optical Network (ASON).

     [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
               architecture and requirements for remote route query.

     [H-PCE]  King, D. and A. Farrel, "The Application of the Path
              Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS & GMPLS", July
              2010.

     [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
              Zhao, Q., King, D., "Extensions to the Path Computation
              Element Communication Protocol (PCEP) for
              Point-to-Multipoint Traffic Engineering Label Switched
              Paths", RFC6006, September 2010.

     [PCEP-P2MP-INTER-DOMAIN]  Ali Z., Zhao, Q., King, D., "PCE-based
              Computation Procedure To Compute Shortest Constrained P2MP
              Inter-domain Traffic Engineering Label Switched Paths",
              draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt,
              work in progress, Januaury, 2011.


11. Acknowledgements

   The author would like to thank Adrian Farrel for his review and
   Meral Shirazipour for his comments.



D. King, et al.        Expires October 18, 2011              [Page 16]


Internet-Draft                                              April 2011


12. Author's Address

   Daniel King
   Old Dog Consulting
   UK
   Email: daniel@olddog.co.uk

   Julien Meuric
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   Email: julien.meuric@orange-ftgroup.com

   Olivier Dugeon
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   Email: olivier.dugeon@orange-ftgroup.com

   Quintin Zhao
   Huawei Technology
   125 Nagog Technology Park
   Acton, MA  01719
   US
   Email: qzhao@huawei.com

   Oscar Gonzalez de Dios
   Telefonica I+D
   Emilio Vargas 6, Madrid
   Spain
   Email: ogondio@tid.es

   Francisco Javier Jimenex Chico
   Telefonica I+D
   Emilio Vargas 6, Madrid
   Spain
   Email: fjjc@tid.es
















D. King, et al.        Expires October 18, 2011              [Page 17]

Internet-Draft                                              April 2011