< draft-bitar-zhang-interas-pce-req-00.txt   draft-bitar-zhang-interas-pce-req-01.txt >
Network Working Group Nabil Bitar (Editor) Network Working Group Nabil Bitar (Editor)
Internet Draft Verizon Internet Draft Verizon
Raymond Zhang (Editor) Raymond Zhang (Editor)
BT InfornetServices BT Infornet
Corporation
Kenji Kumaki (Editor)
KDDI Corporation
Category: Informational Kenji Kumaki (Editor)
Expires: April 2006 KDDI Corporation
October 2005
Inter-AS PCE Requirements Category: Informational
Expires: April 2006
October 2005
draft-bitar-zhang-interas-pce-req-00.txt Inter-AS PCE Requirements
Status of this Memo draft-bitar-zhang-interas-PCE-req-01.txt
By submitting this Internet-Draft, each author represents that any Status of this Memo
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 By submitting this Internet-Draft, each author represents that any
Force (IETF), its areas, and its working groups. Note that other groups applicable patent or other IPR claims of which he or she is aware
may also distribute working documents as Internet-Drafts. 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 draft documents valid for a maximum of six months Internet-Drafts are working documents of the Internet Engineering
and may be updated, replaced, or obsoleted by other documents at any Task Force (IETF), its areas, and its working groups. Note that
time. It is inappropriate to use Internet- Drafts as reference material other groups may also distribute working documents as Internet-
or to cite them other than as "work in progress." Drafts.
The list of current Internet-Drafts can be accessed at Internet-Drafts are draft documents valid for a maximum of six
http://www.ietf.org/ietf/1id-abstracts.txt. 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 Internet-Draft Shadow Directories can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/ietf/1id-abstracts.txt.
Abstract The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document discusses requirements for the support of the Path Abstract
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 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Conventions used in this document
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents 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.
1. Introduction....................................................3 Table of Contents
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.........9
5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE..............10
5.1. Requirements within one SP Administrative Domain.............10
5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability........10
5.1.2. PCC/PCE-PCE Communication Protocol Requirements............10
5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP.............12
5.1.2.2. PCE responses............................................13
5.1.3. PCE Discovery..............................................14
5.1.3.1. Static configuration.....................................14
5.1.3.2. Dynamic Discovery........................................15
5.1.4. PCE: Path Computation......................................15
5.1.4.1. Routing..................................................16
5.1.4.2. Optimality...............................................16
5.1.4.3. Path Re-optimization.....................................17
5.1.4.4. Support of diversely routed inter-AS TE LSP..............17
5.1.5. Hierarchical MPLS..........................................18
5.1.6. Scalability and Performance Requirements...................18
5.1.7. Complexity and Risks.......................................19
5.1.8. Management, Aliveness Detection and Recovery Requirements..19
5.2. Requirements Across SP Administrative Domains................20
5.2.1. Confidentiality............................................20
5.2.2. Policy Controls............................................20
5.2.2.1. Inter-AS PCE Peering Policy Controls.....................21
5.2.2.2. Inter-AS PCE Reinterpretation Polices....................21
6. Security Considerations........................................22
7. Authors’ Addresses.............................................23
8. Normative References...........................................23
9. Informative References.........................................24
10. Full Copyright Statement......................................24
11. Intellectual Property.........................................25
1. Introduction 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
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
MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ] defined 1. Introduction
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 MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]
LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2) Stitched defined the scenarios motivating the deployment of inter-AS MPLS
inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE LSP as in traffic engineering. [INTERAS-TE-REQ] also specified the
[LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines mechanisms for requirements for inter-AS MPLS traffic engineering when the ASes
inter-domain path computation using network elements along the are under one Service Provider (SP) administration or the
signaling and data paths. The mechanisms in [INTERD-TE-PDPC] do not administration of different SPs.
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 Today there are three signaling options in setting up an inter-AS
optimum path than that can be achieved by those provided in [INTERD-TE- TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2)
PDPC] and the capability to separate the path computation elements from Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE
the forwarding elements. 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.
Generic requirements for the PCE discovery protocol (PCEDP) and This document extends on the requirements defined in [INTERAS-TE-
PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP-REQ] REQ] as applied to the PCE [PCE-ARCH], providing an approach for a
and [PCECP-REQ] respectively. Complementary to these already defined more optimum inter-AS TE path computation and potentially
generic requirements, this document provides a set of requirements that minimizing signaling crankbacks.
are specific for inter-AS path computation using a PCE-based approach.
Some of these requirements may become generic requirements if they
apply to other PCE applications.
Section 2 of this document states some definitions. Section 3 defines a The requirements for a PCE have risen from SP needs to compute a
reference model, while section 4 describes use cases of inter-AS path more optimum path than that can be achieved by those provided in
computation using a PCE-based approach. Section 5 states inter-AS PCE [INTERD-TE-PDPC] and the capability to separate the path
requirements when the ASes are under a single SP administrative domain. computation elements from the forwarding elements.
Specifically, the requirements on PCECP, 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 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.
2.1. Definitions 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,
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.
The following provides a list of abbreviations or acronyms specifically 2. Definitions and Requirements Statement
pertaining to this document:
SP: Service Providers including regional or global providers 2.1. Definitions
SP Administrative Domain: a single SP administration over a network The following provides a list of abbreviations or acronyms
or networks that may consist of one AS or multiple ASes. specifically pertaining to this document:
IP/MPLS networks: SP's network where MPLS switching capabilities SP: Service Providers including regional or global providers
and signaling controls are activated in addition to IP routing
protocols.
Intra-AS TE: A generic definition for traffic engineering SP Administrative Domain: a single SP administration over a
mechanisms operating over IP-only and/ or IP/(GMPLS network within network or networks that may consist of one AS or multiple
an AS. ASes.
Inter-AS TE: A generic definition for traffic engineering IP/MPLS networks: SP's network where MPLS switching
mechanisms operating over IP-only and/or IP/(G)MPLS network across capabilities and signaling controls are activated in addition
one or multiple ASes. Since this document only addresses to IP routing protocols.
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 TE: A generic definition for traffic engineering
mechanisms operating over IP-only and/ or IP/(GMPLS network
within an AS.
Intra-AS MPLS-TE: An MPLS Traffic Engineering mechanism where its Inter-AS TE: A generic definition for traffic engineering
Label Switched Path (LSP), Head-end Label Switching Router (LSR), mechanisms operating over IP-only and/or IP/(G)MPLS network
and Tail-end LSR reside in the same AS for traffic engineering across one or multiple ASes. Since this document only
purposes. 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.
Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where its TE LSP: MPLS Traffic Engineering Label Switched Path.
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 Intra-AS MPLS-TE: An MPLS Traffic Engineering mechanism where
different or the same Service Provider via one or more links its Label Switched Path (LSP), Head-end Label Switching Router
between the ASes. (LSR), and Tail-end LSR reside in the same AS for traffic
engineering purposes.
Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where
e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn. its TE LSPs, Head-end LSR and Tail-end LSR do not reside within
the same AS
Inter-AS TE Path Segment: A portion of the Inter-AS TE path. 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 DS-TE: Diffserv-aware Inter-AS TE. Inter-AS TE Path: An TE path traversing multiple ASes and
ASBRs, e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn.
SRLG: A set of links may constitute a 'shared risk link group' Inter-AS TE Path Segment: A portion of the Inter-AS TE path.
(SRLG) if they share a resource whose failure may affect all links
in the set as defined in [GMPLS-ROUT].
PCE: Path computation element Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
PCC: Path computation client 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
PCECP: PCE communication protocol PCC: Path computation client
PCEDP: PCE Discovery Protocol PCECP: PCE communication protocol
Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths PCEDP: PCE Discovery Protocol
traversing a single AS.
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-TE Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths
and/or intra-AS(G)MPLS-TE paths, by possibly cooperating with traversing a single AS.
intra-AS PCEs, across one or more AS(es)
2.2. Objectives and Requirements of Inter-AS Traffic Engineering using PCE 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)
All applications and associated requirements cited in sections 3.2 and 2.2. Objectives and Requirements of Inter-AS Traffic Engineering using
4 in [INTERAS-TE-REQ] for inter-AS traffic engineering hold for inter- PCE
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 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.
Figure 1 depicts the reference model for PCEs in an inter-AS 3. Reference Model
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]).
Inter-AS Inter-AS Inter AS Figure 1 depicts the reference model for PCEs in an inter-AS
PCE1 <--------->PCE2<---------------->PCE3 application. In this document, we define two types of PCE
:: :: :: functions: inter-AS PCEs and intra-AS PCEs. Figure 1 shows the case
R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 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
R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 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
Intra-AS external server that is not part of the routing topology or an LSR
PCE (e.g., ASBR), know as composite PCE, as described in [PCE-ARCH]).
.<==AS1==>. .<====AS2=====>. <=======AS3==>.
Figure 1 Inter and Intra-AS PCE Reference Model Inter-AS Inter-AS Inter AS
In general, an inter-AS PCE is associated with one ore more ASes that PCE1<---------->PCE2<--------------> PCE3
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. R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
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 R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
be implemented and enabled on the same physical device, but scalability ::
requirements and/or security considerations may require their Intra-AS
separation. An inter-AS PCE can be an intermediate-PCE or a PCE
terminating-PCE for a given LSP. An intermediate-PCE is associated with <==AS1=> <====AS2======> <=====AS3===>
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 Figure 1 Inter and Intra-AS PCE Reference Model
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 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 In general, an inter-AS PCE is associated with one ore more ASes
AS of the LSP tail-end computes one or more path in the AS(es) within that define its scope. It receives path computation requests for
its scope by cooperating with intra-AS PCEs. If the immediate requestor (G)MPLS-TE LSPs from PCCs or other inter-AS PCEs and responds to
(e.g., the previous inter-AS PCE) is under another SP administrative these requests. An intra-AS PCE (e.g., inter-area PCE) is one
domain, the inter-AS PCE may not return a path with strict hops (i.e., responsible for path computation within a single AS. It should be
LSP tail-end). What could be returned in the path computation response emphasized that the differentiation between these two PCE types is
is generally controlled by policy configuration. The inter-AS PCE may functional as both can be implemented and enabled on the same
return one or more paths, each of which composed of a list of one or physical device, but scalability requirements and/or security
more ASBRs and/or ASes as loose hops and a cost associated with each considerations may require their separation. An inter-AS PCE can be
path. The returned path(s) must at least include ASBRs connected to the an intermediate-PCE or a terminating-PCE for a given LSP. An
ASes affiliatied with the responding PCE. This process recurses until intermediate-PCE is associated with transit ASes whereas a
the inter-AS PCE serving the LSP head-end receives a response to its terminating-PCE is associated with the AS originating or
request(s) from the immediate inter-AS PCE(s) it sent requests to. terminating the path computation request. If the head-end and tail-
Every time an inter-AS PCE responds to a requestor it concatenates each end of an LSP are in ASes within the scope of a single inter-AS
path it computes with a path it received from the next immediate PCE, PCE, the full path computation can be solely done by that inter-AS
composes a cost for the total path and returns the concatenated path(s) PCE, possibly cooperating with other intra-AS PCEs if it does not
to the previous immediate requestor. It should be noted that the have the full topological and TE knowledge of the ASs within its
path(s) computed by a PCE will be constrained by the path(s) received scope. Otherwise, multiple inter-AS PCEs need to cooperate to
from the next inter-AS PCE(s) and any other constraints in the received compute the LSP path as described in [PCE-ARCH].
request.
If the original PCC (LSR at the head-end of the LSP or proxy) selects a The LSR at the head-end of an LSP or a proxy on its behalf (either
path out of the received ones and the path is composed of strict hops, being a PCC) sends a path computation request to one of its inter-
the head-end LSR will use the signaling procedures defined in [ITERD- AS PCEs upon determining, via configuration or dynamic routing,
TESIG] to signal the LSP with an explicit route object (ERO) consisting that the tail-end is an AS-external destination. There could be one
of these strict hops. There will be no need for computing path segments or more inter-AS PCEs associated with a given LSR AS. The choice of
to loose hops at intermediate nodes. If the path selected by the head- an inter-AS PCE among many can be based on the corresponding
end LSR is composed of strict and loose hops, there needs to be a way destination AS, configuration, and/or load-balancing criteria. An
for an intermediate node to complete the path between that node and the inter-AS PCE in the originating AS sends a path computation request
next loose hop with strict hops. How this is most efficiently done to one or more neighboring AS-PCEs based on the AS through which it
SHOULD be subject for further study. Some possible mechanisms include: 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
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.
a node that needs to acquire a path of strict hops to reach a loose hop In an all-PCE enabled environment, the last inter-AS PCE, serving
specified in the ERO, requests an inter-AS PCE or intra-AS PCE, the AS of the LSP tail-end computes one or more path in the AS(es)
depending on the situation, to compute that path. In this case, the within its scope by cooperating with intra-AS PCEs. If the
original path computation triggered by the LSR head-end would have immediate requestor (e.g., the previous inter-AS PCE) is under
computed that path and the path gets recomputed again during the another SP administrative domain, the inter-AS PCE may not return a
(G)MPLS-TE signaling phase. 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.
In order to avoid the path-segment re-computation in option (1), an If the original PCC (LSR at the head-end of the LSP or proxy)
inter-AS PCE involved in the LSP path computation may store the LSP selects a path out of the received ones and the path is composed of
path-segment it computes for a limited time. Signaling may carry a PCE all strict hops, the head-end LSR will use the signaling procedures
identifier (in case there is more than one PCE serving the ASBR), and defined in [ITERD-TESIG] to signal the LSP with an explicit route
another path-identifier to enable an ASBR to retrieve the path segment object (ERO) consisting of these strict hops. There will be no need
from the PCE. The path-identifier can be an LSP identifier that when for computing path segments to loose hops at intermediate nodes. If
coupled with the requesting ASBR and the next hop in the ERO can the path selected by the head-end LSR is composed of strict and
uniquely identify the path-segment. This approach may require a loose hops, there needs to be a way for an intermediate node to
signaling extension. When a path is retrieved, all other path(s) complete the path between that node and the next loose hop with
associated with that LSP at the PCE could be deleted immediately. In strict hops. How this is most efficiently done SHOULD be subject
order to avoid permanent storage of path-segment(s) at the PCE, there for further study. Some possible mechanisms include:
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.
Alternatively, the inter-AS PCE may communicate to an ASBR the path (1) A node that needs to acquire a path of strict hops to reach a
segment(s) rooted at that ASBR along with the associated LSP loose hop specified in the ERO, requests an inter-AS PCE or intra-
identifier. When the ASBR receives a (G)MPLS-TE path message, it AS PCE, depending on the situation, to compute that path. In this
performs a lookup based on the LSP identifier to identify the path case, the original path computation triggered by the head-end LSR
segment between itself and the next hop in the received ERO. Unused would have computed that path and the path gets recomputed again
path segments at the ASBR could be deleted immediately. The path- during the (G)MPLS-TE signaling phase.
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.
Other mechanisms may also exist. Each of these mechanisms will have (2) In order to avoid the path-segment re-computation in option
associated tradeoffs and may drive requirements on PCECP and/or (1), an inter-AS PCE involved in the LSP path computation may store
signaling. Those types of requirements driven by specific solutions are the LSP path-segment it computes for a limited time. Signaling may
not defined in this document. carry a PCE identifier (in case there is more than one PCE serving
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.
In certain operating environments, PCEs may not be available end to (3) Alternatively, the inter-AS PCE may communicate to an ASBR the
end. Added to that, inter-AS traffic engineering capabilities may not path segment(s) rooted at that ASBR along with the associated LSP
be available end-end. identifier. When the ASBR receives a (G)MPLS-TE path message, it
This document addresses requirements to deal with these situations. 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.
4. Example Application Scenarios 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.
4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional In certain operating environments, PCEs may not be available end to
Networks end. Added to that, inter-AS traffic engineering capabilities may
not be available end-end. This document addresses requirements to
deal with these situations.
A number of application scenarios are discussed in section 4 of 4. Example Application Scenarios
[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 4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional
cases where a global service provider (SP1) would like to extend its Networks
reach into a region using a regional network (SP2) as MPLS transport.
SP1 in these cases would either co-locate its 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)=> A number of application scenarios are discussed in section 4 of
R16(PCE) [INTERAS-TE-REQ] where computing an inter-AS TE LSP path could rely
| on per-domain path computation using procedures documented in
R11(PCC)-R13(PCC)<===>R21-R23-R26(PCE)<===>R15(PCC)-R19-R120 [INTERD-TE-PDPC]. However, as noted above, a per-domain computing
\ /| \ |\ / | \ / | \ / | method does not always yield optimum paths. In this section, we
\ / | \ | \ / | \ / | \_R110 | present a similar inter-AS TE application scenario using PCEs with
\/ | \ | \ / | \ | | | inter-AS scope to compute optimum paths across AS boundaries.
/\ | \ | R24(PCE)| / \ | _R111 |
/ \ | \ | / \R25 | / \ | / \____ |
/ \| || / \ | / \ | / \ |
R12(PCC)-R14(PCC)<===>R22----R27(PCE)<===>R17(PCC)----R121(PCC)
|
R18(PCE)
<=Inter-AS MPLS TE Tunnel T2(R14,R17)=>
<=============Inter-ASS TE Tunnel T3(R11,R121)============>
+=SP1 VPOP/sub=+ +===SP2 As2===+ +=SP1 backbone AS1=+ Section 4.1.1 and section 4.2.2 of [INTERAS-TE-REQ] have presented
network AS1 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
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:
Figure 2: SP1 extended reach linking vPOP or Sub-regional network over <=Inter-AS MPLS TE Tunnel T1(R13,R15)=>
SP2 MPLS Transport R16(PCE)
In the above example diagram, ASBR R13 and R14 as PCCs, dynamically or |
statically discover their corresponding PCE R16 and R18 which maintain R11(PCC)-R13(PCC)<===>R21-R23-R26(PCE)<===>R15(PCC)-R19-R112
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 \ / | \ | \ / | \ / | \_R110 |
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- /\ | \ | R24(PCE)| / \ | _ R111 |
TE tunnel to R121 directly to support a customer voice trunk, for / \ | \ | / \R25 | / \ | / \ |
example. / \| || / \ | / \ | / \ |
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
With per-domain path computation, the three tunnels would be built with Figure 2: SP1 extended reach linking vPOP or Sub-regional network
paths as shown below assuming all links with metric value of 1 and over SP2 MPLS Transport
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- In the above example diagram, ASBR R13 and R14 as PCCs, dynamically
R26-R15; or statically discover their corresponding PCE R16 and R18 which
- T2's path: (R22,R17) expanding at R22 to have the path R14-R22-R27- maintain meshed peering with AS2 PCE R26 and R27, respectively.
R17; They then send PCC/PCE path requests to their own primary PCEs (R16
- T3's path: (R21,R114) expanding at R21 to have the path R11-R13-R21- or R18) for two optimum yet diversified inter-AS paths for
R23-R26-R15-R17-R114 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.
For T1 and T2, the requirement for diversifications is paramount where With per-domain path computation, the three tunnels would be built
R26 and R27 will need to maintain both synchronized states of both T1 with paths as shown below assuming all links with metric value of 1
and T2 in order to compute two diverse routes between these two inter- and inter-AS links between ASes with the same maximum reservable
AS TE LSPs where their HEAD-ENDs and TAIL-ENDs are terminated on the bandwidth:
same pair of ASes (exactly the same ASN in this case).
For T3, a more optimum path should be R11-R14-R22-R27-R17-R114 which - T1's path: (R21,R15) expanding at R21 to have the path R13-R21-
can be obtained through AS1 PCEs (R16 or R17) where R22 and R17 are R23-R26-R15;
selected as better exits for neighbor ASes. - 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
In this environment, PCE R24 in AS2 is only for intra-AS TE path For T1 and T2, the requirement for diversifications is paramount
computation while R26 and R27 are intra-AS PCEs as well as inter-AS where R26 and R27 will need to maintain both synchronized states of
PCEs for AS1 among others. R16 and R17 are dedicated routers running both T1 and T2 in order to compute two diverse routes between these
PCE process for AS2. 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).
Please note that we could also configure R13 and R14 as PCEs as well For T3, a more optimum path should be R11-R14-R22-R27-R17-R114
with direct peering to R26 and R27. In this case, the ASBR routers which can be obtained through AS1 PCEs (R16 or R17) where R22 and
function as the PCE, PCC and the inter-AS tunnel-head end or tail-end R17 are selected as better exits for neighbor ASes.
at the same time.
4.2. Inter-AS Path Computation over a GMPLS Transport Core 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.
This section illustrates a case where inter-AS scoped PCEs are used for Please note that we could also configure R13 and R14 as PCEs as
path computations across a GMPLS transport core. 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.
(PCC) (PCC) 4.2. Inter-AS Path Computation over a GMPLS Transport Core
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 This section illustrates a simplified case where inter-AS scoped
In Figure 3, R1, a PCC sends an MPLS-TE based request message to its PCEs are used for path computations across a GMPLS transport core.
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.
5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE (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===+
This section discusses detailed requirements in two principal areas for Figure 3 Inter-AS TE LSP over a GMPLS Transport Core
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).
5.1. Requirements within one SP Administrative Domain 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.
This section presents detailed PCE requirements for inter-AS (G)MPLS-TE In this application scenario, AS2 is a pure GMPLS core. It is
within the same SP administrative domain. It should be noted that ASes worth noting that AS2 could have outer MPLS edge where the inter-AS
in a single SP administrative domain can have various restrictions and TE LSPs may get aggregated onto the GMPLS TE LSP on the core GMPLS
policies among the ASes, as in the inter-provider case. The additional PSC.
PCE requirements for the inter-provider case are documented in section
5.2.
5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability 5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE
The PCE solution for inter-AS applications SHOULD be consistent with This section discusses detailed requirements in two principal areas
the requirements discussed in [TE-REQ] and [INTERAS-TE-REQ]. The for inter-AS (G)MPLS-TE using a PCE-based approach: 1) requirements
derived solution MUST be such that it will interoperate seamlessly with for inter-AS (G)MPLS-TE in the same SP administrative domain (i.e.,
current intra-area and inter-domain (inter-area and inter-AS)(G)MPLS-TE intra-provider) and 2) requirements for inter-AS (G)MPLS-TE/ across
mechanisms. different SP administrative domains (i.e., inter-provider).
The inter-AS PCE-based solutions MUST interoperate with other .5.1. Requirements within one SP Administrative Domain
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 This section presents detailed PCE requirements for inter-AS
provisioning the TE LSP at the head-end and using (G)MPLS-TE signaling (G)MPLS-TE within the same SP administrative domain. It should be
to signal the LSP to the tail-end residing in another AS traversing, noted that ASes in a single SP administrative domain can have
without any further provisioning requirement, intermediate points along various restrictions and policies among the ASes, as in the inter-
the transit path. provider case. The additional PCE requirements for the inter-
provider case are documented in section 5.2.
5.1.2. PCC/PCE-PCE Communication Protocol Requirements 5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability
Operations in an all-PCE-enabled environment are described in [PCE- The PCE solution for inter-AS applications SHOULD be consistent
ARCH] and, in the case of inter-AS PCE-based path computation, in with the requirements discussed in [TE-REQ] and [INTERAS-TE-REQ].
section 3. There are cases, as stated in section 3, where the The derived solution MUST be such that it will interoperate
environment may not be an all-PCE environment. Figure 4 depicts such a seamlessly with current intra-area and inter-domain (inter-area and
case where AS1 does not have PCEs, whereas AS2 and AS3 do. Thus, when a inter-AS)(G)MPLS-TE mechanisms.
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,
Non PCE PCE PCE The inter-AS PCE-based solutions MUST interoperate with other
Inter-AS Path Inter-AS Path Inter-AS Path mechanisms for path computation to ensure that a path for an LSP
Computaion Computation Computation with TE constraints can be set up across ASes with and without PCE
Scope Scope: AS2/AS3 Scope: AS3/AS2 capabilities.
<----->. .<------->. .<------->.
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 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.
This diagram illustrates an inter-AS (G)MPLS-TE environment composed of 5.1.2. PCC/PCE-PCE Communication Protocol Requirements
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 Operations in an all-PCE-enabled environment are described in [PCE-
next subsections. Following are additional generic requirements to ARCH] and, in the case of inter-AS PCE-based path computation, in
those described in [PCECP-REQ] for PCC/PCE-PCE communication. Some of section 3. There are cases, as stated in section 3, where the
these requirements apply to the process handling PCC/PCE-PCE environment may not be an all-PCE environment. Figure 4 depicts
communication and not the protocol itself: 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,
Non PCE PCE PCE
Inter-AS Path Inter-AS Path Inter-AS Path
Computaion Computation Computation
Scope Scope: AS2/AS3 Scope: AS3/AS2
<------> <--------------> <----------->
An inter-AS PCE must be able to locally prioritize messages on an AS Inter-AS Inter AS
basis in addition to message-level priority. PCE<------------------>PCE
An inter-AS PCE must be able to change the message priority when :: ::
sending a path computation request from the priority it received for R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
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. R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
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 Intra-AS
the two ASes attempting to set an LSP or LSP segment between them use PCE
different class type identifier values. Such a situation may arise when <===AS1=> <=====AS2=====> <======AS3==>
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 Figure 4. Non-PCE and PCE path computation scopes
malicious (could be pretender) PCEs/PCCs who attempt to initiate these
attacks via PCE communication protocol messages. 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 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.
Path computation requests must be able to carry all constraint Requirements specific to requests or responses are discussed in the
attributes necessary for setting up an LSP via (G)MPLS-TE signaling as next subsections. Following are additional generic requirements to
stated in [PCECP-REQ]. A path computation request to an inter-AS PCE or those described in [PCECP-REQ] for PCC/PCE-PCE communication. Some
an ASBR-PCC must be able to specify ASBRs and ASes as strict and loose of these requirements apply to the process handling PCC/PCE-PCE
nodes in the path of the LSP to the destination. A PCE must also be communication and not the protocol itself:
able to specify a preferred ASBR for exiting to the next AS when there
is more than one possibility to reach the destination through a
neighboring AS.
An inter-AS PCE must also be able specify in its request a list of ASes - An inter-AS PCE must be able to locally prioritize messages on an
and/or ASBRs to be excluded in the path computation. In the intra- AS basis in addition to message-level priority.
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 - An inter-AS PCE must be able to change the message priority when
ASes, it should be able to send simultaneous requests to the inter-AS sending a path computation request from the priority it received
PCEs associated with these ASes. The maximum number of inter-AS PCEs, for the same LSP. A notification message should be sent to the
an inter-AS PCE may send simultaneous requests to, SHOULD be requestor indicating that change. Such notification must be
configurable. The choice of inter-AS PCEs could be influenced by suppressed by configuration action on a neighboring inter-AS PCE
policies which prefer some paths over others or some PCEs over others. basis.
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 - An inter-AS PCE must be able to perform translation on class of
specify the AS on whose behalf it is sending the request. This is service identifiers carried in a request/response for a DS-TE
specifically important when the inter-AS PCE has identified many ASes packet LSP when the two ASes attempting to set an LSP or LSP
within its scope to the other inter-AS PCE at the other end of the segment between them use different class type identifier values.
communication. Such a situation may rrise when ASes become part of one service
provider domain as a result of mergers and acquisitions.
A PCC or PCE (including inter-AS PCE) must be able to specify in its - A PCE must be able to protect itself against DOS attacks
request the need for computing an end-end inter-AS path with protection initiated by malicious (could be pretender) PCEs/PCCs who attempt
against node and/or link failure using 1:1 detours or facility backup. to initiate these attacks via PCE communication protocol messages.
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 The aversion of such attacks could also be achieved via a network-
applied at a neighboring AS basis. Such policies may include any valid wide set of policies that extend beyond the PCE and are out of the
request attributes, including class-types for packet LSPs, bandwidth scope of this document. In inter-AS operation, an inter-AS PCE must
that exceeds a preset threshold per LSP, preemption priorities, setup be able to drop PCECP messages arriving from an AS that it does not
priorities, restriction on links with certain affinities, and desired wish to communicate with. It must also be able to limit the
protection. When a path request is rejected, the requestor must be aggregate rate of PCECP requests/responses arriving from PCEs
informed of the rejection reason along with any information that may affiliated with one ore more ASes or from a group of one or more
help the requestor avoid the points and/or reasons of rejections. ASes.
5.1.2.2. PCE responses 5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP
A path computation response must be able to include nodes (e.g., Path computation requests must be able to carry all constraint
ASBRs), abstract nodes such as ASes, and links as described in [PCE- attributes necessary for setting up an LSP via (G)MPLS-TE signaling
ARCH]. In inter-AS intra-provider path computation, there may not be as stated in [PCECP-REQ]. A path computation request to an inter-AS
any confidentiality issues or restrictions that prevent one AS from PCE must be able to specify ASBRs and ASes as strict and loose
returning a path with strict hops and no loose hops (i.e., nodes and nodes in the path of the LSP to the destination. A PCE must also be
links) within its AS to the requesting inter-AS PCE. In this case, the able to specify a preferred ASBR for exiting to the next AS for
head-end of an LSP could receive, as a result of the work of multiple reaching the destination through a neighboring AS.
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 An inter-AS PCE must also be able specify in its request a list of
constraints for an LSP, must be able to return a number of these paths ASes and/or ASBRs to be excluded in the path computation. In the
to the requestor. This requirement presumes that the path computation intra-provider case, it may also include links with specific
algorithm can compute and return more than one path. The number of affinity in the exclude list.
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 recurses 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 If an inter-AS PCE learns reachability to a destination from
is requested to compute such paths. End-end disjoint paths are paths different ASes, it should be able to send simultaneous requests to
that do not share nodes, links or SRLGs except for the LSP head-end and the inter-AS PCEs associated with these ASes. The maximum number of
tail-end. In cases, where disjoint path segments are desired within one inter-AS PCEs, an inter-AS PCE may send simultaneous requests to,
or more ASs, the disjoint path segments may share only the ASBRs of the SHOULD be configurable. The choice of inter-AS PCEs could be
first AS and the ASBR of the last AS across these ASes. 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.
If an inter-AS PCE cannot find a path to the destination or it cannot The PCC/PCE-PCE communication protocol must enable an inter-AS PCE
find a path that satisfies the LSP constraints, it must send a reject- to specify the AS on whose behalf it is sending the request. This
type message to the requestor with a reject reason. Upon receiving this is specifically important when the inter-AS PCE has identified many
reject message, an inter-AS PCE or a PCC SHOULD attempt an alternative ASes within its scope to the other inter-AS PCE at the other end of
path by sending a request to an alternative AS-PCE. If it exhausted all the communication.
AS-PCEs it SHOULD send a reject message to the previous requestion
inter-AS PCE.
5.1.3. PCE Discovery 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.
In this section the requirement for PCE discovery are discussed. There An inter-AS PCE must be able to reject a request based on policies
are tow types of PCE discovery that SHOULD be supported: (1) static via applied at a neighboring AS basis. Such policies may include any
manual configuration, and (2) dynamic. In each case, the discovery of valid request attributes, including class-types for packet LSPs,
an inter-AS PCE within an AS and across ASes is addressed. 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.3.1. Static configuration 5.1.2.2. PCE responses
An intra-AS inter-area PCE or a PCC MUST be configurable with one or A path computation response must be able to include nodes (e.g.,
more inter-AS PCEs that serve the respective PCE/PCC AS. An inter-AS ASBRs), abstract nodes such as ASes, and links as described in
PCE MUST also be configurable with the set of other inter-AS PCEs that [PCE-ARCH]. In inter-AS intra-provider path computation, there may
it can have a session with and the ASes that these inter-AS PCEs cover. not be any confidentiality issues or restrictions that prevent one
For simplicity, each inter-AS PCE should have a relationship with at AS from returning a path with strict hops and no loose hops (i.e.,
least one inter-AS PCE that serves an AS it directly connects with and nodes and links) within its AS to the requesting inter-AS PCE. In
not under its own jurisdiction. Each PCECP relationship between two this case, the head-end of an LSP could receive, as a result of the
inter-AS PCEs MUST be configurable with the ASes that the inter-AS PCE work of multiple cooperating intra-AS and inter-AS PCEs, a path
at the other end of the serves. In addition, other attributes for PCECP that contains nodes and links as strict hops from LSP head-end to
between two PCEs must be configurable. Such attributes include: tail-end.
The IP address of the inter-AS PCE at the other end of the session and An inter-AS PCE, when it finds more than one path that satisfies
the locally used IP address to exchange IP address with inter-AS PCE. the constraints for an LSP, must be able to return a number of
This IP address may differ from the one used for communicating with these paths to the requestor. This requirement presumes that the
other PCEs/PCCs. 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.
The type of the PCE at the other end of the session (e.g., inter-area In its response, an inter-AS PCE must identify disjoint paths, when
intra-AS, intra-area intra-AS, or inter-AS). 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.
The authentication policy for that session and key when authentication If an inter-AS PCE cannot find a path to the destination or it
is required. This assumes that the transport protocol supports cannot find a path that satisfies the LSP constraints, it must send
authentication. Alternatively, the session should be configurable over a reject-type message to the requestor with a reject reason. Upon
an IPsec tunnel with null encryption but with packet authentication. receiving this reject message, an inter-AS PCE or a PCC SHOULD
The IPsec tunnel can be in tunnel mode or transport mode. 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.
A map for the class type (CT) and TE-class translation when the inter- 5.1.2.2. PCE Discovery
AS PCE computes paths for packet LSPs.
The priority that a given inter-AS PCE serves the messages from the In this section the requirement for PCE discovery are discussed.
inter-AS PCE at the other end of the session as a matter of policy. 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.
The message priorities that it can accept, and whether messages related 5.1.2.3. Static configuration
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.
The capability of the inter-AS PCE at the other end of the session to An intra-AS inter-area PCE or a PCC MUST be configurable with one
compute multiple paths and the maximum number of paths it can return. 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 maximum number of paths that a local inter-AS PCE can accept and - The IP address of the inter-AS PCE at the other end of the
specify in a path computation request 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 total number of inter-AS messages that an inter-AS PCE can - The type of the PCE at the other end of the session (e.g., inter-
simultaneously accept from the inter-AS PCE at the other end should be area intra-AS, intra-area intra-AS, or inter-AS).
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.3.2. Dynamic Discovery - 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.
[PCEDP-REQ] states generic requirements for the PCE dynamic discovery - A map for the class type (CT) and TE-class translation when the
protocol. In this section, additional dynamic PCE discovery inter-AS PCE computes paths for packet LSPs.
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, - The priority that a given inter-AS PCE serves the messages from
it may be desired for an inter-AS PCE not to be discovered by a set of the inter-AS PCE at the other end of the session as a matter of
ASes or some of its capabilities not be known by a set of ASes. Thus, policy.
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 - The message priorities that it can accept, and whether messages
which inter-AS PCE it can communicate with when it discovers PCEs. Such related to the path computation requests it receives from an inter-
policies may be based on PCE capabilities, specific PCEs or ASes that AS PCE should be initiated/progressed with a different locally
the PCE is affiliated with. 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.
The inter-AS PCE discovery mechanisms must commonly apply to both - The capability of the inter-AS PCE at the other end of the
intra-provider and inter-provider cases. session to compute multiple paths and the maximum number of paths
it can return.
5.1.4. PCE: Path Computation The maximum number of paths that a local inter-AS PCE can accept
and specify in a path computation request
This section discusses the path computation requirements, including the - The total number of inter-AS messages that an inter-AS PCE can
requirements on routing, optimality, and path re-optimization. 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.4.1. Routing 5.1.2.4. Dynamic Discovery
An inter-AS PCE could be a composite PCE or a standalone server. In [PCEDP-REQ] states generic requirements for the PCE dynamic
either case, an inter-AS PCE must have reachability information to the discovery protocol. In this section, additional dynamic PCE
LSP tail-end and head-end. At minimum, this reachability information discovery requirements specific to inter-AS operations are
must include the AS path to the LSP tail-end, and the AS in which the discussed. An inter-AS PCE must be able to dynamically discover
tail-end and head-end of the LSP reside. In addition, it needs to have other types of PCEs in the ASes that fall within its scope. In
knowledge of the ASBRs that interconnect the ASes within its scope to addition other PCCs or PCEs must be able to discover an inter-AS
each other and to other ASes outside of its scope and the various PCE that serves them. The dynamic discovery protocol must also
attributes associated with the routes advertised by these ASBRs. One enable the detection and advertisement of the failure or non-
simple way to obtain this information is to have an iBGP session with reachability of an inter-AS PCE as well other PCEs within an AS and
each ASBR in the ASes it is serving. Using this information, an inter- across ASs. The dynamic discovery protocol must allow an inter-AS
AS PCE can determine whether it can itself fully handle the path PCE to identify itself as an inter-AS PCE and to identify the ASes
computation request. Otherwise, the inter-AS PCE determines the next that it supports. In addition, it must be able to identify its
inter-AS PCE it needs to send a request to in order to complete the capabilities to the degree necessary for another PCE or PCC to
path computation to the tail-end. The inter-AS PCE needs to interact decide to initiate a PCECP session to it. More detailed
with intra-area PCEs and inter-area PCEs in the ASes within its scope capabilities could be negotiated in PCC/PCE-PCE communication
to compute a path segment between the head-end and tail-end of the LSP. protocol messages.
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 An inter-AS PCE may not be an inter-provider inter-AS PCE. In
ASes for instance that peer at two or more ASBRs, it must be able to addition, it may be desired for an inter-AS PCE not to be
maintain all the BGP advertisements from each ASBR and use this raw discovered by a set of ASes or some of its capabilities not be
information to compute a path. 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.
The exact procedure(s) that govern the interaction between an inter-AS A PCC/PCE must allow the configuration of local policies that
PCE and intra/inter-area PCEs in the ASes within its scope for the control which inter-AS PCE it can communicate with when it
purpose of path computation shall be specified and shall result in an discovers PCEs. Such policies may be based on PCE capabilities,
optimum way of computing an inter-AS TE-LSP path. Optimality measures specific PCEs or ASes that the PCE is affiliated with.
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.)
5.1.4.2. Optimality The inter-AS PCE discovery mechanisms must commonly apply to both
intra-provider and inter-provider cases.
The inter-AS PCE solution SHOULD allow the set-up of an inter-AS 5.1.3. PCE: Path Computation
(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.4.3. Path Re-optimization This section discusses the path computation requirements, including
the requirements on routing, optimality, and path re-optimization.
When there are resource changes within any AS on the path of an 5.1.3.1. Routing
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 An inter-AS PCE could be a composite PCE or a standalone server. In
management action in reaction to the network event or via a periodic either case, an inter-AS PCE must have reachability information to
re-optimization attempt by the LSP head-end. Alternatively, this the LSP tail-end and head-end. At minimum, this reachability
trigger can be dynamic in reaction to network events. If solutions information must include the AS path to the LSP tail-end, and the
allow relaying a re-optimization trigger via PCEs, and specifically AS in which the tail-end and head-end of the LSP reside. In
inter-AS PCEs, using the PCC/PCE communication protocol messaging, such addition, it needs to have knowledge of the ASBRs that interconnect
solutions must be designed with scalability in mind as multiple LSPs the ASes within its scope to each other and to other ASes outside
could become eligible for re-optimization at the same time. 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.
If re-optimization is triggered dynamically by network events, a large For an inter-AS PCE to compute multiple paths, especially between
number of LSP head-ends may simultaneously attempt to initiate path re- two ASes for instance that peer at two or more ASBRs, it must be
optimization for many LSPs, potentially overloading PCCs and PCEs, able to maintain all the BGP advertisements from each ASBR and use
specifically, inter-AS PCEs. Similarly, if path re-optimization is this raw information to compute a path.
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.
5.1.4.4. Support of diversely routed inter-AS TE LSP 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.)
5.1.3.2. Optimality
The head of the LSP or a proxy (either being a PCC) on its behalf may The inter-AS PCE solution SHOULD allow the set-up of an inter-AS
desire to setup two or more LSPs with diversified paths between the (G)MPLS-TE LSP that complies with a set of TE constraints defined
same tail-end and head-end. A diversified path avoids the sharing of in [TE-REQ]), respectively, and follows an optimal path. The
nodes and links along the path between the two LSPs and optionally definition of “optimal path” for a TE LSP path can be found in
seeks to minimize the number of shared ASes across the two paths. The section 5.1.3 of [INTERAS-TE-REQ] and Section 1 of this document.
solution shall provide ways for computing such diversified paths. 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.
The head-end of an LSP or a proxy (PCC) on its behalf may desire to 5.1.3.3. Path Re-optimization
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 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.
The inter-AS PCE-based solution SHOULD provide the capability of MPLS Triggering path re-optimization for an inter-AS LSP can be done via
fast reroute around a link or node failure. The link or node could be a management action in reaction to the network event or via a
internal to an AS or at an AS boundary. 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.
5.1.5. Hierarchical MPLS 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.
The inter-AS PCE solution SHOULD allow for tunneling inter-AS LSPs 5.1.3.4. Support of diversely routed inter-AS TE LSP
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 The head of the LSP or a proxy (either being a PCC) on its behalf
environment could stem from the need to provide a scalable solution, by may desire to setup two or more LSPs with diversified paths between
reducing the number of LSPs exposed in intermediate ASes and the the same tail-end and head-end. A diversified path avoids the
associated state and dynamism. 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.
5.1.6. Scalability and Performance Requirements 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.
When evaluating a particular solution or comparing solutions that Inter-AS MPLS Fast Reroute
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. The inter-AS PCE-based solution SHOULD provide the capability of
Resulting optimality of the computed end-end LSP path under stated MPLS fast reroute around a link or node failure. The link or node
network conditions and constraints and comparison to [INTERD-TE-PDPC] could be internal to an AS or at an AS boundary.
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 5.1.4. Hierarchical MPLS
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.7. Complexity and Risks 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 proposed solution(s) SHOULD NOT introduce unnecessary complexity to The need for supporting hierarchical MPLS in a single provider
the current operating network to such a degree that it would affect the environment could stem from the need to provide a scalable
stability and diminish the benefits of deploying such a solution over solution, by reducing the number of LSPs exposed in intermediate
SP networks. ASes and the associated state and dynamism.
5.1.8. Management, Aliveness Detection and Recovery Requirements 5.1.5. Scalability and Performance Requirements
Especially, in terms of MIB, inter-AS PCEs should support a specific When evaluating a particular solution or comparing solutions that
inter-AS traffic engineering MIB as specified in section 5.1.10.1 of address aspects of inter-AS PCE, the following scalability and
[INTERAS-TE-REQ]. This MIB relates to security consideration in this performance criteria SHOULD be considered:
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 - Message load on the inter-AS PCEs and intra-AS PCEs.
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.
Basic aliveness detection for PCC/PCE-PCE communication is described in - Resulting optimality of the computed end-end LSP path under
[PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to stated network conditions and constraints and comparison to
check the liveliness of the neighboring inter-AS PCE(s) it is using for [INTERD-TE-PDPC] mechanisms
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 (G)MPLS-TE LSP setup time
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 - Minimization of the need for crankback
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 - 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 inter-AS PCE requirements for PCECP for inter-providers case SHOULD - The capability to operate in a PCE-enabled and PCE-free
include all requirements discussed in section 6.1 above in addition to environment and interworking with existing(G)MPLS-TE mechanisms
those discussed in this section here.
Please also note that the SP with multiple ASes may choose not to - No added complexity to network routing by the inter-AS PCE
include inter-provider inter-AS PCE requirements presented here in its
inter-AS TE implementation within its own administrative domain.
5.2.1. Confidentiality - Scalability with network size and its effect on PCC/PCE-PCE
sessions
Each SP will in most cases maintain its own PCEs, some scoped for - Added complexity and features to the PCC/PCE-PCE communication
intra-provider inter-AS within its own administrative domain and some protocol
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 - Added complexity and features to the inter-AS PCE discovery
inter-domain path computation capability for both PCCs and PCEs covered protocol
in section 6.1 and 6.2 of [PCEDP-REQ], and specifically to the inter- Added complexity and features on signaling
provider inter-AS application, the PCE discovery mechanism SHOULD have
the ability to exclude and/or filter 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 5.1.6. Complexity and Risks
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 The proposed solution(s) SHOULD NOT introduce unnecessary
across AS boundaries without detailed knowledge of the list of hops, TE complexity to the current operating network to such a degree that
link metrics and paths within each transit AS. For each partial inter- it would affect the stability and diminish the benefits of
AS LSP path a PCE computes, it should return to its peering PCE in the deploying such a solution over SP networks.
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 5.1.7. Management, Aliveness Detection and Recovery Requirements
Section 5.2.2. of [INTERAS-TE-REQ] discusses the policy control Especially, in terms of MIB, inter-AS PCEs should support a
requirements on the inter-AS RSVP-TE signaling at the AS boundaries for specific inter-AS traffic engineering MIB as specified in section
the enforcement of interconnect agreements, attribute/parameter 5.1.10.1 of [INTERAS-TE-REQ]. This MIB relates to security
translation and security hardening. 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.
This section discusses those policy control requirements specifically The built-in diagnostic tools must detect failures of PCC/PCE-PCE
for PCECP at the PCE control plane level. Please note that SPs may PCECP and allow checking the status of PCECP related to inter-AS
still require ingress policy controls on the actual signaling paths PCEs. The new MIB module should support the status of PCECP related
mentioned above to enforce their bilateral or multi-lateral agreements to inter-AS PCEs. Here, it is assumed that inter-AS PCEs exist in
at the AS boundaries. different AS or different SP administrative domains.
5.2.2.1. Inter-AS PCE Peering Policy Controls 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.
As mentioned in section 5.2.1 above, the PCE discovery protocol SHOULD Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an
have the ability to control PCE scope and inter-AS computation inter-AS PCE must address inter-AS PCE-inter-AS PCE communication
capabilities to be discovered by PCCs or PCEs from other AS(es). The failure response. It must be defined how an inter-AS PCE deals with
following provides some parameters which could be controlled during the failures of neighboring inter-AS PCEs. It is recommended that
discovery for PCCs or PCEs from upstream neighboring AS(es): 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.
PCE scope and path computation domains: one or a set of ASNs for which Basic protocol recovery is described in [PCECP-REQ]. PCC/PCE-PCE
it can compute inter-AS TE LSP paths communication protocol must support resynchronization of
the capability to compute inter-AS TE paths with other ASes that are information and requests between inter-AS PCEs, and this should be
not part of the originating AS transit path; for example, AS1 has arranged in order to minimize repeated data transfer.
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.
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 5.2. Requirements Across SP Administrative Domains
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 The inter-AS PCE requirements for PCECP for inter-providers case
allow the discovery and enforcement of different information sets for SHOULD include all requirements discussed in section 6.1 above in
PCCs and PCEs from different AS(es). addition to those discussed in this section here.
For path computation requests that are not compliant with configured Please also note that the SP with multiple ASes may choose not to
policies, the policy enforcing PCE SHOULD generate a path error message include inter-provider inter-AS PCE requirements presented here in
to the requesting PCC or PCE indicating the cause of errors. its inter-AS TE implementation within its own administrative
domain.
5.2.2.2. Inter-AS PCE Reinterpretation Polices 5.2.1. Confidentiality
Each SP may have different definitions in its use of for example, RSVP- Each SP will in most cases maintain its own PCEs, some scoped for
TE session attributes, DS-TE TE classes, etc. The PCEs receiving these intra-provider inter-AS within its own administrative domain and
path requests need to be able to reinterpret some of attributes and some are specifically designated for inter-provider inter-As TE LSP
adapt them to the native environment in its own AS for path path computation. Among the inter-provider scoped inter-AS PCEs in
computation. A list of such parameters subject to policy each SP domain, there may also be a subset of the PCEs specifically
reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ]. enabled for path computation across one or specific set of ASes of
Also the transit SPs along the inter-AS TE path may be a GMPLS different SPs.
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 In addition to the generic requirement of limiting discovery scope
reinterpret some of these parameters in the incoming PCC or PCE and inter-domain path computation capability for both PCCs and PCEs
requests from other AS(es) for its own AS TE implementations or to covered in section 5.1 and 5.2 of [PCEDP-REQ], and specifically to
signal to PCEs in the downstream AS(es). the inter-provider inter-AS application, the PCE discovery
mechanism SHOULD have the ability to support the following
requirements:
6. Security Considerations - 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.
Security concerns arise between any two communicating elements - Also as required in section 5.2.1 of [INTERAS-TE-REQ], the PCE
especially when the elements belong to different administrative solutions SHOULD include the ability to carry out path computations
entities. In this case, there are security concerns that need to be for an optimum inter-AS TE LSP across AS boundaries while
addressed for communication among inter-AS PCEs and other PCEs in a preserving the path confidentiality in its own AS.
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 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.
In a multi-SP administrative domain environment, SPs want to 5.2.2. Policy Controls
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, Section 5.2.2. of [INTERAS-TE-REQ] discusses the policy control
the SP may authenticate inter-AS path computation requests to confirm requirements on the inter-AS RSVP-TE signaling at the AS boundaries
whether they should trust the requests or not depending on SP's policy. for the enforcement of interconnect agreements, attribute/parameter
And they may allow or deny the requests after inter-AS PCEs translation and security hardening.
authenticate them.
Inter-AS PCEs should be able to authenticate inter-AS path computation This section discusses those policy control requirements
requests and confirm whether they should allow or deny them. 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.
Confidentiality: in a multi-SP administrative domain environment, SPs 5.2.2.1. Inter-AS PCE Peering Policy Controls
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 As mentioned in section 5.2.1 above, the PCE discovery protocol
SP itself has some policies for a (G)MPLS-TE enabled network. An inter- SHOULD have the ability to control PCE scope and inter-AS
AS PCE sends path computation requests which with some parameter to its computation capabilities to be discovered by PCCs or PCEs from
neighboring inter-AS PCEs. In terms of parameters, see section 5.2.2.1 other AS(es). The following provides some parameters which could
of [INTERAS-TE-REQ]. In this case, an inter-AS PCE enforces some be controlled during discovery for PCCs or PCEs from upstream
policies applied to its neighboring inter-AS PCEs that may include neighboring AS(es):
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 - PCE scope and path computation domains: one or a set of ASNs for
case multiple ASes exist within a single SP administrative domain, which it can compute inter-AS TE LSP paths
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.
Protection from DoS attacks: In multi-SP administrative domain - The capability to compute inter-AS TE paths with other ASes that
environment, inter-AS PCEs may be subject to malicious DoS attacks. are not part of the originating AS transit path; for example, AS1
They should have functions to protect from such attacks. 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.
PCC/PCE spoofing: In multi-SP administrative domain enviornmrnt, inter- - Certain type of link and path constraints; for example, AS2 only
AS PCEs have the possibility of spoofing the PCE-PCE communication. agrees to allow its PCEs scoped for AS1 only considering bandwidth
Inter-AS PCEs should have functions to avoid spoofing a PCE-PCE with certain sets of affinities and DS-TE class types - then all
communication. other capabilities of AS2's PCE will be excluded during the
discovery between AS1 and AS2
7. Authors’ Addresses - 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.
Nabil Bitar - FRR capabilities for inter-AS paths: link, node or bandwidth
Verizon protection for inter-AS TE LSP paths
40 Sylvan Road DS-TE TE class <class-type, Preemptions>: SPs may have their own
Waltham, MA 02145 class-type and preemption definitions. Thus, advertised TE class
Email: nabil.bitar@verizon.com capability should be translated to ones native to the requesting
ASes. This is discussed in previous sections
Kenji Kumaki The PCE communications protocol SHOULD have the ability to enforce
KDDI Corporation on the incoming PCE requests policies on a set of parameters listed
Garden Air Tower in section 5.2.2.1 of [INTERAS-TE-REQ] in addition to the PCE scope
Iidabashi, Chiyoda-ku, and path computation domains.
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com
Raymond Zhang Please note that the PCEDP and PCECP SHOULD provide the ability to
BT INFONET Services Corporation allow the discovery and enforcement of different information sets
2160 E. Grand Ave. for PCCs and PCEs from different AS(es).
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com
8. Normative References 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.
[INTERAS-TE-REQ] Zhang and Vasseur, ‘‘MPLS Inter-AS Traffic Engineering 5.2.2.2. Inter-AS PCE Reinterpretation Polices
requirements’’, draft-ietf-tewg-interas-mpls-te-req-09.txt, March 2005
(Work in Progress; RFC Editor’s Queue)
[PCE-ARCH] Farrel, Vasseur & Ash, ‘‘Path Computation Element (PCE) Each SP may have different definitions in its use of for example,
Architecture’’, draft-ietf-pce-architecture-02.txt, March 2006 (Work in RSVP-TE session attributes, DS-TE TE classes, etc. The PCEs
Progress) 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.
[PCECP-REQ] J. Ash, J.L Le Roux et al., ‘‘PCE Communication Protocol The PCECP implementation SHOULD allow for the policy enforcing PCEs
Generic Requirements’’, draft-ietf-pce-comm-protocol-gen-reqs (work in to reinterpret some of these parameters in the incoming PCC or PCE
progress). requests from other AS(es) for its own AS TE implementations or to
signal to PCEs in the downstream AS(es).
[PCEDP-REQ] J.L. Le Roux et al., ‘‘Requirements for Path Computation 6. Security Considerations
Element (PCE) Discovery’’, draft-ietf-pce-discovery-reqs (work in
progress).
[TE-REQ] Awduche et. al., "Requirements for Traffic Engineering Security concerns arise between any two communicating elements
over MPLS", RFC2702, September 1999. 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:
[TE-RSVP] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP authentication, permission and rejection for path computation
Tunnels", RFC 3209, December 2001 requests:
9. Informative References 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.
[INTERD-TESIG] Ayyangar and Vasseur, ‘‘Inter domain GMPLS Traffic In case multiple ASes exist within a single SP administrative
Engineering - RSVP-TE extensions’’, draft-ietf-ccamp-inter-domain-rsvp- domain, the SP may authenticate inter-AS path computation requests
te-02.txt, April 2006 (Work in Progress) 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.
[ISP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with Inter-AS PCEs should be able to authenticate inter-AS path
Generalized MPLS TE", (work in progress). computation requests and confirm whether they should allow or deny
them.
[LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with - Confidentiality: in a multi-SP administrative domain environment,
Generalized MPLS TE", (work in progress)) 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].
[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, ‘‘A Per-domain path - Policy control: In a multi-SP administrative domain environment,
computation method for computing Inter-domain Traffic Engineering (TE) each SP itself has some policies for a (G)MPLS-TE enabled network.
Label Switched Path (LSP)’’, draft-ietf-ccamp-inter-domain-pd-path-comp- An inter-AS PCE sends path computation requests which with some
00.txt , October 2005, (Work in Progress) 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.
[GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label - Traffic policing: In multi-SP administrative domain environment
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic or in case multiple ASes exist within a single SP administrative
Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 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.
10. Full Copyright Statement - 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.
Copyright (C) The Internet Society (2005). This document is subject to - PCC/PCE spoofing: In multi-SP administrative domain enviornmrnt,
the rights, licenses and restrictions contained in BCP 78, and except inter-AS PCEs have the possibility of spoofing the PCE-PCE
as set forth therein, the authors retain all their rights. communication. Inter-AS PCEs should have functions to avoid
spoofing a PCE-PCE communication.
This document and the information contained herein are provided on an 7. Author’s Addresses
"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 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 Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
The IETF takes no position regarding the validity or scope of any Dean Cheng
Intellectual Property Rights or other rights that might be claimed to Cisco Systems Inc.
pertain to the implementation or use of the technology described in 3700 Cisco Way
this document or the extent to which any license under such rights San Jose CA 95134 USA
might or might not be available; nor does it represent that it has made Phone: +1 408 527 0677
any independent effort to identify any such rights Information on the Email: dcheng@cisco.com
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 Kenji Kumaki
assurances of licenses to be made available, or the result of an KDDI Corporation
attempt made to obtain a general license or permission for the use of Garden Air Tower
such proprietary rights by implementers or users of this specification Iidabashi, Chiyoda-ku,
can be obtained from the IETF on-line IPR repository at Tokyo 102-8460, JAPAN
http://www.ietf.org/ipr. Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com
The IETF invites any interested party to bring to its attention any Eiji Oki
copyrights, patents or patent applications, or other proprietary NTT
rights that may cover technology that may be required to implement Midori-cho 3-9-11
this standard. Please address the information to the IETF at ietf- Musashino-shi, Tokyo 180-8585,
ipr@ietf.org. 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)
[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
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.
 End of changes. 209 change blocks. 
1031 lines changed or deleted 1033 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/