Network Working Group XH. Fu
Internet-Draft YL. Bao
Intended status: Informational ZTE Corporation
Expires: September 1, 2011 YL. Zhao
J. Zhang
Y. G
BUPT
February 28, 2011
A Dual-end Recursive PCE-Based Computation (DRPC) Procedure to Compute
Shortest Constrained Inter-domain Traffic Engineering Label Switched
Paths
draft-fuxh-pce-drpc-02
Abstract
A dual-end recursive PCE-based computation procedure (DRPC) is
proposed to compute shortest constrained inter-domain traffic
engineering label switched paths based on BRPC in Multi-protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. By
recursively performing shortest path algorithm and transferring the
segmental path computation result from both ends bi-directionally,
they meet at one of the Middle PCEs, generating a directional
shortest path graph into which the two shortest path trees are
stitched together. Therefore, the end-to-end constrained inter-
domain traffic engineering label switched path, even k shortest paths
can be gained from the directional shortest path graph directly.
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 September 1, 2011.
Copyright Notice
Fu, et al. Expires September 1, 2011 [Page 1]
Internet-Draft DRPC Procedure February 2011
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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. DRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PCE Sequence Selection Approaches . . . . . . . . . . . . 5
4.2. DRPC Procedure . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Stitching PCE Selection . . . . . . . . . . . . . . . . . 9
4.3.1. Case(1): Mode of Operation in PCE Designation . . . . 9
4.3.2. Case(2): Mode of Operation in PCEP Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 10
4.4. An Example of PCE Collaboration . . . . . . . . . . . . . 12
5. PCEP Protocol Extension Requirements . . . . . . . . . . . . . 14
6. VSPG Encoding . . . . . . . . . . . . . . . . . . . . . . . . 15
7. DRPC Procedure Failures . . . . . . . . . . . . . . . . . . . 16
8. Path Computation Failures . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17
10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 17
10.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 18
10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Fu, et al. Expires September 1, 2011 [Page 2]
Internet-Draft DRPC Procedure February 2011
1. Introduction
With regards to the constraint-based shortest path computation in
Multi-protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
multi-layer and multi-domain networks, IETF groups propose the
architecture of Path Computation Element (PCE) [RFC4655]. As an
important approach of path computation in PCE architecture, backward
recursive PCE-based computation (BRPC) procedure can gain a shortest
path tree along the direction from the destination node to the source
node, and then get an end-to-end shortest path [RFC5441]. During the
procedure of BRPC, a PCE sequence should be pre-determined. However,
when there is a large number of PCEs in the predetermined PCE
sequence, the path computation time may be long for the customer, and
the long PCE chain is more vulnerable. A dual-end recursive PCE-
based computation (DRPC) procedure is proposed to compute shortest
constrained inter-domain traffic engineering label switched paths.
DRPC procedure aims to provide a further improvement of the existing
BRPC procedure by computing and transferring the shortest path tree
bi-directionally, which doubles the pace of inter-domain path
computation.In DRPC procedure, Path computation is launched at the
source PCE and the destination PCE simultaneously. By recursively
performing shortest path algorithm and transferring the segmental
path computation result from both ends bi-directionally, they meet at
one of the Middle PCEs, generating a directional shortest path graph
into which the two shortest path trees are stitched together.
Therefore, the end-to-end constrained inter-domain traffic
engineering label switched path, even the k shortest paths can be
gained from the directional shortest path graph directly. Only the
differences from RFC5441 are listed here, the overlapped comments all
inherit the corresponding terms in RFC5441, such as section 7, 8, 10,
11, 13, 14, 16, and so on.
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. Terminologies
ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Routers. Routers used to connect
together ASes of the same or different Service Providers via one or
more Inter-AS links.
Fu, et al. Expires September 1, 2011 [Page 3]
Internet-Draft DRPC Procedure February 2011
Boundary Node (BN): a boundary node is either an ABR in the context
of inter-area Traffic Engineering or an ASBR in the context of
inter-AS Traffic Engineering.
Entry BN of domain (n): a BN connecting domain (n-1) to domain (n)
along a determined sequence of domains.
Exit BN of domain (n): a BN connecting domain (n) to domain (n+1)
along a determined sequence of domains.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary. Inter-area TE
LSP: A TE LSP that crosses an IGP area boundary.
LSR: Label Switching Router.
LSP: Label Switched Path.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element.
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.
PCE(i): a PCE with the scope of domain (i).
TED: Traffic Engineering Database.
VSPT: Virtual Shortest Path Tree.
VSPG: Virtual Shortest Path Graph.
Source PCE: the PCE in the source domain to launch the DRPC procedure
and transfer the calculated VSPT forward.
Destination PCE: the PCE in the destination domain to launch the DRPC
procedure and transfer the calculated VSPT backward.
Middle PCE: a PCE in the PCE sequence which is a relative concept -
along the direction from the Destination PCE to the Source PCE or
from the Source PCE to the Destination PCE relatively.
Stitching PCE: a PCE which is determined to stitch the two VSPTs from
both source and destination sides of PCEs into a VSPG.
Downstream: In forward direction, from Source PCE to Destination PCE.
Upstream: In backward direction, from Destination PCE to Source PCE.
Fu, et al. Expires September 1, 2011 [Page 4]
Internet-Draft DRPC Procedure February 2011
3. General Assumptions
In the rest of this document, we make the following set of
assumptions common to inter-area and inter-AS MPLS TE, which are same
to the assumptions of [RFC 5441].
o Each IGP area or Autonomous System (AS) is assumed to be Traffic
Engineering enabled.
o No topology or resource information is distributed between domains
(as mandated per RFC4105 and RFC4216), which is critical to
preserve IGP/BGP scalability and confidentiality.
o while certain constraints like bandwidth can be used across
different domains, other TE constraints like resource affinity,
color, metric, etc. as listed in RFC2702 could be translated at
domain boundaries. If required, it is assumed that, at the domain
boundary nodes, there will exist some sort of local mapping based
on policy agreement, in order to translate such constraints across
domain boundaries during the inter-PCE communication process.
o Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a
single AS made of multiple IGP areas, multiple ASes made of a
single IGP area or any combination of the above. For the sake of
simplicity, each AS will be considered to be made of a single area
in this document. The case of an Inter-AS TE LSP spanning
multiple ASes where some of those ASes are themselves made of
multiple IGP areas can be easily derived from this case by
applying the DRPC procedure described in this document,
recursively.
o The domain path (set of domains traversed to reach the destination
domain) is either administratively pre-determined or discovered by
some means that is outside of the scope of this document.
4. DRPC Procedure
4.1. PCE Sequence Selection Approaches
PCE sequence has to be predetermined before DRPC procedure is
launched, which corresponds to domain path selection. The PCE/domain
path may be either administratively predetermined or discovered by
some means outside of the scope of this document.
A hierarchical PCE architecture is highly recommended which is
proposed in [I-D.ietf-pce-hierarchy-fwk]. In the hierarchical PCE
Fu, et al. Expires September 1, 2011 [Page 5]
Internet-Draft DRPC Procedure February 2011
architecture, a Parent (hierarchical) PCE maintains a domain topology
map. The domain topology map contains the domains and their
interconnections, but has no information about the contents of the
domains.
Each domain has a PCE responsible for computing paths across it.
These PCEs are known as Child PCEs and have a relationship with the
Parent PCE. Each Child PCE also knows the identity of the border
nodes and links of its adjacent domains
The Parent PCE learns from configuration or from each Child PCE how
the domains are interconnected including the traffic engineering (TE)
capabilities of domain interconnections, but does not know the
contents of the domains.
When the ingress PCE receives a path computation request from the
source node, and the destination is outside of the ingress domain,
the ingress PCE will send a path computation request(PCReq Message)
to the parent PCE. The parent PCE computes a domain path based on
the current domain topology and returns a path computation
result(PCRep Message) to the ingress PCE within the selected
candidate PCE sequence.
The communication with Parent PCE is unnecessary within the context
of non-hierarchical PCE architecture and PCE/domain path can be
obtained by other means.
4.2. DRPC Procedure
Definition of VSPG(i), VSPT(0,i) and VSPT(1,i):
VSPG(i) consists of multi shortest paths from the same node to other
multi nodes.
In each domain i,
o 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).
The definition of VSPT(1,i) is the same as that of VSPT(i) in BRPC
(see [RFC5441]).
VSPT(1,i): MP2P (multipoint-to-point) tree returned by PCE(i) to
PCE(i-1):
Fu, et al. Expires September 1, 2011 [Page 6]
Internet-Draft DRPC Procedure February 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 is no larger than [X-en(i)]
Figure 1: VSPT(1,i) Backward Shortest Path MP2P Tree
Each link of tree VSPT(1,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).
The definition of VSPT(0,i) is vary similar to that of VSPT(1,i).
VSPT(0,i): P2MP (point-to-multipoint) tree returned by PCE(i) to
PCE(i+1):
Root (TE LSP source)
/ | \
/ | \
/ | \
BN-en(1,i+1) BN-en(2,i+1) ... BN-en(j,i+1).
where [X-en(i)] is the number of entry BNs in
domain (i), and j is no larger than [X-en(i)]
Figure 2: VSPT(0,i) Forward Shortest Path P2MP Tree
Each link of tree VSPT(0,i) represents the shortest constrained path
between BN-en(j,i+1) and the TE LSP source that satisfies the set of
required constraints for the TE LSP (bandwidth, affinities, etc.).
These are path segments to reach BN-en(j,i+1) from the TE LSP source.
Different from BRPC, when there is a path computation request
arriving and the PCE sequence which will take part in the path
computation has been fixed, DRPC will launch the path computation
from dual-end PCEs to the Middle PCEs bi-directionally. It is worth
noting that the Middle PCE may not be the PCE in the middle of the
PCE sequence but the PCE receiving the two path computation requests
from two directons. According to the path computation request, the
Fu, et al. Expires September 1, 2011 [Page 7]
Internet-Draft DRPC Procedure February 2011
source PCE sparks the path computaion to the Entry BN of the
stitching domain. while, the destination PCE sparks the path
computation to the the Entry BN of the domain next to the stitching
domain. When the stitching PCE receives the two messages which
contain the two virtual shortest path trees (VSPT) at the root of the
source node and the destination node respectively, the stitching PCE
will stitch the two VSPTs into one complete directional shortest path
graph. At last, the shortest path or k shortest paths will be
selected from the directional shortest path graph by the stitching
PCE according to some strategies and transferred to the source node
through the Source PCE. Similar with BRPC, a pre-determined PCE
sequence should also be designated before DRPC.
PCE(i+1) computes VSPT(1,i+1) by using its own topology map without
considerating any cross-domain links. VSPT(1,i+1) is returned by
PCE(i+1) to PCE(i) along the direction from the Destination PCE to
the Source PCE, which consists of multi shortest paths from the multi
BN-en(j,i+1)s to the destination node, as is shown in Fig.1.
PCE(i-1) computes VSPT(0,i-1) by using its own topology map together
with the cross-domain links between domain(i-1) and domain(i).
VSPT(0, i-1) is returned by PCE(i-1) to PCE (i) along the direction
from the Source PCE to the Destination PCE, which consists of multi
shortest paths from the source node to multi BN-en(j,i), as is shown
in Fig.2.
VSPG(i)=VSPT(0,i)+VSPT(1,i+1) is the directional shortest path graph
from the source node to the destination node stitched by the two
directional shortest path tree gained above. As the Stitching PCE,
PCE(i) computes VSPT(0,i) and then stitches the two directional
shortest path graphs together where VSPT(0,i) represents the
directional shortest path tree computed from source node to the Entry
BN of domain(i+1) and VSPT(1,i+1) represents the directional shortest
path graph computed from destination node to the Entry BN of
domain(i+1). At last, the directional shortest path graph from the
source node to the destination node is generated as shown in Fig.3.
Root (TE LSP source)
/ | \
/ | \
BN-en(1,i+1) BN-en(2,i+1) ... BN-en(j,i+1).
\ | /
\ | /
Root (TE LSP destination)
Figure 3: VSPG(i) Shortest Path Graph
Fu, et al. Expires September 1, 2011 [Page 8]
Internet-Draft DRPC Procedure February 2011
The Stitching PCE can either be designated by some means before DRPC
procedure, or by dynamic selection in PCEP signaling procedure
automatically.
Two path selection strategies are permitted to return the shortest
path back to PCC.
o The Stitching PCE transfers the computed shortest path to the
Source PCE through PCReq message and the Source PCE returns it
back to PCC. The non-shortest paths are deleted at the Stitching
PCE.
o The Stitching PCE transfers the newly stitched directional
shortest path graph to the Source PCE through PCRep message.
Source PCE generates the shortest path and returns it back to PCC.
The non-shortest paths are deleted at the Source PCE.
4.3. Stitching PCE Selection
The Stitching PCE is an ordinary PCE. It acts the role of stitching
the two VSPTs from both source and destination sides of PCEs into a
VSPG. The Stitching PCE can be fixed by several means before DRPC
procedure, such as Parent PCE computation, Network Management
System(NMS), administrative configuration and etc. These can be
regarded as Designation Case and Section 4.3.1 describes the DRPC
operation in this case. By utilizing the characteristics of the PCEP
signaling, the stitching role can be dynamically determined. Section
4.3.2 elaborates the details of PCEP signaling procedure in Stitching
PCE Selection.
4.3.1. Case(1): Mode of Operation in PCE Designation
Denote that PCE(1) is the Source PCE, PCE(m) the Stitching PCE, and
PCE(n) the Destination PCE.
Step 1:
PCE(1) computes VSPT(0,1), the tree made of the list of shortest
constrained paths between the TE LSP source and every BN-en(j,2) by
using a suitable path computation algorithm (e.g., CSPF) and returns
the computed VSPT(0,1) to PCE(2). This can be triggered by Parent
PCE, PCC or spontaneously.
Simultaneously, PCE(n) computes VSPT(1,n), the tree made of the list
of shortest constrained paths between every BN-en(j,n) and the TE LSP
destination using a suitable path computation algorithm (e.g., CSPF)
and returns the computed VSPT(n) to PCE(n-1). This can be triggered
by Parent PCE, PCE(n-1) or PCE(1) directly. It is highly recommended
Fu, et al. Expires September 1, 2011 [Page 9]
Internet-Draft DRPC Procedure February 2011
to drive PCE(n) to compute VSPT(1,n) by PCE chain and to relay PCReq
message PCE-by-PCE downstream from PCE(1). An example of specific
PCEP message flow is shown in section 4.4.
Step i: (Downstream)
For i=2 to m-1: PCE(i) computes VSPT(0,i), the tree made of the
shortest constrained paths between the TE LSP source and each BN-
en(j,i+1). It does this by considering the information in
VSPT(0,i-1) and its own TED including the links that provide
connectivity from domain(i) to domain(i+1). PCE(i) returns the
computed VSPT(0,i) to PCE(i+1).
Step i: (Upstream)
For i=n-1 to m+1: PCE(i) computes VSPT(1,i), the tree made of the
shortest constrained paths between each BN-en(j,i) and the TE LSP
destination. It does this by considering the information in
VSPT(1,i+1) and its own TED. PCE(i) returns the computed VSPT(1,i)
to PCE(i-1).
Step m:
PCE(m) computes VSPT(0,m), the tree made of the shortest constrained
paths between the TE LSP source and each BN-en(j,m+1). It does this
by considering the information in VSPT(0,m-1) and its own TED
including the links that provide connectivity from domain(m) to
domain(m+1). PCE(m) stitches the computed VSPT(0,m) and VSPT(1,m+1)
which is returned from PCE(m+1) into a VSPG.
If n=2, the source domain and the destination domain are directly
interconnected each other. The Stitching PCE is recommended to be
specified as the Source PCE where step i is omitted.
The PCRep message which carries VSPG(m) or final ERO should be
relayed from PCE(m) to PCE(1) upstream PCE-by-PCE. PCE(1) returns
the final path computation result to PCC. The shortest path can be
selected from VSPG(m) either by PCE(m) or PCE(1). For the sake of
topology confidentialality, PCE(m) is recommended to select the final
explicit route rather than PCE(1).
4.3.2. Case(2): Mode of Operation in PCEP Signaling Procedure
Denote that PCE(1) is the Source PCE and PCE(n) the Destination PCE.
In this case, every PCE transfers VSPT to the next PCE without
knowing a pre-defined Stitching PCE. So, the Stitching PCE is
selected automatically in PCEP signaling procedure where VSPT request
messages upstream and downstream meet each other and there are three
Fu, et al. Expires September 1, 2011 [Page 10]
Internet-Draft DRPC Procedure February 2011
scenarios.
Scenario (1): PCE(i) and PCE(i+1) receive messages request for
VSPT(1,i+1) and VSPT(0,i) respectively after these two messages have
been sent. Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into
VSPG(i), whereas PCE(i+1) discards the message.
Scenario (2): PCE(i) receives a message carrying VSPT(1,i+1) after it
has received a message carrying VSPT(0,i), and it is unable to stop
sending PCReq with computed VSPT(0,i) to PCE(i+1) immediately or the
message has already been sent. Thus, PCE(i) stitches VSPT(0,i) and
VSPT(1,i+1) into VSPG(i), whereas PCE(i+1) discards VSPT(0,i).
Scenario (3): PCE(i+1) receives a message carrying VSPT(0,i) after it
has received a message carrying VSPT(1,i+2), and it is unable to stop
sending message carrying a computed VSPT(1,i+1) to PCE(i)
immediately. Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into
VSPG(i), whereas PCE(i+1) discards VSPT(0,i).
The following steps are described as follows to deal with these three
situations in a uniform procedure. Denote that PCE(m) is the
intersection of the two VSPTs. It represents the Stitching PCE.
Step 1:
PCE(1) computes VSPT(0,1), the tree made of the list of shortest
constrained paths between the TE LSP source and every BN-en(j,2) by
using a suitable path computation algorithm (e.g., CSPF) and returns
the computed VSPT(0,1) to PCE(2). This can be triggered by Parent
PCE, PCC or spontaneously.
Simultaneously, PCE(n) computes VSPT(1,n), the tree made of the list
of shortest constrained paths between every BN-en(j,n) and the TE LSP
destination using a suitable path computation algorithm (e.g., CSPF)
and returns the computed VSPT(n) to PCE(n-1). This can be triggered
by Parent PCE, PCE(n-1) or PCE(1) directly. It is highly recommended
to drive PCE(n) to compute VSPT(1,n) by PCE chain and to relay PCReq
message PCE-by-PCE downstream from PCE(1). This step is identical
with that of Case (1).
Step i: (Downstream)
For i=2 to m: PCE(i) computes VSPT(0,i), the tree made of the
shortest constrained paths between the TE LSP source and each BN-
en(j,i+1). It does this by considering the information in
VSPT(0,i-1) and its own TED including the links that provide
connectivity from domain(i) to domain(i+1). If PCE(i) has already
received a valid message request for VSPT(0,i) from PCE(i+1) which
Fu, et al. Expires September 1, 2011 [Page 11]
Internet-Draft DRPC Procedure February 2011
carries VSPT(1,i+1), it ignores the message once received from
PCE(i-1) downstream. Otherwise PCE(i) returns the computed VSPT(0,i)
to PCE(i+1).
Step i: (Upstream)
For i=n to m+1: PCE(i) computes VSPT(1,i), the tree made of the
shortest constrained paths between each BN-en(j,i) and the TE LSP
destination. It does this by considering the information in
VSPT(1,i+1) and its own TED. PCE(i) returns the computed VSPT(1,i)
to PCE(i-1). If PCE(i) has already received a valid message request
for VSPT(1,i-1) from PCE(i-1) which carries VSPT(0,i-1), it computes
VSPT(0,i+1) and transfers the VSPT(0,i) to PCE(i+1). Once a valid
message carrying VSPT(1, i+1) received from PCE(i+1) after receiving
VSPT(0, i-1) from PCE(i-1), PCE(i) stitches these two VSPTs into a
VSPG(i).
Both PCReq and PCRep message are permitted to trigger VSPT
computation. It is recommended to use PCRep message to trigger the
VSPT computation on the Middle PCE, and PCReq on the Source and
Destination PCE. VSPT(0, i), VSPT(1, i) and VSPG(i) MUST be encoded
in ERO, IRO, RRO, or XRO Objects (see [RFC5440] and [RFC5521]).
The PCRep message which carries VSPG(m) or final ERO should be
relayed from PCE(m) to PCE(1) upstream PCE-by-PCE. PCE(1) returns
the final path computation result to PCC. The shortest path can be
selected from VSPG(m) either by PCE(m) or PCE(1). These are
identical with case (1).
4.4. An Example of PCE Collaboration
The following example will be used for demonstrating PCE
collaboration of DRPC procedure in this document. It uses the
recommended PCEP message flow.
Notes:
- Just three domains are depicted in the diagram below for the
sake of simplicity.
- We assume that the Stitching PCE is in the middle of the PCE
sequence, which may be determined by either of the two cases
described in Section 4.3.
Fu, et al. Expires September 1, 2011 [Page 12]
Internet-Draft DRPC Procedure February 2011
(1.1)PCReq ------------
+----------------->| Parent PCE |
| (1.2)PCRep ------------
|
-----+------ ------------ ------------
| | | | Domain 2 | | Domain 3 |
| v | | (Stitcher) | | |
| ------ | (2a)PCReq | ------ | (3a)PCReq | ------ |
| | PCE1 |<-+-----------+->| PCE2 |<-+-----------+->| PCE3 | |
| ------ | (2b)PCRep | ------ | (3b)PCRep | ------ |
| ^ | (4)PCRep | | | |
| (1)|PCReq | ------------ ------------
| (5)|PCRep |
| v |
| ----- |
| | PCC | |
| ----- |
| Domain 1 |
| |
------------
Figure 4: An Example of DRPC Procedure
Workflows:
(1) PCC sends a PCReq message to the Source PCE, requesting an
end-to-end explicit route.
(1.1) Source PCE sends a PCReq message to Parent PCE, requesting a
PCE Sequence.
(1.2) Parent PCE sends a PCReq message to Source PCE, replying the
PCE Sequence.
(2a) Once PCE(1) obtained the PCE Sequence by (1b) or some other
means, it sends a PCReq message to PCE(2), asking for PCE(2) to
relay this message to the Destination PCE. It expects the
Destination PCE to compute VSPT(1, 3).
(2b) Once PCE(1) obtained the PCE Sequence by (1b) or some other
means, it computes VSPT(0, 1) and encapsulate this VSPT into a
PCRep message. Then it sends this PCRep message to PCE(2) to
launch a VSPT(0, 2) computation.
Fu, et al. Expires September 1, 2011 [Page 13]
Internet-Draft DRPC Procedure February 2011
(3a) Having received a PCReq message from PCE(1), PCE(2) sends a
PCReq message to PCE(3), asking for PCE(3) to relay this message
to the Destination PCE.
(3b) Having received a PCReq message from PCE(2) and checked that
the Destination PCE is itself, PCE(3) computes VSPT(1, 3) and
encapsulate this VSPT into a PCRep message. Then it sends this
PCRep message to PCE(2) to launch a VSPT(1, 2) computation.
(4) The Stiching PCE stitches VSPT(0, 2) and VSPT(1, 2) into a
VSPG(2). It may either select a shortest path from this VSPG and
encapsulate it into a PCRep message or it may encapsulate the VSPG
into a PCRep message. No matter which strategy is chosen, it
sends back the PCRep message to PCE(1), the neighbor PCE along the
upstream direction, expecting that PCE to relay this PCReq message
to the Source PCE.
(5) Having received a PCRep message from PCE(2) and checked that
the Source PCE is itself, PCE(1) returns the final ERO to PCC by
sending a PCRep message. If the received PCRep message contains a
VSPG, PCE(1) selects the shortest path from the VSPG, or else
PCE(1) relays the received PCRep message to PCC directly.
If the parent PCE which maintains a domain topology map of the child
domains and their interconnectivity does not exist, the PCE sequence
can be fixed by other means such as administrative configuration,
Network Management System(NMS), non-shortest path computation without
regard to detailed TE attributes, and etc. This way, the (1.1) and
(1.2) steps are skipped.
5. PCEP Protocol Extension Requirements
The two different DRPC procedures require the specification of new
flags of the RP object carried within the PCReq message to specify
that the shortest paths satisfying the constraints from the
destination to the set of entry boundary nodes or from the source to
the set of entry boundary nodes are requested.
Note that IANA has already defined Bit 25 of the flags in RP Object
for VSPT.
The following new flags of the RP object is defined:
Fu, et al. Expires September 1, 2011 [Page 14]
Internet-Draft DRPC Procedure February 2011
Bit Number Name Flag
16 VSPG
When Bit 16 is set, it enables VSPG encoding in ERO, IRO, RRO, or XRO
Object. In PCReq message, when Bit 16 is set, it indicates that the
Source PCE is response for path selection from VSPG rather than the
Stitching PCE, which is defined in this document. Bit 16 is valid
under the assumption that bit 17 is valid.
Bit Number Name Flag
17 DRPC VSPT Extension
In PCReq Message:
17 1: Request for DRPC Procedure
In PCRep Message:
17 0: from source PCE to Middle PCE for VSPT Extension
1: from destination PCE to Middle PCE for VSPT
Extension
In PCReq message, when Bit 17 is set, it indicates that the PCC
requests the computation of an inter-domain TE LSP using the DRPC
procedure defined in this document. In PCRep message Bit 17 is valid
under the assumption that bit 25 is valid.
Because path segments computed by the two end PCEs in the context of
the DRPC procedure must be provided along with their respective path
costs, the C flag of the METRIC object carried within the PCReq
message must be set. It is the choice of the requester to
appropriately set the O bit of the RP object.
6. VSPG Encoding
The VSPG is returned within a PCRep message. The encoding consists
of a non-ordered list of Explicit Route Objects (EROs) where each ERO
represents a path from the source to the destination specified in the
END-POINT object of the corresponding PCReq message from PCC to
Source PCE.
Example:
Fu, et al. Expires September 1, 2011 [Page 15]
Internet-Draft DRPC Procedure February 2011
<---- area 1 -----><-------- area 2 ---------><----- area 3 ------>
+--A--B---BNex1-1--BNen2-1---E---F---BNex2-1--BNen3-1---K----L--+
| |
| |
S----C----BNex1-2--BNen2-2---G---H---BNex2-2--BNen3-2-----M-----D
| |
| |
+---J---BNex2-3--BNen3-3---N----P--+
| |
| |
+------BNen3-4---Q----+
Figure 5: An Example of VSPG Encoding Using a Set of EROs
In the simple example shown in Figure 5, along the direction from the
source node to the destination node, when the Stitching PCE completes
the path computation and the Source PCE expects a VSPG to select the
optimal path in it, four non-ordered EROs are transferred to PCE(1).
The four EROs are as follows:
ERO[1]: S---A---B---BN-ex(1,1)---BN-en(2,1)---E---F---BN-ex(2,1)---
BN-en(3,1)---K---L---D
ERO[2]: S---C---BN-ex(1,2)---BN-en(2,2)---G---H---BN-ex(2,2)---BN-
en(3,2)---M---D
ERO[3]: S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN-
en(3,3)---N---P---D
ERO[4]: S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN-
en(3,4)---Q---P---D
Note that the (BN-ex, BN-en) pair can be either a pair of interfaces
on a single ABR or two detached TE-Routers in different domains. In
both cases they should be encoded to ERO sub-object specified in
RFC3209.
7. DRPC Procedure Failures
If the DRPC procedure cannot be completed because a PCE along the
domain does not recognize the procedure (VSPG flag of the RP object),
the PCE sends a PCErr message to the parent PCE with an Error-Type=4
(not supported object), Error-value-4 (Unsupported parameter). Then
the parent PCE sends the failure message to the other PCEs along the
PCE chain. The corresponding path computation request is then
cancelled by the PCE without further notification. The PCErr message
Fu, et al. Expires September 1, 2011 [Page 16]
Internet-Draft DRPC Procedure February 2011
must be relayed to the requesting PCC by the source PCE.
PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type which 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 and the corresponding error value are defined here.
Error-type Meaning
14 DRPC procedure completion failure
Error-value Meaning
1 DRPC procedure not supported by one or more PCEs
along the domain path
8. Path Computation Failures
If a PCE requires to relay a path computation request according to
the DRPC procedure defined in this document to a downstream PCE and
no such PCE is available, the PCE MUST cancel all the procedures of
path computation on all the other PCEs along the PCE chain through
the Source PCE, and send a path computation reply to the PCC using a
PCRep message that contains a NO-PATH object. In such case, the NO-
PATH object MUST carry a NO-PATH-VECTOR TLV with the newly defined
bit named "DRPC Path Computation chain unavailable" set.
Different from BRPC using bit 28, Bit 23 is defined here.
Bit Number Name Flag
23 DRPC Path computation chain unavailable
9. Security Considerations
TBD.
10. IANA Consideration
10.1. New Flags Of The RP Object
New flags Of The RP Object is defined in this document (VSPG and
VSPT-DRPC-Extension to be assigned by IANA).
Fu, et al. Expires September 1, 2011 [Page 17]
Internet-Draft DRPC Procedure February 2011
Bit Number Name Flag
16 VSPG
17 DRPC VSPT Extension
In PCReq Message:
17 1: Request for DRPC Procedure
In PCRep Message:
17 0: from source PCE to Middle PCE for VSPT Extension
1: from destination PCE to Middle PCE for VSPT
Extension
Bit 16 is valid under the assumption that bit 17 is valid.
Bit 17 is valid under the assumption that bit 25 is valid in PCRep
message.
10.2. New Error-Type and Error-Value
A new Error-Type is defined in this document (Error-Type and Error-
value to be assigned by IANA).
Error-type Meaning
14 DRPC procedure completion failure
Error-value Meaning
1 DRPC procedure not supported by one or more PCEs
along the domain path
10.3. New Flag Of The NO-PATH-VECTOR TLV
A new flag of the NO-PATH-VECTOR TLV defined in is specified in this
document.(Bit 23 to be assigned by IANA)
Bit number Name Flag
23 DRPC Path computation chain unavailable
Fu, et al. Expires September 1, 2011 [Page 18]
Internet-Draft DRPC Procedure February 2011
11. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
12. Normative References
[I-D.ietf-pce-hierarchy-fwk]
King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS & GMPLS", December 2009.
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5441] Vasseur, J., Zhang, R., Bitar, N., and JL. Le Roux, "A
Path Computation Element (PCE)-Based Architecture",
RFC 5441, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
Authors' Addresses
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi'an 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://www.zte.com.cn/
Fu, et al. Expires September 1, 2011 [Page 19]
Internet-Draft DRPC Procedure February 2011
Yuanlin Bao
ZTE Corporation
5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road
Nanshan District
Shen Zhen 518055
P.R.China
Phone: +86 755 26773731
Email: bao.yuanlin@zte.com.cn
URI: http://www.zte.com.cn/
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613911060930
Email: lgr24@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Yuan Gu
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613466734941
Email: josephstrauss@yahoo.com.cn
URI: http://www.bupt.edu.cn/
Fu, et al. Expires September 1, 2011 [Page 20]