Internet DRAFT - draft-li-pce-hierarchical-pce-p2mp-path
draft-li-pce-hierarchical-pce-p2mp-path
Internet Engineering Task Force K. Li
Internet-Draft X. Tu
Intended status: Standards Track Z. Fu
Expires: July 3, 2012 ZTE Corporation
December 31, 2011
Hierachical PCE Extensions for Inter-Domain Point-to-Multipoint Path
Computation
draft-li-pce-hierarchical-pce-p2mp-path-00
Abstract
The hierachical Path Computation Element (PCE) architecture defined
in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be
selected, and the optimum end-to-end path to be derived through the
use of a hierarchical relationship between domains.
This document defines the hierachical PCE (H-PCE) extensions for the
purpose of implementing inter-domain P2MP 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 July 3, 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
Li, et al. Expires July 3, 2012 [Page 1]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Li, et al. Expires July 3, 2012 [Page 2]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architectural Protocol Overview . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Child PCE Responsibility . . . . . . . . . . . . . . . . . 7
3.3. Parent PCE Responsibility . . . . . . . . . . . . . . . . 7
3.4. Multi-layer H-PCE . . . . . . . . . . . . . . . . . . . . 8
3.5. Inter-domain TE Link . . . . . . . . . . . . . . . . . . . 9
4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 10
4.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 11
4.3. PCNtf Message . . . . . . . . . . . . . . . . . . . . . . 12
4.4. PCErr Message . . . . . . . . . . . . . . . . . . . . . . 13
5. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Inter-domain Capability Advertisement . . . . . . . . . . 15
5.2. Preserving Topology Confidentiality . . . . . . . . . . . 15
5.3. Extensions to END-POINTS Object . . . . . . . . . . . . . 15
5.4. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 17
5.5. Extensions to Unreach-Destination Object . . . . . . . . . 17
5.6. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 20
6.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Li, et al. Expires July 3, 2012 [Page 3]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
1. Introduction
[RFC4655] describes the motivations and architecture for a Path
Computation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs).
[PCE-HIERARCHY-FWK] defined a hierachical Path Computation Element
(H-PCE) architecture allows the optimum sequence of domains to be
selected, and the optimum end-to-end inter-domain path to be derived
through the use of a hierarchical relationship between domains.
This document specifies the inter-domain P2MP path computation
methods. Inter-domain P2MP is comprised of multiple source-to-leaf
sub-LSPs. These S2L sub-LSPS are set up between the ingress and
egress LSRs, and may located in different domain or autonomous
system.
Li, et al. Expires July 3, 2012 [Page 4]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
2. Terminology
AS: Autonomous System, A collection of connected routing prefixes
under the control of one or more network operators that presents a
common, clearly defined routing policy to the Internet.
ASBR: Autonomous System Border Router. Routers used to connect
together ASes of the same or different service providers via one or
more inter-AS links.
BN: Boundary Node, 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.
Child PCE: A PCE responsible for computing the path across one or
more specific (child) domains. A child PCE maintains a relationship
with at least one parent PCE.
Parent PCE: A PCE responsible for selecting a path across a parent
domain and any number of child domains by coordinating with child
PCEs and examining a topology map that shows domain inter-
connectivity.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity that is capable of
computing a network path or route based on a network graph and
applying computational constraints.
H-PCE: Hierarchical PCE. A parent PCE maintains a domain topology
map that contains the child domains and their interconnections (links
in the topology).
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a
path.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a
path.
Li, et al. Expires July 3, 2012 [Page 5]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
3. Architectural Protocol Overview
3.1. Overview
This docment provids a method which uses H-PCE to compute an optimal
P2MP path. The parent PCE floods path computation requests from the
ingress domain which contains the ingress node to adjacent domains,
child PCE which serves the domain receives the path computation
requests, finishes the computation and replys the results to the
parent PCE. After computation of all domains, the parent PCE
completes the path computation of the whole P2MP tree. Procedure is
as follows:
1. PCC sends P2MP path computation request to child PCE. The
request message must contain information of leaf nodes, type and
other attributes of the P2MP tree.
2. Child PCE find that the message is a inter-domain P2MP path
computation request, and transmits it to its parent PCE.
3. The parent PCE treats the ingress domain which contains the
ingress node of the inter-domain P2MP tree as currently
processing domain, and treats the ingress node as root node, the
BNs of this domain and leaf nodes in this domain as leaf nodes,
then the parent PCE sents a path computation request to a child
PCE which serves the domain.
4. The child PCE which receives the path computation request from
the parent PCE will select a optimal path computation request to
compute path to every leaf nodes and finally reply optimized
computation results to the parent PCE.
5. The parent PCE receives path segments computation results,
combines these results into a P2MP path tree, this P2MP tree's
root is ingress node and leaf nodes are BNs of the domain and
leaf nodes of this trees that have been computed. Then the
parent PCE decides next domains need to be flooded and sends path
computation requests to them.
6. The corresponding child PCEs that receive the path computation
requests from the parent PCE process as step 4.
7. If the path segments computation results is null, or if there
isn't any next domain need to be flooded, then current path
computation is completed, the parent PCE should repond the
completed inter-domain P2MP path to its child PCE. Otherwise,
the parent PCE should send path computation requests to child
PCEs in next domains, just as process in step 5.
Li, et al. Expires July 3, 2012 [Page 6]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
8. Child PCEs reply the ultimately path computation result to PCC.
3.2. Child PCE Responsibility
Each child PCE is responsible for one domain, computing path segment
in the domain and replying computation result to its parent PCE.
Child PCE's main work is detailed as follows.
Child PCE should receive path computation request which is sent by
PCC, and decide the path computation request, if the path is inter-
domain type, then child PCE should transmit the path computation
request to its parent PCE. Child PCE then receive path segment
computation request, according to content of the request message,
compute path segment in the domain, and reply optimal result to its
parent PCE. Child PCE should receive path computation result from
its parent PCE, and transmit it to PCC.
In the actual network application scenario, the connection among
domains may be very complex, especially when the connection among
domains is full mesh. So child PCE may receive more than one path
computation requests. When child PCE receives more than one
requests, it should process those requests according to following
rules.
If child PCE receives more than one path computation requests for a
number of different root nodes in the same flooding process, the
child PCE should compute path for each request, then decide all the
computation results and give an optimal sub-S2L LSP for each leaf
node, reply those results to its parent PCE. If child PCE receives
more than one path computation requests for a number of different
root nodes in different flooding processes, the child PCE only need
to process latest request and reply computation result to its parent
PCE. If child PCE receives more than one path computation requests
for the same root node in the same flooding process, the child PCE
only need to process the request which has the smallest cost to root
node, and reply computation result to its parent PCE. If child PCE
receives more than one path computation requests for the same root
node in different flooding processes, the child PCE should decide
cost to root node in the later received path computation request is
smaller; if yes, the child PCE should re-compute path to each leaf
node and reply computation result to its parent PCE.
3.3. Parent PCE Responsibility
Parent PCE is mainly responsible for flooding path computation
requests to neighbor domains, summarizing path computation results
from its child PCEs, and deciding the whole computation process.
First, parent PCE receives inter-domain path computation request
Li, et al. Expires July 3, 2012 [Page 7]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
which is sent by its child PCE, finds the domain that has ingress
node of the P2MP tree that to be computed, finds ingress nodes(BNs)
and leaf nodes of this domain, then sends path segment computation
request to this child PCE. After sending the computation request,
parent PCE should wait for computation result from child PCE, and
decide next neighbor domains that should be flooded, find ingress
nodes and leaf nodes of those domains, send path segment computation
requests to them.
If parent PCE decides the path computation is complete, it should end
the computation process and send result to the child PCE which
request inter-domain path computation.
In complex scenario, parent PCE maybe receive different computation
results from the same child PCE, then parent PCE should process those
results according to following rules.
For each BN, parent PCE should decide if the cost to the BN in the
later received computation result is better than cost value exists in
parent PCE; if so, parent PCE should flood the BN's neighgor domains
in next flooding process; otherwise, parent PCE should desert the
later received computation result without any further process. In
each flooding process to next domains, parent PCE should first
estimate the entry BN of next domains haven't been flooded; if so,
parent PCE continue to send computation requests to next domains;
otherwise, parent PCE shouldn't send any request to next domains, and
parent PCE only need to update corresponed cost values in parent PCE.
After that, parent PCE should decide again that if is there need to
send computation requests to the next domain's next domains.
If every possible path of each domains has been computed, or if there
isn't better result given by child PCE, parent CPE can decide the
path computation is complete.
3.4. Multi-layer H-PCE
H-PCE may have more than two layers in actual scenario, it could nest
more layers, neighbor layers are parent and child, such as Figure 1.
Li, et al. Expires July 3, 2012 [Page 8]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
+----+
--|PCE3|
/ +----+
+----+ /
-- |PCE2|--
/ +----+
+----+ /
-- |PCE1|--
/ +----+
+---+ /
|PCC|--
+---+
Figure 1: Multi-Layer H-PCE Example
In Figure 1, there are three layers. For one PCE layer, it treats
its up PCE as parent PCE and treats its down layer as PCC. it only
has communication with its up layer. For PCE1 in Figure 1, PCE2 is
parent PCE, when PCE1 receives path computation request from PCC, it
will transmit the request to parent PCE(i.e. PCE2). For PCE2 in
Figure 1, it treats PCE1 as PCC, and treats PCE3 as parent PCE, when
it receives path computation request from PCE1, it will transmit the
request to parent PCE(i.e. PCE3).If PCE3 receives path computation
request, it will send intra-domain path computation request to
PCE2(PCE3's child PCE), and PCE2 will break down the request and send
new request to PCE1(PCE2's child PCE). Then, PCE1 will compute path
and reply to PCE2.
3.5. Inter-domain TE Link
BNs of different domains are connected through TE link, such as:
--------- Transit ---------
|Domain1|---------|Domain2|
--------- Link ---------
Figure 2: TE Link Example
When PCE computes path of a P2MP tree, parent PCE should consider
attributes of TE link as constraints.
Li, et al. Expires July 3, 2012 [Page 9]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
4. Messages Format
4.1. PCReq Message
The PCEP Path Computation Request message (PCReq Message) is a PCEP
message sent by a PCC or PCE to request a path computation. A PCReq
message may carry more than one path computation request. As in
inter-domain scene, the overlap of addressing space should be
considered, and it should use the newly defined END-POINTS object as
in section 5.3.
Also, the request message must contain the cost which the ingress
node(or what we called root node of the P2MP path) associated, so
there is a METRIC-LIST object followed each END-POINTS object.
PCReq Message format defined as follows:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
For supporting of PATH-KEY, <request> defined as follows:
<request>::= <RP>
<segment-computation> | <path-key-expansion>
<segment-computation>::= <end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion>::= <PATH-KEY>
where:
<end-point-rro-pair-list>::= <END-POINTS>
<metirc-list>
[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List> ::= <RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list> ::= <METRIC>[<metric-list>]
Li, et al. Expires July 3, 2012 [Page 10]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
Extension to [PCE-HIERARCHY-FWK], PCReq Message can be send by PCC to
child PCE to initialize a inter-domain p2mp path computation, and can
be transfered by child PCE to parent PCE, and parent PCE can also
send PCReq message to child PCE for the inner domain sub path result.
For supporting of preserving topology confidentiality between each
domain, request object is extended to support Path-Key mechanism.
The usage is specified in [RFC5520]
4.2. PCRep Message
The PCEP Path Computation Reply message (PCRep Message) is a PCEP
message in response to a previously received PCReq message. A PCRep
message may contain a set of computed paths corresponding to either a
single path computation request or multiple path computation
requests, each computed path must followed by a METRIC object to
indicate the path's cost.
Because of it should preserving topology information leak into other
domain, when child PCE reply P2MP path segment to parent PCE, the
PATH object should use loose hops, or Path-Key described in [RFC5520]
The PCRep message format defined as follows:
Li, et al. Expires July 3, 2012 [Page 11]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
<PCRep Message>::= <Common Header>
<response-list>
where:
<response-list>::= <response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<end-point-path-pair-list>]
where:
<end-point-path-pair-list>::= [<END-POINTS>]
<path> | <path-key-expansion>
[<end-point-path-pair-list>]
<path>::= (<ERO>|<SERO>)
<metric>
[<path>]
<path-key-expansion> ::= <PATH-KEY>
<metric>
[<path-key-expansion>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Note that we add Metric object after each ERO/SERO and PATH-KEY
object. At least one instance of Metric MUST BE present in each path
or path-key-expansion.
4.3. PCNtf Message
The PCNtf Message is send by a PCC or a PCE to notify of a specific
event. The PCNtf Message MUST carry at least one NOTIFICATION
object.
The format of NOTIFICATION object is as follows:
Li, et al. Expires July 3, 2012 [Page 12]
Internet-Draft H-PCE Extensions for P2MP Path December 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NOTIFICATION Object Body Format
We need to add new notification types in inter-domain scene, which
defined as follows:
Notification-type=3, Notification-value=1: Parent PCE update request
metric to child PCE. It indicates that parent PCE wants to inform a
child PCE that the path computation request before should update the
metric contains in the message. Such an event could be triggered
when the parent PCE request child PCE to computate a P2MP path
segment, but have not return the result yet, parent PCE can use this
NOTIFICATION object to renew the child PCE's metric, when child PCE
reply the last result, it can do the path computation according to
newest metric.
4.4. PCErr Message
The PCErr message is sent by a PCC or a PCE in response to a request
or in an unsolicited manner. A PCErr message MUST contain a PCEP-
ERROR object specifying the PCEP error condition. The PCEP-ERROR
object is defined as follows (defined in [RFC5440]):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PCEP-ERROR Object Body Format
For each PCEP error, an Error-Type and an Error-value are defined.
Li, et al. Expires July 3, 2012 [Page 13]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
We need to add new error type as follows:
When Error-Type=5, Error-value=3, reception of messages where K bit
in RP object is setted, but not supported
When Error-Type=6, Error-value=3, reception of messages with no
metric object
Li, et al. Expires July 3, 2012 [Page 14]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
5. Object Format
5.1. Inter-domain Capability Advertisement
[RFC6006] use the OSPF PCE capability Flags in PCE Discovery TLV to
indicate the capability of P2MP computation. This document will use
the same method, defines a new flag in the OSPF PCE Capability Flags
to indicate the capability of inter-domain P2MP computation.
PCEs wishing to advertise that they support inter-domain path
computation will set this bit, as to inter-domain P2MP ,PCEs would
set this bit and the bit 10 ([RFC6006]) accordingly. PCCs that do
not understand those bit will ignore it. PCEs that do not support
inter-domain will leave the bit clear (per the default behavior
defined in [RFC5088] and [RFC5089]).
5.2. Preserving Topology Confidentiality
A important element of inter-domain is that topology information is
not shared between domains for scalability and confidentiality
reasons. So the cooperating PCEs cann!_t exchange the actual path
segments between each other in PCRep Messages. We can use loose hops
described in [RFC3209]] to satisfy this requirement, or we can use
PATH-KEY described in [RFC6006].
If loose hops are used, the TE LSPs are signaled as normal
([RFC3209]), and when a loose hop is encountered in the explicit
route, it is resolved by performing a secondary path computation to
reach the resource or set of resources identified by the loose hop.
A Path-Key is a token that replaces a path segment in an explicit
route. The Path-Key is encoded as a Path-Key Subobject (PKS)
returned in the PCEP Path Computation Reply message (PCRep)
([RFC5440]). when a PATH-KEY is encountered in the signaling process,
corresponding PCE will return the actural path segment continuing to
set up the LSP, thus avoid the secondary path computation.
After parent PCE computated the finally path and reply PCRep Message,
the ERO and RRO contain in messge will only represented in loose hops
or PATH-KEY format.
5.3. Extensions to END-POINTS Object
P2MP END-POINT object is mainly used in PCReq Messages to specify
path!_s source and destination. When using in inter-domain scene,
there may be overlap in address space, so END-POINT object should
expand to inter-domain mode, the object type should be newly defined.
Li, et al. Expires July 3, 2012 [Page 15]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
END-POINTS Object-Class is 4.
P2MP END-POINTS Object-Type is 3 for IPv4 and 4 for IPv6. And it
should add type code for inter-domain IPV4 and inter-domain IPV6. We
assume that 5 for inter-domain IPV4, and 6 for inter-domain IPV6.
The format of the new inter-domian END-POINTS object body for IPv4
(Object-Type 5) is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source domain |
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain |
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain |
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Inter-domain P2MP END-POINTS Object Body Format for IPv4
The format of the new inter-domian END-POINTS object body for IPv6
(Object-Type 6) is as follows:
Li, et al. Expires July 3, 2012 [Page 16]
Internet-Draft H-PCE Extensions for P2MP Path December 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source domain |
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domian |
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain |
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Inter-domain P2MP END-POINTS Object Body Format for IPv6
5.4. PCEP NO-PATH Indicator
[RFC6006] defined No-Path Object used in PCRep Messages to
communicate the reasons for not being able to find P2MP path, we need
to defined one new bit in the NO-PATH-VECTOR TLV carried in it:
Bit 25GBPo when set, the PCE indicateds that there is a reachability
problem with subset of the inter-domain P2MP destinations.
Optionally, the PCE can specify the destination or list of
destinations that are not reachable using the UNREACH-DESTINATION
object.
5.5. Extensions to Unreach-Destination Object
[RFC6006] defined UNREACH-DESTINATION object to specify the list of
unreachable destinations or has no-better path destinations. This
object can present in PCRep messages, and the Object-Class is 28,
Object-Type for IPV4 is 1, for IPV6 is2.
We need to add Object-Type for inter-domain options, the type added
list below:
Li, et al. Expires July 3, 2012 [Page 17]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
UNREACH-DESTINATION Object-Class is 28.
UNREACH-DESTINATION Object-Type for inter-domain IPv4 is 3.
UNREACH-DESTINATION Object-Type for inter-domain IPv6 is 4.
The format of the UNREACH-DESTIONATION object body for inter-domain
IPV4 is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain |
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain |
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UNREACH-DESTINATION Object Body for IPv4
The format of the UNREACH-DESTINATION object body for inter-domain
IPV6 is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain (4 bytes) |
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination domain (4 bytes) |
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires July 3, 2012 [Page 18]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
Figure 8: UNREACH-DESTINATION Object Body for IPv6
5.6. OPEN Object
When a PCE does not advertise its inter-domain P2MP capability during
discovery, it should be done during the Open Message exchange when
the PCEP session is established. To satisfy this requirement, we
need to extend the PCEP OPEN object by add a new optional TLV to
indicate the PCE!_s capability to perform inter-domain P2MP path
computations.
OPEN object format defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object Body Format
In optional TLVs, we add a new TLV type 0x07, to indicate the inter-
domain P2MP path computation.
Li, et al. Expires July 3, 2012 [Page 19]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
6. IANA Considerations
6.1. OSPF PCE Capability Flag
As discussed in Section 5.1, a new OSPF Capability Flag is defined to
indicate inter-domain path computation capability. IANA is requested
to make the following allocation form the OSPF Parameters "Path
Computation Element (PCE) Capability Flags" registry:
Bit Description Reference
11 inter-domain path computation This I-D
6.2. PCEP TLV Type Indicators
As discussed in Section 5.5, a new inter-domain P2MP capability TLV
allows the PCE to advertise its inter-domain P2MP path computation
capability. IANA is requested to make the following allocation from
the "PCEP TLV Type Indicators" sub-registry:
Value Description Reference
7 inter-domain P2MP capable This I-D
Li, et al. Expires July 3, 2012 [Page 20]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
7. References
7.1. Normative References
[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 and GMPLS", October 2011.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
and J. Meuric, "Extensions to the Path Computation Element
Communication Protocol (PCEP) for Point-to-Multipoint
Traffic Engineering Label Switched Paths", RFC 6006,
September 2010.
7.2. Informative References
[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.
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
October 2010.
Li, et al. Expires July 3, 2012 [Page 21]
Internet-Draft H-PCE Extensions for P2MP Path December 2011
Authors' Addresses
KeJun Li
ZTE Corporation
6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 755 26773611
Email: li.kejun@zte.com.cn
XiaoPing Tu
ZTE Corporation
6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 755 26773624
Email: tu.xiaoping@zte.com.cn
ZhenTao Fu
ZTE Corporation
No.50, RuanJian Avenue
Yuhuatai District, Nanjing, Jiangsu
P.R.China
Phone: +86 25 88014227
Email: fu.zhentao@zte.com.cn
Li, et al. Expires July 3, 2012 [Page 22]