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