wdiff draft-bitar-zhang-interas-pcecp-reqs-00.txt draft-bitar-zhang-interas-pcecp-reqs-01.txt

Internet Draft draft-bitar-zhang-interaS-pcecp-reqs-00 February 2006Network Working Group Nabil Bitar (Editor)
Verizon
Internet Draft Raymond Zhang (Editor)
BT Infonet
Kenji Kumaki (Editor)
KDDI Corporation

Expires: August December 2006 February June 2006

Inter-AS Requirements for the Path Computation Element Communication
Protocol (PCECP)

draft-bitar-zhang-interas-pcecp-reqs-00.txt

draft-bitar-zhang-interas-pcecp-reqs-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.

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 Internet-Drafts as reference
material or to cite them other than as "work in progress."

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

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

This Internet-Draft will expire in December 2006.

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.

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. 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. (G)MPLS-TE..............4
4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............9
5.1.1.1. Requirements..............4
4.1.1.1. Requirements on path computation requests.................10
5.1.1.2. requests..................4
4.1.1.2. Requirements on path computation responses................11
5.1.2. responses.................6
4.1.2. Scalability and Performance Requirements....................12
5.1.3. Complexity and Risks........................................12
5.1.4. Requirements.....................6
4.1.3. Management, Aliveness Detection and Recovery Requirements...12
5.2. Requirements Across SP Administrative Domains.................13
5.2.1. Confidentiality.............................................13
5.2.2. Requirements....7
4.1.4. Confidentiality..............................................8
4.1.5. Policy Controls Effecting inter-AS PCECP....................13
5.2.2.1. PCECP.....................8
4.1.5.1. Inter-AS PCE Peering Policy Controls......................13
5.2.2.2. Controls.......................8
4.1.5.2. Inter-AS PCE Reinterpretation Polices.....................14
6. Polices......................9
5. Security Considerations.........................................14 Considerations..........................................9
6. IANA Considerations..............................................9
7. Authors' Addresses..............................................15 Acknowledgments..................................................9
8. Normative References............................................16 Authors' Addresses...............................................9
9. Normative References............................................10
10. Informative References..........................................16 References.........................................10

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 [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
(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], 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. model. Section 5 4 states inter-
AS inter-AS PCECP requirements when the ASes are under a single SP
administrative domain. requirements.
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

This document refers only
to IP/(G)MPLS networks adopts the definitions 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 acronyms defined in the same AS for traffic engineering
purposes.

Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where
its TE LSPs, Head-end LSRs
[INTERAS-TE-REQ] Section 3.1 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 [PCE-ARCH] Section 2. In addition,
we use the ASes. following terminology:

PCECP: PCE Communication Protocol

PCEDP: PCE Discovery Protocol

Inter-AS TE Path: (G)MPLS-TE path: A TE (G)MPLS-TE path traversing multiple that traverses two or
more 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:

Intra-AS (G)MPLS-TE path: A set of links may constitute a 'shared risk link group'
(SRLG) if they share (G)MPLS-TE path that is confined to a resource whose failure
single AS. It may affect all
links in the set as defined in [GMPLS-ROUT]. traverse on or more IGP areas.

Inter-area PCE: Path computation element

PCC: Path computation client

PCECP: PCE communication protocol

PCEDP: A PCE Discovery Protocol responsible for computing (G)MPLS-TE paths or
path segments traversing across multi-IGP areas.

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, (G)MPLS-
TE paths or path segments, by possibly cooperating with intra-
AS PCEs and other inter-AS intra-AS
PCEs, across one or more AS(es). ASes.

3.
Reference Model

Figure 1 depicts the reference model for PCEs in an inter-AS
application. In this document, we define We refer to two types of PCE functions: functions in this document:
inter-AS PCEs and intra-AS PCEs. Figure 1 shows Inter-AS PCEs perform the case where there
are three ASes, each having an inter-AS PCE. Each procedures
needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs
perform the functions needed for intra-AS (G)MPLS-TE path
computation. This document focuses on the PCE
communicates with Communication Protocol
requirements used by inter-AS PCEs of neighboring ASes to compute inter-
AS (G)MPLS-TE paths. An inter-AS PCE may also communicate with intra-
AS path
requests/responses to other inter-AS PCEs and by intra-AS PCEs within the scope of its AS to compute a
communicate path segment within
its AS. An requests/responses to 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]). PCEs and vice versa.

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: 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

4.
Detailed PCECP Requirements 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 Inter-AS (G)MPLS-TE

This section discusses detailed PCECP requirements for path computation within inter-AS
(G)MPLS-TE applications using a single AS. It should be emphasized that
the differentiation between these two PCE types is functional as both
can be implemented and enabled PCE-based approach. Depending on the same physical device, but
scalability requirements and/or security considerations
operation environment, service providers 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 use some 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 all 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
capabilities 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, PCECP 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 satisfies these requirements.
Specifically, some requirements are more neighboring AS-PCEs based on the AS(es) through which
it learned reachability (maybe the best path ) applicable 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
inter-provider (G)MPLS-TE operation than intra-provider operations.

4.1.1.
PCC/PCE-PCE Communication Protocol Requirements

Requirements specific to which the path request must be sent, an inter-AS PCE may first qualify the PCECP path to an ASBR associated with
that inter-AS PCE computation requests
and may exclude paths that do not satisfy the
constraints of the LSP (e.g., by excluding ASBRs responses are discussed in section 4.1.1.1 and inter-AS links
between the two neighboring ASes when there is not sufficient
bandwidth 4.1.1.2,
respectively.

4.1.1.1.
Requirements on the paths to these ASBRs or ASes to sastisfy the LSP
bandwidth constraints). Before an inter-AS PCE decides to send a path computation request to a neighbor requests

Following are 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 specific requirements on PCECP requests for
path in both directions according to the LSP constraints.

In an all-PCE enabled environment, the last inter-AS PCE, serving computation

- PCECP MUST allow the
AS specification 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 request
priority 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 specified in [PCECP-REQ]. Priority-based message
processing is a cost for the
total path and returns the concatenated path(s) local decision 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 out 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 scope 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]. document. 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.

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 operation, a customer voice-trunk, for example.

With per-domain path computation, the three tunnels (T1, T2, and T3)
would policy may 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
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,
enforced on 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 request so 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 priority 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
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 altered when progressing 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 request 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 AS or responses are discussed in across other ASes. PCECP SHOULD allow the
next subsections. Following are additional requirements to those
described in [PCECP-REQ] for PCC/PCE-PCE communication. Some notification 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 requester of such a 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. happens. Such notification must MAY
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.

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 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 MUST also be able to specify a
preferred ASBR for exiting to the next AS and
reach for reaching the
destination through that a neighboring AS.

- An inter-AS PCE must If such a constraint cannot
be able satisfied at a PCE, PCECP SHOULD allow a PCE to specify notify the
requestor of that fact in its request the path error message.

- PCECP MUST enable enlisting 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 PCECP 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 MUST be able to specify in
its PCECP path computation request the need for computing an end-end end-to-
end path with protection against node and/or node, 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 PCC or PCE MUST be able to ask for specify in its path request to an
inter-AS PCE the retturn of a minimum of two
paths that are diversified paths
(i.e., paths that do not share common nodes, links or
SRLGs) its and/or SRLGs).

- A PCECP path computation request to an inter-AS PCE. message MUST enable the
specification of AS-only diversified path computation.

- An inter-AS PCE must A PCECP path computation request message 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
affinities, and desired protection. When a path request is rejected, identify
the requestor must be informed scope of diversified path computation to be end-to-end (i.e.,
between the rejection reason along with any
information that may help the requestor avoid the points and/or
reasons endpoints of rejections in subsequent requests.

5.1.1.2. the (G)MPLS-TE tunnel) or to be limited to a
specific AS.

4.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 MUST be able to include nodes (e.g.,
ASBRs), abstract nodes such as ASes, ASBRs and links as described in [PCE-
ARCH]. ASes
on the computed path. 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 inter-provider case,
confidentially and security considerations may require only the requestor
return of AS at numbers and/or ASBRs in path computation response
messages.

- A PCECP response message MUST be able to carry an identifier for a minimum. In addition,
path segment computed by the responding PCE. Such an identifier could
be used in a cost
associated with each (G)MPLS-TE path should setup message for path expansion at an
ASBR.

- A PCECP response message MUST be returned able to enable selection of carry an optimum end-end path. The cost could reflect the cumulative
administrative inter-AS
path cost. Path cost normalization across ASes is out
of the path. The PCC/PCE-PCE scope of this document and it is expected to be addressed
in other work on path computation.

- A PCECP must response message SHOULD be able to carry this information.

- In its response, an intra-AS cost
for a path segment separately from an inter-AS PCE must path segment cost.
Best path selection procedures based on these costs are out of the
scope of this document.

- A PCECP response message MUST be able to identify diversified paths, paths
for the same(G)MPLS-TE LSP when it the responding PCE is requested to
compute such paths. End-to-end (i.e., between the two endpoints of
the (G)MPLS-TE tunnel) disjoint diversified paths are paths that do
not share nodes, links or SRLGs except for the LSP head-end and tail-end. tail-
end. In cases, 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.

5.1.2.

4.1.2.
Scalability and Performance Requirements

When evaluating a PCECP for the inter-AS case, the following
scalability and performance criteria SHOULD be considered:

- Message Processing load on the inter-AS PCEs and intra-AS PCEs.
- Scalability with network size, as a function of the following parameters:

- number of PCCs within the scope of an inter-AS PCEs, PCE
- number of
intra-AS intra-area PCEs and within the effect scope of these parameters on PCC/PCE-PCE
sessions an inter-AS PCE
- number of peering inter-AS PCEs
- 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.

4.1.3.
Management, Aliveness Detection and Recovery Requirements

Especially, in terms of MIB,

[PCECP-REQ] specifies generic requirements for PCECP management. This
document addresses new requirements that apply to inter-AS PCEs should support a specific
operations.

The PCECP MIB module MUST provide objects to control the behavior of
PCECP in inter-AS applications, including the ASes within its scope,
the ASes the PCE cannot communicate with via PCECP, the ASes that the
PCE can communicate with, confidentiality policies, and traffic
engineering MIB policies. Each of these two latter requirements SHOULD
apply per inter-AS PCE and/or AS peer.

The built-in diagnostic tools MUST enable failure detection and
status checking of PCC/PCE-PCE PCECP. Diagnotic tools include
statistics collection on the historical behavior of PCECP as
specified in section 5.1.10.1 of
[INTERAS-TE-REQ]. This MIB relates to security consideration in [PCECP-REQ]. For inter-AS operations, this
document. statistics
SHOULD be collected on per inter-AS PCE peer basis and per AS. For
instance, the following statistics SHOULD be collected:
- number of successfully satisfied requests
- number of rejected requests per reason
- number of PCE requests
- number of malformed PCECP messages
- number of unauthenticated PCECP messages

The new MIB module must provide MUST support 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 These
thresholds SHOULD be specifiable per peer AS as well as per peer
inter-AS
PCEs. The new MIB module PCE and traps 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. be accordingly generated.

Basic aliveness liveliness 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 The
inter-AS PCE deals with
the failures PCECP MIB module SHOULD allow control of neighboring inter-AS PCEs. It is recommended that an
inter-AS PCE selects another neighboring liveliness check
behavior by providing a liveliness message frequency MIB object. This
frequency SHOULD be specified per inter-AS PCE peer. In addition,
there SHOULD a MIB object that serves specifies the
same AS or group dead-interval as a
multiplier of ASes the liveliness message frequency so that to obtain equivalent coverage, on
detection of an inter-AS PCE failure or non-rechability of an inter-
AS PCE. But note if no
liveliness message is received within that time from an inter-A PCE,
the inter-AS PCE selection procedure is out of the
scope of this document.

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 declared unreachable.

4.1.4.
Confidentiality

Confidentiality mainly applies 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 communication.
However, confidentiality rules may also apply among ASes under a
single provider. Each SP will in most cases designate some PCEs for
inter-AS (G)MPLS-
TE (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 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 may 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 As stated
earlier, PCECP responses SHOULD be able to compute the inter-AS TE LSP across AS boundaries carry path-segment
identifiers without detailed knowledge of the list details of hops, TE link metrics that path segment. An ASBR that
receives an RSVP-TE path message with an identifier object
(new object), it can use that object to contact the PCE keyed by
that identifier and
paths within each transit AS.

5.2.2. extract the identified path segment as well.

4.1.5.
Policy Controls Effecting inter-AS PCECP

Section 5.2.2. 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.

4.1.5.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.

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 An inter-AS PCE that receives such requests enforces
some policies applied to its neighboring inter-AS PCEs. These
policies may include rewriting some of the parameters' values or and
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. Parameters subject to policy include
bandwidth, setup/holding priority, Fast Reroute request,
Differentiated Services Traffic Engineering (DS-TE) Class Type (CT),
and others as specified in section 5.2.2.1 of [INTERAS-TE-REQ].

For path computation requests that are not compliant with configured
policies, the policy enforcing PCE PCECP SHOULD generate enable a PCE to send 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. errors.

4.1.5.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 A PCE receiving these
path computation requests need needs to be able to reinterpret some of the
attributes and adapt them to the native environment in their 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
In addition, the transit SPs along the inter-AS TE path may be a GMPLS
transport provider providers which may require reinterpretation of MPLS
specific PCE PCECP path request message messages 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 These interpretation policies must be specifiable on
a per-peer inter-AS PCE
requests from other AS(es) for its own AS TE implementations or to
signal to PCEs in the downstream AS(es).

6. AS basis as part of PCECP MIBs discussed
earlier.

5.
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 [PCECP-REQ] specifies
requirements that
apply to inter-AS PCECP messages:

- 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 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 protect against spoofing, snooping 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 These requirements become especially important in the PCC/PCE-PCE
communication. Inter-AS PCEs should have functions to avoid spoofing
PCC/PCE-PCE communication. multi-
AS case.

6.
IANA Considerations

This document makes no requests for IANA action.

7.
Acknowledgments

We would like to thank Adrian Farrel, Jean-Philippe Vasseur,
and Jean Louis Le Roux for their useful comments and suggestions.

8.
Authors' Addresses

Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com

Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com

Raymond Zhang
BT INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com

9.
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
(PCE) Based Architecture", draft-ietf-pce-architecture-04.txt, January
2006 draft-ietf-pce-architecture-05.txt
(Work in Progress) 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
06.txt (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).

10.
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]

[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,
September 2005, (work in progress).

[LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)
Hierarchy with Generalized MPLS TE", RFC4206, October 2005.

[GMPLS-ROUT] Kompella, et.

[PCEDP-REQ] J.L. Le Roux 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 "Requirements for Path Computation
Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work 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
progress).

[INTERD-TE-PDPC] Vasseur, Ayyangar 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. 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).

Intellectual Property Statement

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 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. ietf-
ipr@ietf.org.

Disclaimer of Validity

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.

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.