Internet Draft draft-bitar-zhang-interaS-pcecp-reqs-00 February 2006
Network Working Group Nabil Bitar (Editor)
Verizon
Internet Draft Raymond Zhang (Editor)
BT Infonet
Kenji Kumaki (Editor)
KDDI Corporation
Expires: August 2006 February 2006
Inter-AS Requirements for the Path Computation Element Communication
Protocol (PCECP)
draft-bitar-zhang-interas-pcecp-reqs-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.
Abstract
This document discusses requirements for the support of the Path
Computation Element Communication Protocol (PCECP) 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.
Bitar et al. Inter-AS Requirements for PCECP [Page 1]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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.....................................................2
2. Definitions......................................................3
3. Reference Model..................................................4
4. Application Scenarios............................................6
4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional
Networks............................................................6
4.2. Inter-AS Path Computation over a GMPLS Transport Core..........8
5. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............8
5.1. Requirements within one SP Administrative Domain...............9
5.1.1. PCC/PCE-PCE Communication Protocol Requirements..............9
5.1.1.1. Requirements on path computation requests.................10
5.1.1.2. Requirements on path computation responses................11
5.1.2. Scalability and Performance Requirements....................12
5.1.3. Complexity and Risks........................................12
5.1.4. Management, Aliveness Detection and Recovery Requirements...12
5.2. Requirements Across SP Administrative Domains.................13
5.2.1. Confidentiality.............................................13
5.2.2. Policy Controls Effecting inter-AS PCECP....................13
5.2.2.1. Inter-AS PCE Peering Policy Controls......................13
5.2.2.2. Inter-AS PCE Reinterpretation Polices.....................14
6. Security Considerations.........................................14
7. Authors' Addresses..............................................15
8. Normative References............................................16
9. Informative References..........................................16
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. A (G)MPLS-TE optimum path for an LSP is one
that has the smallest cost, according to a normalized TE metric
Bitar, Zhang et al. [Page 2]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
(based upon a TE-metric or IGP metric adopted in each transit AS),
among all possible paths that satisfy the LSP TE-constraints.
The requirements for a PCE have risen from SP needs to compute a more
optimum path than that can be achieved by mechanisms provided
in[INTERD-TE-PDPC], and be able 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 PCECP
requirements that are specific to (G)MPLS-TE inter-AS path
computation using a PCE-based approach.
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 PCECP requirements when the ASes are under a single SP
administrative domain. 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
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 networks 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/(G)MPLS 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 Paths (LSP), Head-end Label Switching Routers (LSRs),
and Tail-end LSRs reside in the same AS for traffic engineering
purposes.
Bitar, Zhang et al. [Page 3]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where
its TE LSPs, Head-end LSRs and Tail-end LSRs do not reside within the
same AS
ASBR Routers: Border routers used to connect one AS to another AS of
a different or the same SP via one or more links between the ASes.
Inter-AS TE Path: A 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].
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 and other inter-AS PCEs, across one or more AS(es).
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),known as composite PCE,
as described in [PCE-ARCH]).
Inter-AS Inter-AS Inter AS
Bitar, Zhang et al. [Page 4]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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
Defines 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 ASes
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 selection 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(es) 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 "downstream" neighbor inter-AS
PCE that it progresses the path request to. In determining the
"downstream" 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 ASes 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
Bitar, Zhang et al. [Page 5]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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. What could be returned in the path computation response
can be 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 affiliated with the responding PCE. This
process proceeds recursively 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 [INTERD-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.
4.
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, a
similar inter-AS TE application scenario using PCEs with inter-AS
scope to compute optimum paths across AS boundaries is presented.
Bitar, Zhang et al. [Page 6]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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-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 example diagram depicted in Figure 2, ASBRs R13 and R14 as
PCCs, dynamically or statically discover their corresponding PCEs R16
and R18 which in turn maintain meshed peering with AS2 PCEs R26 and
R27. R13 and R14 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 require
building a separate inter-TE tunnel (T3) to R113 directly to support
a customer voice-trunk, for example.
With per-domain path computation, the three tunnels (T1, T2, and T3)
would be built with paths as shown below, assuming all links have a
metric value of 1 and all inter-AS links between ASes have the same
maximum reservable bandwidth:
- T1's path: (R13,R15) expanding at R21 to have the path R13-R21-R23-
R26-R15;
- T2's path: (R14,R17) expanding at R22 to have the path R14-R22-R27-
R17;
- T3's path: (R11,R113) expanding at R21 to have the path R11-R13-
R21-R23-R26-R15-R17-R113
Bitar, Zhang et al. [Page 7]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
For T1 and T2, the requirement for diversification is paramount where
R26 and R27 (as PCEs) will need to maintain synchronized states of
both T1 and T2 in order to compute two diverse routes for these two
inter-AS TE LSPs.
For T3, a more optimum path should be R11-R14-R22-R27-R17-R113 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 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. It is also worth noting that the reachability
between R13 and R14 and their primary PCEs (R16 and R18) will be
required via, for example either static or BGP routing in the global
space across inter-ASBR links.
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 to compute an inter-As TE LSP between R1 and R2. ASBR1
in turns requests path computation from its downstream peering PCE,
ASBR2, for this LSP 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 PCECP Requirements for Inter-AS (G)MPLS-TE
Bitar, Zhang et al. [Page 8]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
This section discusses detailed PCECP requirements in two principal
areas for inter-AS (G)MPLS-TE path computtion 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 PCECP 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.
PCC/PCE-PCE Communication Protocol Requirements
Requirements specific to requests or responses are discussed in the
next subsections. Following are additional 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-type
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.
- In inter-AS operation, an inter-AS PCE must be able to silently
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 by silently droping
messages when a pre-configured rate threshold is exceeded.
Bitar, Zhang et al. [Page 9]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
5.1.1.1.
Requirements on path computation requests
Following are inter-AS specific requirements on PCECP requests for
path computation
- 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/or 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 and
reach the destination through that AS.
- An inter-AS PCE must be able to specify in its request a list
of ASes and/or ASBRs to be excluded in the path computation. It must
also be able to include links with specific affinity in the
exclude/include list. Boundary policies can be deployed to interpret
and translate incoming affinity to one significant to the local AS.
- 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-to-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 path with protection
against node and/or link, and/or SRLG 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) its 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
valid request attributes, including class-types for packet LSPs,
bandwidth that exceeds a preset threshold per LSP or AS, preemption
priorities, setup priorities, restriction on links with certain
Bitar, Zhang et al. [Page 10]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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 in subsequent requests.
5.1.1.2.
Requirements on path computation responses
Following are inter-AS specific requirements on PCECP responses for
path computation:
- 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.
- In a path computation response, 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 of the path. The PCC/PCE-PCE PCECP must be able
to carry this information.
- In its response, an inter-AS PCE must identify diversified paths,
when it is requested to compute such paths. End-to-end diversified
paths are paths that do not share nodes, links or SRLGs
except for the LSP head-end and tail-end. In cases, where diversified
path segments are desired within one or more ASes, the diversified
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 requesting inter-AS PCE if there is one.
Bitar, Zhang et al. [Page 11]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
5.1.2.
Scalability and Performance Requirements
When evaluating a PCECP for inter-AS case, the following scalability
and performance criteria SHOULD be considered:
- Message load on the inter-AS PCEs and intra-AS PCEs.
- Scalability with network size, number of inter-AS PCEs, number of
intra-AS PCEs and the effect of these parameters on PCC/PCE-PCE
sessions
- Added complexity and features to the PCC/PCE-PCE communication
protocol
5.1.3.
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.4.
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
communicating with for inter-AS (G)MPLS-TE path computation.
Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an
inter-AS PCE must address inter-AS PCE to 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 serves the
same AS 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 of this document.
Bitar, Zhang et al. [Page 12]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
5.2.
Requirements Across SP Administrative Domains
The inter-AS PCECP requirements in the inter-provider case include
all requirements discussed in section 5.1 in addition to those
discussed in this section. 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 designate some PCEs for inter-AS (G)MPLS-
TE path computation within its own administrative domain and some
other PCEs for inter-provider inter-As (G)MPLS-TE 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 a specific set of ASes of different peer SPs.
PCECP should allow an SP to hide from other SPs the set of hops,
within its own AS(es,) traversed by an inter-AS inter-provider
(G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a
multi-SP administrative domain environment, SPs want to hide their
network topologies for security reasons. In addition, SPs do not want
to reveal the path traversed by an LSP segment within their domains
to other SPs' domains. Thus, 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(es)
without detailing the explicit intra-AS hops plus partial paths with
an aggregated TE LSP cost it receives from its downstream PCE. A 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.
5.2.2.
Policy Controls Effecting inter-AS PCECP
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 for PCECP.
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
A PCE SHOULD have the ability to enforce policies, defined for a set
of parameters listed in section 5.2.2.1 of [INTERAS-TE-REQ], on the
incoming PCECP path computation requests.
Bitar, Zhang et al. [Page 13]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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 with some parameters 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. These policies may
include rewriting some of the parameters' values or rejecting
requests based on some parameters' values. Inter-AS PCEs should also
have the ability to exclude and/or filter internally-scoped
information and capability information based on policies. Such
policies may also be applied in the case of multiple ASes within a
single SP administrative domain.
For path computation requests that are not compliant with configured
policies, the policy enforcing PCE SHOULD generate an error message
to the requesting PCC or PCE indicating the cause of errors or a
reject message with a reason.
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
the attributes and adapt them to the native environment in their 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).
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 as among inter-AS PCEs under
different SP administrative domains. Following are requirements that
apply to inter-AS PCECP messages:
- Authentication, permission and rejection for path computation
requests:
Bitar, Zhang et al. [Page 14]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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 it should trust the requests or not, depending on SP policy.
An inter-AS PCE may allow or deny the requests after it authenticates
them. Inter-AS PCEs should also be able to authenticate inter-AS
PCECP path computation responses.
Inter-AS PCEs should be able to authenticate inter-AS path
computation requests and confirm whether they should allow or deny
them. Inter-AS PCEs should be able to authenticate all PCECP
messages.
- 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 (i.e., resulting in a high path-computation-request rate).
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
using PCECP. Inter-AS PCEs should be able protect themselves from
such attacks.
- PCC/PCE spoofing: In multi-SP administrative domain environment,
inter-AS PCEs have the possibility of spoofing the PCC/PCE-PCE
communication. Inter-AS PCEs should have functions to avoid spoofing
PCC/PCE-PCE communication.
7.
Authors' Addresses
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com
Kenji Kumaki
KDDI Corporation
Bitar, Zhang et al. [Page 15]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
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", RFC4216, November 2005.
[PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element
(PCE)Based Architecture", draft-ietf-pce-architecture-04.txt, January
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-
04.txt(work in progress).
[PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation
Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (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-02.txt, February 2006, (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", draft-ietf-ccamp-lsp-stitching-02.txt,
September 2005, (work in progress).
Bitar, Zhang et al. [Page 16]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
[LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)
Hierarchy with Generalized MPLS TE", RFC4206, October 2005.
[GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions, RFC 3473, January 2003.
Full Copyright Statement
Copyright (C) The Internet Society (2006). 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.
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, Zhang et al. [Page 17]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006
Bitar, Zhang et al. [Page 18]