Network Working Group Xuerong Wang
Internet-Draft Muliu Tao
Intended status: Informational Xihua Fu
Expires: January 12, 2012 Qilei Wang
Kexin Tang
ZTE Corporation
July 11, 2011
Extensions of Backward-Recursive PCE-Based Computation (BRPC) to Support
Inter-Autonomous System (AS) Bidirectional LSP Path Computation
draft-wang-pce-inter-as-extentions-01.txt
Abstract
This document provides extensions for the Backward-Recursive PCE-
Based Computation (BRPC) to support bidirection LSP path computation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 12, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Xuerong Wang, et al. Expires January 12, 2012 [Page 1]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Inter-AS Information Advertised by IGP . . . . . . . . . . 4
3.2. Backward Recursive Path Computation . . . . . . . . . . . 5
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
4. Solutions of Inter-AS bidirectional path computation . . . . . 7
4.1. Extensions of Backward-Recursive PCE-Based Computation
(BRPC) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Extensions of PCEP . . . . . . . . . . . . . . . . . . . . 9
4.2.1. IVSPT flag . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. BRPC Procedure Completion Failure . . . . . . . . . . 10
4.2.3. Inter-AS TE links carried in PCEP message . . . . . . 11
4.2.3.1. Definition of IVSPT(i) . . . . . . . . . . . . . . 11
4.2.3.2. Constrain Route Object(CRO) . . . . . . . . . . . 13
4.2.3.3. IVSPT Encoding . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Xuerong Wang, et al. Expires January 12, 2012 [Page 2]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
1. Introduction
Requirements for establishing Multiprotocol Label Switching Traffic
Engineering (MPLS-TE) Label Switched Paths (LSPs) that cross multiple
Autonomous Systems (ASes) are described in [RFC4216]. As described
in [RFC4216], a method SHOULD provide the ability to compute a path
spanning multiple ASes. So a path computation entity that may be the
head-end Label Switching Router (LSR), an AS Border Router (ASBR), or
a Path Computation Element [PCE] needs to know the TE information not
only of the links within an AS, but also of the links that connect to
other ASes.
As described in [RFC5392], two new LSAs are defined to advertise
inter-AS TE information for OSPFv2 and OSPFv3 separately, and three
new sub-TLVs are added to the existing Link TLV to carry the
information about the neighboring AS and the remote ASBR. [RFC5316]
defines similar extensions for [ISIS].
In order for bidirection path computation, PCE needs to get
bidirection Inter-AS TE link information. [RFC5392] introduces a
"proxy" for the ASBR at the edge of the other AS and generate a
bidirection TE link.
This document extends BRPC in order to support the bidirection path
computation within single procedure. Based on the mechanism in this
document, we don't need to introduce the 'proxy'. It shows how the
Backward-Recursive PCE-Based Computation (BRPC) - procedures for
Inter-AS TE Links can be extended in order for deriving the optimum
end-to-end bidirection path.
This document does not propose or define any mechanisms to advertise
any other extra-AS TE information within IGP.
1.1. 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 [RFC2119].
2. Terminology
o ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different service providers via one
or more inter-AS links.
o Boundary Node (BN): a boundary node is either an ABR in the
context of inter-area Traffic Engineering or an ASBR in the
Xuerong Wang, et al. Expires January 12, 2012 [Page 3]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
context of inter-AS Traffic Engineering.
o Entry BN of domain(n): a BN connecting domain(n-1) to domain(n)
along a determined sequence of domains.
o Exit BN of domain(n): a BN connecting domain(n) to domain(n+1)
along a determined sequence of domains.
o PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element.
o PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
o PCE(i) is a PCE with the scope of domain(i).d
o TED: Traffic Engineering Database.
o VSPT: Virtual Shortest Path Tree.
o IVSPT: Inter-AS Virtual Shortest Path Tree.
3. Introduction
3.1. Inter-AS Information Advertised by IGP
As mentioned in [RFC5392] and [RFC5316], Hellos MUST NOT be exchanged
over the Inter-AS TE link, and consequently, an IGP adjacency MUST
NOT be formed.
In the current operation of TE IGP, the LSRs at each end of a TE link
emit LSAs describing the link. The databases in the LSRs then have
two entries (one locally generated, the other from the peer) that
describe the different 'directions' of the link. This enables
Constrained Shortest Path First (CSPF) to do a two-way check on the
link when performing path computation and eliminate it from
consideration unless both directions of the link satisfy the required
constraints.
In the case we are considering here (i.e., of a TE link to another
AS), there is, by definition, no IGP peering and hence no bidirection
TE link information.
The information advertised comes from the ASBR's knowledge of the
unidirection TE capabilities of the link, the ASBR's knowledge of the
Xuerong Wang, et al. Expires January 12, 2012 [Page 4]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
unidirection current status and usage of the link, and configuration
at the ASBR of the remote AS number and remote ASBR TE Router ID.
For other properties, e.g., bandwidth and metrics, an ASBR is
difficult or impossible to get the latest value of these properties
about reverse directional of Inter-AS TE links timely. In order for
the CSPF route computation entity to include the link as a candidate
path, we have to find a way to solve this problem.
3.2. Backward Recursive Path Computation
The Backward Recursive Path Computation (BRPC) [RFC5441] procedure
involves cooperation and communication between PCEs in order to
compute an optimal end-to-end path across multiple domains. Each PCE
creates a tree of potential paths from every entry BN to the LSP
destination (the Virtual Shortest Path Tree - VSPT) and passes this
back to the previous PCE in a PCRep. Each PCE in turn adds to the
VSPT and passes it back until the PCE in the source domain uses the
VSPT to select an end-to-end path .
In the case of inter-domain LSP computation, PCE(i)(i=n-1 to 2) also
requires adding the inter-AS TE links that connect the domain(i) and
the domain(i+1).
3.3. Problem Statement
Following scenarios illustrate the problem.
Case 1: Inter-AS link failed in only one direction
A---B1---- C1---Z
\ | | /
\ | | /
\ | | /
B2---- C2
:
<--AS1-->:<-- AS2-->
Figure 1: multi-AS network
Considering multi-AS network shown in Figure 1,PCE1 responsible for
the computation of AS1, and PCE2 responsible for the computation of
AS2 . Bidirection Inter-AS link between B1 and C1 consists of two
unidirectional inter-AS links, one is from B1 to C1,another is from
C1 to B1. For the inter-AS links do not exchange IGP information,
PCE1 and PCE2 seperately have the TE properties of one direction of a
bidirection inter-AS link.
Xuerong Wang, et al. Expires January 12, 2012 [Page 5]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
As described in RFC5441: In the case of inter-domain LSP computation,
PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that
connect the domain(i) and the domain(i+1).
For unidirection LSP computation from A to Z: Because PCE1 has the TE
properties in one direction (i.e.,B1-->C1, B2-->C2) of the inter-AS
links, PCE1 knows which inter-AS link can be added. So PCE1 can
compute LSP within AS1 attached add the unidirectional inter-AS links
that connect AS1 to AS2 (i.e., B1-->C1, B2-->C2).
For bidirection LSP computation from A to Z : Suppose the inter-AS
link fails in one direction( e.g. ,from C1 to B1), Which inter-AS
link should be selected for the bidirectional path? Obviously, PCE1
can't select proper inter-AS TE links without any enough information.
Case 2: bandwidth of bidirection inter-AS link is different in two
directions
Z1 A1
\ /
B------C
/ \
A2 Z2
:
<--AS1-->:<--AS2-->
Figure 2: multi-AS MPLS-TP network
Figure 2 shows a multi-AS MPLS-TP network, where AS1 and AS2 are
MPLS-TP networks. PCE1 and PCE2 are responsible for the computation
of corresponding AS.
Suppose unidirection LSP along A1-C-B-Z1 have already been setup, and
bandwidth has been reserved for the LSP. For the inter-AS link
between B and C, bandwidth of link that is from B to C is not the
same as that is from C to B. If we want to create a co-routed
bidirection LSP from A2 to Z2, suppose bandwidth of inter-AS link
only satisfy the constraints in one direction. Neither PCE1 nor PCE2
knows which bidirectional inter-AS link could be select.
Case 3: multi-inter-AS links connect to one ASBR
Xuerong Wang, et al. Expires January 12, 2012 [Page 6]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
A----B1----C1----Z
\ | \ / | /
\ | X | /
\ | / \ | /
B2----C2
:
<-- AS1 -->:<---- AS2 --->
Figure 3: multi-inter-AS links connect to one ASBR
Suppose unidirectional inter-AS link from C1 to B1 doesn't satisfy
the constraints. As previous case shown in figure1, there is only
one inter-AS link connect to each ASBR node. PCE2 has the ability to
check that unidirectional inter-AS link from C1 to B1 does not
satisfy the constraints, and then it can simply delete the path C1 to
Z from VSPT and only passes path C2 to Z in PCRep to PCE2 . But if
there are more than one inter-AS links connected to one ASBR, and not
all of the unidirectional inter-AS links don't satisfy the
constraints, there still be some problem:
In figure 3, there are more than one inter-AS links connected to one
ASBRs. Suppose a bidirectional LSP from A to Z is going to be
created and only unidirectional inter-AS link from C1 to B1 doesn't
satisfy the constraints.VSPT computed by PCE2 consists of two paths:
C1 to Z and C2 to Z. So in figure 3, PCE1 can not delete the path C1
to Z from VSPT. Similarly,How can PCE1 or PCE2 know which inter-AS
links to select?
4. Solutions of Inter-AS bidirectional path computation
4.1. Extensions of Backward-Recursive PCE-Based Computation (BRPC)
As described in RFC5441: In the case of inter-domain LSP computation,
PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that
connect the domain(i) and the domain(i+1).The problem about Inter-AS
TE links described in previous section focus on : In the case of
bidirection LSP computation, if PCE adds the inter-AS TE links ,it
must know which of the inter-AS links that can be added.
In our solution, PCE can select inter-AS links that satisfy the
constraints and carry them in the computing reply message(Specially
in case3 shown in previous section, PCE2 must let PCE1 know which
unidirection inter-AS link satisfy the constraints).
With the following extensions of BRPC procedure we can get these
proper inter-AS TE links for the bidirection LSP:
Xuerong Wang, et al. Expires January 12, 2012 [Page 7]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
o After computing the shortest constrained paths(i.e., VSPT) between
every entry BN and the TE LSP destination, PCE(i+1) selects the
Inter-AS TE links from AS(i+1) to AS(i) that satisfy the
constraints and passes them back to the PCE(i) in a PCRep.
o Then, the PCE(i) can choose among the Inter-AS TE links carried in
received PCRep message that satisfy the constraints in the reverse
direction ,and compute the shortest constrained paths between
every exit BN and the TE LSP destination.
Following is the extended BRPC procedure:
o Step 1:
First, the PCC needs to determine the PCE capable of serving its
path computation request (this can be done with local
configuration or via IGP discovery (see [RFC5088] and [RFC5089])).
The path computation request is then relayed until reaching a
PCE(n) such that the TE LSP destination resides in the domain(n).
This step is the same as described in [RFC5441].
o Step 2:
2.1. PCE(n) computes the list of shortest constrained paths
between every BN-en(j,n) and the TE LSP destination;
2.2. PCE(n) selects the Inter-AS TE links that satisfy the
constraints from all of the Inter-AS TE links that provide
connectivity from domain (n) to domain(n-1);
2.3. PCE(n) returns PCRep (including result of 2.1 and 2.2) to
PCE(n-1).
Note that for unidirection LSP computation, step 2.2 may not be
performed.
o Step i:
For i=n-1 to 2: {
i.1. With the Inter-AS TE links returned from PCE(i+1), PCE(i)
chooses the links that satisfy the constraints in the reverse
direction(i.e., the selected Inter-AS TE links satisfy the
required constraints in both of the directions.)
i.2. PCE(i) computes the shortest constrained paths between each
BN-en(j,i) and the TE LSP destination; PCE(i)(i=n-1 to 2) requires
adding the inter-AS TE links that concluded by i.1.
Xuerong Wang, et al. Expires January 12, 2012 [Page 8]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
i.3. PCE(i) selects the Inter-AS TE links that unidirectionally
satisfy the constraints from all of the Inter-AS TE links that
provide connectivity from domain (i) to domain(i-1);
i.4. PCE(i) returns PCRep (including result of i.2 and i.3) to
PCE(i-1). }
Note that for unidirection LSP computation, step i.1, and i.3 may
not be performed.
o Step n:
n.1. With the Inter-AS TE links returned from PCE(2), PCE(1)
chooses the links that satisfy the constraints in the reverse
direction (i.e., the selected Inter-AS TE links satisfy the
required constraints in both of the directions.);
n.2. PCE(1) computes the end-to-end shortest constrained path.
PCE(1) requires adding the inter-AS TE links that concluded by
n.1.
Note that for unidirection LSP computation, step n.1. may not be
performed.
Note that uni-direction represents the direction from entry BNs of
local domain i to exit BNs of domain i-1, the reverse direction
represents the direction from exit BNs of local domain i to entry BNs
of domain i+1.
4.2. Extensions of PCEP
As described in RFC5440, if the path computation request can be
satisfied, the set of computed paths specified by means of Explicit
Route Objects (EROs) is inserted in the PCRep message.In the scenario
of inter-domain path computation using BRPC procedure,the ERO
represents the VSPT, i.e.,the paths satisfy the constraints between
every entry BN and the LSP destination.
For the following reasons, a new object CRO (see 4.2.3) is introdued
to represent the inter-AS links:
o l For the bidirection LSP solution introduced in this document,
the inter-AS links carried in PCRep satisfy the constraints only
in one direction. These inter-AS links only partially satisfy the
constraints, and wait for neighbor PCE to confirm the constraints
in reverse direction. These partially confirmed inter-AS links
are not the compute results and only used to notify neighbor PCE
to confirm. So the inter-AS links carried in PCRep need to
Xuerong Wang, et al. Expires January 12, 2012 [Page 9]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
differentiate from ERO that represents the computation result.
o To include inter-AS links by ERO needs to stitch VSPT and inter-AS
links. In the case there are more than one inter-AS links connect
to one ASBR, e.g., in figure 3, ERO C1--Z represent the path from
the ASBR C1 to the destination Z. Suppose both of the two inter-AS
links C1--B1 and C1--B2 satisfy the constraints, then maybe we
need to copy C1--Z to two EROs, one stitchs inter-AS link B1--C1,
the other stitchs inter-AS link B2--C1. So there maybe some
repeated information.
4.2.1. IVSPT flag
PCEP needs to be introduced a new flag in RP object carried within
the PCReq message (defined in [RFC5440]). The PCE(i) set this flag
in PCReq to indicates that the Inter-AS TE links from AS(i+1) to
AS(i) satisfying the constraints must be return. In other words, the
PCE(i) requests the computation of an inter-domain TE LSP using the
new BRPC procedure defined in this document, and Inter-AS TE links
from AS(i+1) to AS(i) satisfying the constraints must be included in
PCRep.
The following new flag of the RP object is defined:
IVSPT Flag
Bit Number Name Flag
------- ------
TBD IVSPT
4.2.2. BRPC Procedure Completion Failure
If PCE(i) send IVSPT flag to PCE(i+1) who doesn't recognizes the
IVSPT flag of RP object, PCE(i+1) MUST generate PCErr message with an
Error-Type=4 (Not supported object), Error-value=4 (Unsupported
parameter). The PCE may include the parent object (RP object) up to
and including (but no further than) the unknown or unsupported
parameter. In this case where the unknown or unsupported parameter
is a bit flag (IVSPT flag), the included RP object should contain the
whole bit flag field with all bits after the parameter at issue set
to zero. The corresponding path computation request is then
cancelled by the PCE without further notification.
If PCE(i) send IVSPT flag to PCE(i+1) who recognizes IVSPT flag of RP
object but does not support the new BRPC procedure extended in this
document, it MUST return a PCErr message to the upstream PCE with an
Error-Type " Enhanced BRPC procedure unsupported".
Xuerong Wang, et al. Expires January 12, 2012 [Page 10]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
The PCErr message MUST be relayed to the requesting PCC.
PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-value are managed by IANA.
A new Error-Type is defined that relates to the BRPC procedure.
Error-Type Meaning
-------- -------
TBD Enhanced BRPC procedure unsupported
Error-value
1 Enhanced BRPC procedure not supported
by one or more PCEs along the domain path
4.2.3. Inter-AS TE links carried in PCEP message
For the bidirection Inter-AS TE LSP BRPC procedure referenced in this
document, PCE(n) should select the unidirection Inter-AS TE links
that satisfy the constraints from all of the Inter-AS TE links that
provide connectivity from domain (n) to domain(n-1),and then PCE(n)
should return the selected Inter-AS TE links in PCRep message.
We introduce a new object (Inter-AS Virtual Shortest Path Tree
-IVSPT) to carry the selected Inter-AS TE links (see 4.2.3.1.).
4.2.3.1. Definition of IVSPT(i)
Mode of BRPC Operation is introduced in [RFC 5441]:
Definition of VSPT(i)
In each domain i:
o Step 1: There is a set of X-en(i) entry BNs noted BN-en(k,i) where
BN-en(k,i) is the kth entry BN of domain(i).
o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN-
ex(k,i) is the kth exit BN of domain(i).
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to
PCE(i-1):
Xuerong Wang, et al. Expires January 12, 2012 [Page 11]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
Root (TE LSP destination)
/ | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
where [X-en(i)] is the number of
entry BNs in domain i and j<= [X-en(i)]
Figure 4: MP2P VSPT
Each link of tree VSPT(i) represents the shortest constrained path
between BN-en(j,i) and the TE LSP destination that satisfies the set
of required constraints for the TE LSP (bandwidth, affinities,
etc.).These are path segments to reach the TE LSP destination from
BN-en(j,i).
Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
only the BNs that provide connectivity from domain(i-1).
Besides VSPT, this document defines Inter-AS Virtual Shortest Path
Tree (IVSPT) used for describing unidirection Inter-AS paths whose
direction is from AS(i) to AS(i-1).
Definition of IVSPT(j,i) :
IVSPT(j,i): jth MP2P (multipoint-to-point) tree returned by PCE(i) to
PCE(i-1)
Xuerong Wang, et al. Expires January 12, 2012 [Page 12]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
IVSPT(1,i):
BN-en(1,i)
/ | \
BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k1,i-1).
IVSPT(2,i):
BN-en(2,i)
/ | \
BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k2,i-1).
IVSPT(j,i):
BN-en(j,i)
/ | \
BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(kj,i-1).
where
[X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)],
[Y-ex(i-1)] is the number of exit BNs in domain i-1
and k1,k2,...,kj<= [X-ex(i-1)]
Figure 5: IVSPT
IVSPT(j,i) represents the Inter-AS paths from BN-en(j,i) of domain i
to exit BNs of domain i-1 that satisfies the set of required
constraints for the TE LSP (bandwidth, affinities, etc.).
4.2.3.2. Constrain Route Object(CRO)
The CRO is used to encode the Inter-AS paths that satisfies the set
of required constraints for the TE LSP.
The CRO is carried within a PCRep message to provide the selected
Inter-AS links if the path computation was successful.
The contents of this object are identical to the contents of the
RSVP-TE ERO defined in [RFC3209], [RFC3473], and [RFC3477]. That is,
the object is constructed from a series of sub-objects. Any RSVP-TE
ERO sub-object already defined or that could be defined in the future
for use in the RSVP-TE ERO is acceptable in this object.
Xuerong Wang, et al. Expires January 12, 2012 [Page 13]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-objects:
Type Sub-object
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
Figure 6: Format of CRO
The format of the PCRep message is updated as follows :
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>][<CRO-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<CRO-list>::=< CRO >[< CRO -list>]
Xuerong Wang, et al. Expires January 12, 2012 [Page 14]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
4.2.3.3. IVSPT Encoding
The IVSPT is returned within a PCRep message. The encoding consists
of a non-ordered list of Constrain Route Objects (CROs) where each
CRO represents an Inter-AS link that satisfy the required constraint
from domain i to domain i+1.
Example:
R1------R3----R5-----R7------R9-----R11---- R13
| \ | \ | / | /
| \ | \ | ---- | ----------
| \ | \ | / | /
R2------R4----R6-----R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<------- AS3 --------->
Figure 7: An Example of Inter-AS path computation
In the example shown in Figure 7, if we make the assumption that a
constrained path exists between each ABR and the destination R13, the
VSPT computed by a PCE(3) serving AS 3 consists of the following non-
ordered set of EROs:
o ERO1: R9(TE Router ID)-R11(Interface IP address)-R13(TE Router ID)
o ERO2: R10(TE Router ID)-R13(TE Router ID)
If we make the assumption that Inter-AS links R9-->R7 ,R9-->R8 and
R10-->R8 satisfy the required constraints, the IVSPT selected by a
PCE(3) serving AS 3 consists of the following non-ordered set of
CROs:
o CRO1: R9(Interface IP address),R7(TE Router ID)
o CRO2: R9(Interface IP address),R8(TE Router ID)
o CRO3: R10(Interface IP address),R8(TE Router ID)
5. Security Considerations
TBD.
6. IANA considerations
TBD.
Xuerong Wang, et al. Expires January 12, 2012 [Page 15]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
7. Acknowledgments
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009.
Xuerong Wang, et al. Expires January 12, 2012 [Page 16]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
8.2. Informative References
[H-PCE] D. King, "The Application of the Path Computation Element
Architecture to the Determination of a Sequence of Domains
in MPLS & GMPLS", draft-king-pce-hierarchy-fwk-03.txt .
Authors' Addresses
Xuerong Wang
ZTE Corporation
6F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road,
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 755 26773609
Email: wang.xuerong@zte.com.cn
URI: http://www.zte.com.cn/
Muliu Tao
ZTE Corporation
4F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road,
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 755 26773609
Email: tao.muliu@zte.com.cn
URI: http://www.zte.com.cn/
Xuerong Wang, et al. Expires January 12, 2012 [Page 17]
Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011
Xihua Fu
ZTE Corporation
ZTE Plaza, No.10, Tangyan South Road,
Gaoxin District,Xi'An 710065
P.R.China
Phone: +86 29 85458058
Email: fu.xihua@zte.com.cn
URI: http://www.zte.com.cn/
Qilei Wang
ZTE Corporation
No.50 Software Avenue,
Yuhuatai District, Nanjing 210012
P.R.China
Phone: +86 25 88014224
Email: wang.qilei@zte.com.cn
URI: http://www.zte.com.cn/
Kexin Tang
ZTE Corporation
No.50 Software Avenue,
Yuhuatai District, Nanjing 210012
P.R.China
Phone: +86 25 88014224
Email: tang.kexin@zte.com.cn
URI: http://www.zte.com.cn/
Xuerong Wang, et al. Expires January 12, 2012 [Page 18]