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