Internet DRAFT - draft-bitar-pce-inter-domain-frwk
draft-bitar-pce-inter-domain-frwk
Network Working Group Nabil Bitar
Internet Draft Verizon
Jean-Louis Le Roux
France Telecom
Category: Informational Raymond Zhang
BT Infonet
Expires: December 2006 June 2006
Framework for PCE based inter-domain path computation
draft-bitar-pce-inter-domain-frwk-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 represents a framework for computing G)MPLS-TE paths
across IGP-areas in a single AS, and across multiple ASes using a path
computation element (PCE).
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.
Bitar et al. Inter-domain PCE Framework [Page 1]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
Table of Contents
1. Introduction 2
2. Definitions and Requirements Statement 3
3. Reference Model for PCE-based inter-domain path computation 3
4. Inter-IGP-Area Operation 6
4.1 Inter-Area PCE Discovery 6
4.2 Inter-area Path Computation 6
4.2.1 Single PCE Computation 7
4.2.2 Multiple PCE path computation with inter-PCE communication 8
4.3 PCE Inter-area TED 9
4.4 Inter-Area PCECP 10
4.5 Optimality 10
4.6 Reoptimization 12
4.7 Diversepath computation 12
4.8.Considerations on PCE location 13
5. Inter-AS Operation13
5.1 PCE-based Inter-AS Routing 13
5.2 Inter-AS PCE Location 14
5.3 Inter-AS PCE Discovery 14
5.4 Inter-AS Path Computation 14
5.5 Path Diversity 14
5.6 Inter-AS (G)MPLS-TE Operations and Interoperability 15
5.7 Optimality 16
5.8 Reoptimization 16
6. Security Considerations 16
7. Author’s Addresses 17
8. Normative References 17
9. Informative References 17
10. Full Copyright Statement 17
11. Intellectual Property 17
1. Introduction
This document represents a framework for Path Computation Element (PCE)
based computation of(G)MPLS-TE paths across IGP-areas in one Autonomous
System (AS) and across multiple ASes. In addition, this document
identifies areas where additional protocol extensions or mechanisms are
needed to satisfy inter-AS and inter-area path computations.
In particular, this document defines a reference model for inter-domain
(inter-area and inter-AS) path computation. It describes how elements of
the PCE architecture, including: (1) PCE Communication Protocol (PCECP),
(2) PCE Discovery, (3) Policies, (4) Inter-domain Path Computation
Algorithms, and (5) Inter-Domain (G) MPLS-TE Signaling, cooperate in
path computation.
Bitar et al. Inter-domain PCE Framework [Page 2]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
2.Definitions and Requirements Statement
This document uses terminologies defined in [RFC3031], [RFC4105],
[RFC4216] and [PCE-ARCH]. It defines the following new terms:
PCECP: PCE Communication Protocol
PCEDP: PCE Discovery Protocol
Intra-Area PCE: A PCE responsible for computing (G)MPLS-TE paths
traversing a single area.
Intra-Domain PCE: Intra-Area or intra-AS PCE
Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths
traversing a single AS.
Inter-Area PCE: A PCE responsible for computing or taking part into
the computation of inter-area TE-LSPs, by possibly cooperating with
intra-area PCEs or other inter-area PCEs.
Inter-AS PCE: A PCE responsible for computing or taking part into
the computation of inter-AS TE-LSPs, by possibly cooperating with
intra-AS PCEs or other inter-AS PCEs.
Inter-Domain PCE: Inter-Area or Inter-AS PCE
3. Reference Model for PCE-based inter-domain path computation
An intra-domain PCE is responsible for path computation
within a single domain. An inter-domain PCE is responsible
for path computation across multiple domains. An inter-domain PCE is
associated with one or more domains that define its scope of
visibility. It serves paths computation request for inter-domain
paths, from PCCs or other inter-domain PCEs. When it has topology
visibility in all domains along the path it can directly compute the
inter-domain path. When it doesn't have topology visibility in all
domains along the path it needs to collaborate with other inter-
domain PCEs so as to compute an end-to-end path. An inter-domain PCE
may require the services of one or more intra-domain PCEs within
domains of its scope to compute intra-domain segments of an inter-
domain path. An inter-domain PCE can be an intermediate-PCE or a
terminating-PCE for a given LSP. An intermediate-PCE is associated
with transit domains whereas a terminating-PCE is associated with the
domain originating or terminating the path computation request.
Bitar et al. Inter-domain PCE Framework [Page 3]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
In this document, we define an inter-domain PCE is an inter-area or
inter-AS PCE and An intra-domain PCE is an intra-AS PCE or intra-area
PCE. An intra-AS PCE can be either an intra-area PCE or inter-area
PCE.
It should be emphasized that the differentiation between these
PCE types is functional as they can be implemented and enabled on the
same physical device. Depending on the location and use of there
different PCE types there are various options for PCE-based inter-
domain path computation.
An inter-area PCE may consult intra-area PCEs for computing intra-
area path segments within areas of its scope. Similarly an inter-AS
PCE may consult intra-AS PCEs (i.e. intra/inter area PCE) for
computing intra-AS path segments within ASes of its scope.
Figure 1 depicts an example for PCEs in an inter-domain application,
including both inter-area and inter-AS. In this example computation
rely on inter-AS and inter-area PCEs. As discussed above,an intra-AS
PCE can be either an inter-area or intra-area PCE, but for the sake
of simplicity, in this example we only use inter-area PCE to
illustrate the concept which covers both cases. 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-AS to
compute inter-AS (G)MPLS-TE paths. An inter-AS PCE may also
communicate with inter-area PCEs 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 External PCE, as
described in [PCE-ARCH]).
<======================inter-AS TE LSP R1-R7============>
Inter-AS Inter-AS Inter AS
PCC PCE1<------------->PCE2<------------------>PCE3
:: :: :: ::
R1---ASBR1====ASBR3-ABR1-R3-ABR2-ASBR5====ASBR7---R5---R7
| | | | | | | |
| | | | | | | |
R2---ASBR2====ASBR4-ABR4-R4-ABR3-ASBR6====ASBR8---R6---R8
:: ::
(Intra-AS Inter-area)
PCE4 PCE5
<==AS1=> <=========AS2========> <=====AS3===>
Figure 1 Inter-AS and Inter-area PCE Application Scenario
As shown from the diagram above, the LSR R1 at the head-end of an LSP
or a proxy on its behalf (either being a PCC) sends a path
Bitar et al. Inter-domain PCE Framework [Page 4]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
computation request to one of its inter-AS PCEs PCE1 upon
determining, via configuration or dynamic routing, that the tail-end
R7 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 PCE1
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. In our example, PCE1 sends the request to PCE2. Each
neighboring inter-AS PCE that receives the request determines its
neighbor inter-AS PCE(s) that it progresses the path request to. In
determining the inter-AS PCE to which the path request must be sent,
an inter-AS PCE may first qualify the path to an ASBR associated with
that inter-AS PCE and may exclude paths that do not satisfy the
constraints of the LSP e.g., by excluding ASBRs and inter-AS links
between the two neighboring ASs when there is not sufficient
bandwidth on the paths to these ASBRs or ASes to satisfy the LSP
bandwidth constraints). Before an intermediate inter-AS PCE PCE2
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 inter-area PCE(s) PCE4 and/or PCE5 in its own AS. 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 potentially by cooperating with inter-area PCEs if
any. 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., it may return an ASBR as a
strict hop and the LSP tail-end as a loose node). What could be
returned in the path computation response is generally controlled by
policy configuration. The inter-AS PCE PCE2 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 recurses until
the inter-AS PCE serving the LSP head-end receives a response to
its request(s) from the immediate inter-AS PCE(s) it sent requests
to. Every time an inter-AS PCE responds to a requestor it
concatenates each path it computes with a path it received from the
next immediate PCE, composes a cost for the total path and returns
the concatenated path(s) to the previous immediate requestor as per
defined in [BRPC]. It should be noted that the path(s) computed by a
Bitar et al. Inter-domain PCE Framework [Page 5]
nternet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
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. an intermediate node would expand the path between that
node and the next loose hop with strict hops in its own AS.
4.Inter-IGP-Area Operation
4.1. Inter-Area-PCE Discovery
A PCC must first discover the inter-area PCEs that serve its area and
the domain scope of that PCE. Similarly, an inter-area PCE must
discover other inter-area PCEs and their domain scopes. A PCC selects
a PCE from a set of discovered PCEs based on the discovered PCE
information and the destination of the (G)MPLS-TE LSP. Inter-area PCE
discovery is provided by a PCE discovery protocol [Inter-area-PCE-
Discovery] or via static configuration on the PCC.
In multi-PCE path computation, a PCE can learn with the PCECP request
message, in which area a destination is located. This requires for
the PCC to know the area in which the destination lies and to include
it in the request message. This may rely on configuration on the PCC
but may not be flexible.
When the PCC does not know in which area the destination lies it will
not include this information in the request message, and a PCE will
not learn in which area a destination is located if that area is not
within its scope. From IGP advertisements, it can only learn which
ABR can be used to reach the destination. Thus, it must use that
information to determine which PCE is serving the destination area.
This requires that an IGP discovery protocol identifies the ABRs
that are within its scope.
Most often, an inter-AS PCE could be selected to be an ABR that has
visibility into the topology and TE database of two or more attached
areas. When the PCE is an ABR, the PCE learns the necessary topology
information as part of normal IGP operations.
4.2. Inter-area path Computation
Bitar et al. Inter-domain PCE Framework [Page 6]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
There are various possible modes for PCE-Based inter-area path
computation. The computation of an inter-area optimal path can rely
on:
- a single PCE, that has enough topology visibility and can
alone compute an end-to-end optimal path,
- multiple PCEs, that have partial topology
visibility and collaborate with each other so as to arrive at
an end-to-end optimal path.
These two modes are referred as to "Single PCE computation" and
"Multiple PCE computation with inter-PCE communication" in [PCE-
ARCH]. Note that these two modes may co-exist in a given multi-area
network.
Note that the per-area path computation mode relying on route
expansion performed directly by ABRs on the path (which function has
composite PCEs), or on external PCEs contacted by the ABRs on the
path, consists in fact of a simple concatenation of intra area paths.
It actually only implies intra-area path computations and does not
allow computing inter-area optimal paths. Hence this mode is not
discussed in this document.
4.2.1. Single PCE Computation
In this mode the inter-area path computation is directly performed by
a single PCE that has enough topology information to compute an end-
to-end optimal path. No inter-PCE communication is required in this
mode.
This mode requires that the PCE have at least the Traffic Engineering
Database (TED) of all the crossed areas for a given LSP. The actual
distribution of PCEs may vary, i.e., a PCE may have a TE database
base from two, three or more IGP areas. If the head-end and tail-end
LSRs are located in two peripheral areas, the PCE must have the TED
of the source, backbone, and destination areas. In the particular
case where the head-end/tail-End LSR is located in the backbone area
and the tail-end/head-end LSR is located in a peripheral area, the
PCE only needs the TED of the backbone area and the peripheral area
to compute the path.
Figure 2 below illustrates an example of single PCE inter-area
computation.
------
| PCE0 |
/ ------ \
/ | \
/ | \
/ | \
/ | \
------------------------------------------
| | | |
| ABR2 ABR3 |
R1 area1 | area0 | area2 R2
| ABR1 ABR4 |
| | | |
------------------------------------------
Figure 2: Example of single PCE computation.
Bitar et al. Inter-domain PCE Framework [Page 7]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
In this multi area network PCE0 has topology visibility in area1,
area0 and area2 and can compute and end-to-end path from area 1 to
area 2. To setup an inter-area LSP from R1 in area 1 to R2 in area 2,
R1 has to directly contact PCE0.
Note that this mode may rely on PCEs that have knowledge of topology
in all areas. Such a PCE is called an "all-areas" PCE.
Particular attention should be given to the potential limitations of
this "all-areas" PCE approach, in terms of scalability. Such all-area
PCEs may have to maintain a large topology and this raises
scalability issues both in terms of memory to maintain the TED and
processing to synchronize TED information.
Also such all-area PCEs would potentially serve a large number of
PCCs, and hence may face a huge path computation request overload
during a network event such as link or node failure (that may impact
a large number of TE-LSPs on a large number of head-end LSRs). This
may significantly delay the TE-LSP recovery, and thus may diminish
the benefits of such an approach.
4.2.2. Multiple PCE path computation with inter-PCE communication
In this mode the computation of an optimal inter-area TE-LSP path is
distributed across multiple PCEs.
There is at least one PCE per area, and those PCEs do not have enough
topology visibility to compute and inter-area optimal path.
PCEs in each area compute path segments in their respective areas and
collaborate together to arrive at an end-to-end inter-area optimal
path. Such collaboration is carried using inter-PCE communication
protocol (PCEP).
The actual distribution of PCEs may vary, i.e. a PCE may have TE
database from one, two, or more IGP areas, and the important thing is
that the collection of topology and TE information maintained by a
set of PCEs, collectively, must cover all the IGP areasthat all
inter-area LSPs traverse.
Figure 2 and 3 below illustrate two examples of multiple PCE inter-
area computation
------ ------ ------
| PCE1 |<------>| PCE0 |<---->| PCE2 |
------ ------ ------
| | |
| | |
--------------------------------------------
| | | |
| ABR2 ABR3 |
R1 area1 | area0 | area2 R2
| ABR1 ABR4 |
| | | |
--------------------------------------------
Figure 3: Cooperation between single-area PCEs
Bitar et al. Inter-domain PCE Framework [Page 8]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
Figure 3 above illustrates a multi-area network with 3 areas. PCE0,
PCE1 and PCE2 are PCEs responsible for path computation respectively
in area 0, 1 and 2. These PCEs have topology visibility limited to
one area and are called single-area PCEs.
To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has
to contact PCE1. PCE1 then collaborates with PCE0, and PCE0 with PCE2
so as to compute an end-to-end shortest constrained path.
------ ------
| PCE1 | <----> | PCE2 |
------ ------
/ \ / \
/ \ / \
--------------------------------------------
| | | |
| ABR2 ABR3 |
R1 area1 | area0 | area2 R2
| ABR1 ABR4 |
| | | |
--------------------------------------------
Figure 4: Cooperation between multi-area PCEs
Figure 4 above illustrates a multi-area network with 3 areas. PCE1,
and PCE2 are PCEs responsible for path computation respectively in
area 0+1 and in area 0+2. This means that PCE1 and PCE2 have topology
visibility in area0+area1 and area0+area2, respectively.
To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has
to contact PCE1. PCE1 then collaborates with PCE to compute an end-
to-end shortest constrained path.
4.3. PCE Inter-area TED
Bitar et al. Inter-domain PCE Framework [Page 10]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
The topology visibility of an inter-area PCE depends on the path
computation mode:
- A mono-area-seeing PCE has topology visibility within a
single area
- A multi-area-seeing PCE has topology visibility into two or
more areas. In particular, an all-area-seeing PCE has topology
visibility within the entire AS.
There are various means for a PCE to discover the TED of a given
area. In order to ensure path computation accuracy, PCE TEDs should
be as far as possible synchronized with the network TED.
A mono-area-seeing PCE would have to get the TED of a single area. If
the PCE is an LSR, it directly gets the TED from the IGP. If the PCE
is a server it may discover the TED by running the IGP and
maintaining an IGP adjacency with one or more LSRs of the area,
called "seed LSRs". Note that in this case the link between the PCE
and the see-LSR must not be part of the LSDB. Note that the PCE and
seed LSR may not be directly connected, in which case the IGP
adjacency may be built on top of a tunnel connecting the two elements
(e.g. a GRE tunnel).
A multi-area-seeing PCE would have to get the TED of multiple areas.
If the PCE is an ABR, it directly gets from the IGP the TED of the
backbone area and its attached peripheral areas. If the PCE is a
server, it may run the IGP and maintain IGP adjacencies with
seed LSRs Located in each area of its scope. In this case the use of
ABRs as seed LSR would reduce the amount of adjacencies required.
Note that this may raise scalability issues as the number of areas
within the PCE scope increases. In particular the all-area-seeing PCE
approach may face some limitations regarding the amount of
information to be stored, the processing required to keep the TED
synchronized, and to maintain IGP adjacencies with all seed LSRs.
An inter-area PCE may also discover the TED by other means (SNMP TE-
Link MIB, proprietary interface…)
4.4.Inter-Area PCECP
PCECP is used to communicate path computation requests and responses
between PCC and inter-area PCE, between inter-area PCEs and
potentially between inter-area PCEs and intra-area PCEs.
4.5. Optimality
In a single IGP domain, it is expected that the link costs will be
assigned with the same semantics (e.g., delay). In that case, the
costs of links in different areas could be added without the need for
any normalization. It will be guaranteed that the computed path for
Bitar et al. Inter-domain PCE Framework [Page 10]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
an LSP will be the shortest path that satisfies the TE constraints of
the LSP.
In order to illustrate the optimality of the resulting path, consider
the case of path computation using per domain path computation
illustrated in Figure 5 as show below:
<======inter-area TE LSP t0======>
(PCC) (PCE) (PCE)
R1-------ABR1---------ABR3-------R2
\ | / | /
\ | ------- | /
\ | / | /
-----ABR2---------ABR4-----
<-area1-><--area0----><--area2->
Figure 5: inter-area path computation
A TE-LSP is being placed with head-end R1 in area1 and tail-end R2 in
area2. R1 has summary reachability information to R2 advertised by
ABR1 with cost 2 and by ABR2 with cost 2. In per-domain path
computation, R1 computes the cost to get to R2 via ABR1 and it finds
to be 3 which is a tie with that of going through ABR2, but as a tie-
breaker it selects ABR1. In addition, the local path segment R1-ABR1
satisfies the LSP TE constraints. R1 signals the TE-LSP with ABR1 as
a strict hop and R2 as a loose hop. When the RSVP-TE path message
gets to ABR1, ABR1 performs another lookup to determine the path
segment within the backbone. While ABR1-ABR3 results in the shortest
path, that path does not satisfy the TE constraints. ABR1 is forced
t0 select path ABR1-ABR2-ABR3 with cost 2. ABR3 in turns performs its
per domain path computation and selects the direct link to R2 on the
path. The resulting path is R1-ABR1-ABR2-ABR3-R2 with cost 4.
Using the PCE-based approach, and assuming ABR1 and ABR3 are PCEs for
area1-area0 and area0-area2 respectively, R1 sends a path computation
request to ABR1 as a PCE. ABR1 determines the PCE it needs to contact
to compute a path to the destination is ABR3. ABR1 sends a path
computation request to ABR3. ABR3 computes a path to the destination
R2 and returns ABR1-ABR2-ABR4-R2 and ABR2-ABR4-R2 as possible paths
with costs of 3 and 2, respectively. ABR1 then computes a path within
area1 with strict hops being ABR1 and ABR2. The first path when R1-
ABR1 when concatenated with ABR1-ABR2-ABR3-R2 has a cost of 4 and the
second path R1-ABR2 when concatenated with path ABR2-ABR4-R2 has a
cost of 3. Thus, ABR1 selects path R1-ABR2-ABR4-R2 and returns to R1.
Contrary to the per-domaon based approach, the PCE-based approach
results in the optimum path computation as the full topology and link
resources are known to the collective set of PCEs that collaborate to
perform the path computation while the per domain path computation is
blinded to global optimization by local optimization within an area.
Bitar et al. Inter-domain PCE Framework [Page 11]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
4.6. Reoptimization
Note that here we focus on end-to-end inter-area path reoptimization
and not on per-area path reoptimization. Per-area path reoptimization
does not allow global reoptimization of an inter-area TE-LSP.
When there are resource changes within any area on the path of an
already established LSP, a more optimal end-to-end path may have
become available.
An end-to-end path reoptimization is under control of the head-end
LSR. Once a head-end LSR desire to perform an end-to-end
reoptimization its sends a request message to its PCE, indicating
that this is a request for a reoptimization. The request message may
include the previously computed path so as to avoid double bandwidth
accounting.
Note that an head-end LSR may not be aware of a change in another
area.
A reoptimization may be triggered:
-Via management action, in reaction to a network event.
-Periodically, on a timer driven basis, the head-end LSR send a
requests for re-optimization to the inter-area PCE, and if the
returned path is distinct from the current path may decide to
reroute the LSP in a make-before-break manner. This decision is
driven by local policies.
-Dynamically, on an event driven basis. A head-end LSR may be
aware of a change in another area thanks to IGP advertisements
(IGP metric change) or thanks to signaling notification [LOOSE-
REOPT]. When a change is detected the head-end LSR sends a
request for re-optimization to its inter-area PCE.
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 PCEs, specifically, inter-area PCEs. Similarly,
if path re-optimization is attempted periodically and if PCC timers
are synchronized PCEs could become overloaded.
Therefore, as discussed in [PCE-COM-REQ] PCCs that initiate requests
for path computation should implement mechanisms that pace path re-
optimization requests and avoid network activity synchronization.
4.7. Diverse path computation
To compute two diverse paths, a PCC or transit inter-area PCE must
include in the PCECP request message multiple correlated requests and
indicate the desired level of intra-area diversity (link, node, SRLG)
on a per-area basis as well as the level of inter-area diversity (ABR
disjointness).
Bitar et al. Inter-domain PCE Framework [Page 12]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
4.8.
Considerations on PCE location
As explained in [PCE-ARCH] a PCE can be a LSR or a network server.
But note that in the inter-area context, it may be quite efficient
for the ABRs to act as PCEs. Indeed, ABRs have topology information
of the backbone area and at least one peripheral area. An inter-area
TE-LSP optimal path computation could rely on a single ABR, if the
path crosses only two IGP areas, or on collaboration between two ABRs
in case the path crosses three IGP areas.
For instance, in figure 4 above, ABR1 or ABR2 can play PCE1 role, and
similarly ABR3 or ABR4 can play PCE2 role. Note that such ABRs are
not necessarily transit LSRs on the computed inter-area TE LSP.
With such PCE distribution on ABRs, the PCECP would run directly
between LSRs. Note that if N peripheral areas are connected to one
backbone area, with at least N ABRs, inter-area path computation
would potentially require a full mesh of N^2 PCE-PCE communications
between ABRs.
5. Inter-AS Operation
5.1. PCE-based Inter-AS Routing
Inter-AS PCE-based path computation does not impose any additional
requirements on inter-AS routing. Particularly, there are no inter-AS
TE information exchanged using BGP.
Thus, the TE information of a given AS is confined to that AS. Path
computation procedures for inter-AS paths rely on intra-AS (intra or
inter-area) path computation as explained in the previous section to
compute an intra-AS path computation with an extended AS TED that
includesinter-AS TE links.
An inter-AS PCE could be a LSR 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 in which the tail-end and head-end of
the LSP reside and it may also have the AS path to the LSP tail-end.
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. Alternatively, the PCE itself could be an ASBR with
BGP peering relationship with other ASes. One or more of these ASBRs
could be within the scope of the PCE. 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
Bitar et al. Inter-domain PCE Framework [Page 13]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
the path computation to the tail-end. The inter-AS PCE may have to
interact with intra-area PCEs and potentially 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 or
there may be no interaction at all, if the inter-AS PCE process
includes intra-area CSPF for example. Thus, a PCE LSR or PCE server
can implement all PCE functions and acquire topological information,
including the TED, for ASes within its scope.
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 should be well defined to avoid
interoperability issues. 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.
5.2. Inter-AS PCE Location
TBC (may be merged with section 5.1)
5.3. Inter-AS-PCE Discovery
Inter-AS PCE Discovery can be done via static configuration or
dynamically. PCE discovery allows one inter-AS PCE to discover
capabilities and scope (which ASes they operate in) of other inter-
AS PCEs. During path computation, one inter-AS PCE selects which of
the discovered PCEs it needs to send requests to based on
reachability information, which AS it learns that information, and
which PCE covers that AS.
5.4. Inter-AS Path Computation
TCB
5.5. Path Diversity
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 or different pairs of 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 level of diversity should be specified by
the PCC, one may want to request for link/node/SRLG diversity on a
Bitar et al. Inter-domain PCE Framework [Page 14]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
per AS basis, and also ASBR diversity and AS diversity, etc..
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.
5.6. Inter-AS (G)MPLS-TE Operations and Interoperability
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 6 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 n AS2 (ASBR3). ASBR3 makes a request to
its serving inter-AS PCE_AS2 for a path that satisfies the LSP
constraints to the destination. PCE_AS2 determines that the
destination is reachable via AS3 and subsequently sends a path
computation request to PCE_AS3 (the serving inter-AS PCE for AS3
which serves connection setup requests between AS2 and AS3). PCE_AS3
computes a path within its domain and returns to PCE_AS2 which in
turns computes a path from ASBR3 to the ASBR connected to the
returned path from PCE_AS3 and returns the concatenated path to
ASBR3. ASBR3 can then setup the TE-LSP along this path.
Non PCE PCE_AS2 PCE_AS3
Inter-AS Path Inter-AS Path Inter-AS Path
Computation Computation
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 6.Non-PCE and PCE path computation scopes
Bitar et al. Inter-domain PCE Framework [Page 15]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
5.7. Optimality
TBC
5.8. Reoptimization
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.
6. Security Considerations
TBC
Bitar et al. Inter-domain PCE Framework [Page 15]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
7. Author’s Addresses
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.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
[PCE-ARCH] Farrel, Vasseur & Ash, “Path Computation Element (PCE)
Architecture”, draft-ietf-pce-architecture-02.txt, March 2006
(Work in Progress)
[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, “A Per-domain path
computation method for computing Inter-domain Traffic Engineering
(TE) Label Switched Path (LSP)”, draft-ietf-ccamp-inter-domain-pd-
path-comp-00.txt , October 2005, (Work in Progress)
[BRPC], Vasseur, etc., “A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic
Engineering Label Switched Paths, draft-vasseur-pce-brpc-01.txt,
December 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)
10.
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.
Bitar et al. Inter-domain PCE Framework [Page 17]
Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
11.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
