One document matched: draft-zhao-pce-pcep-inter-domain-p2mp-procedures-03.txt
Differences from draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02.txt
Internet Engineering Task Force Q. Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track Z.Ali
Created: February 4, 2010 T. Saad
Expires: August 4, 2010 Cisco Systems, Inc.
D. King
Old Dog Consulting
PCE-based Computation Procedure To Compute Shortest Constrained P2MP
Inter-domain Traffic Engineering Label Switched Paths
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-03.txt
Abstract
The ability to compute paths for constrained point-to-multipoint
(P2MP) Traffic Engineering Label Switched Paths(TE LSPs) across
multiple domains has been identified as a key requirement for the
deployment of P2MP services in MPLS and GMPLS networks. The Path
Computation Element (PCE) has been recognized as an appropriate
technology for the determination of inter-domain paths of P2MP TE
LSPs.
This document describes the procedures and extensions to the PCE
communication Protocol (PCEP) to handle requests and responses for
the computation of inter-domain paths for P2MP TE LSPs.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2010.
Zhao, et al. [Page 1]
Internet-Draft February 2010
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Computing a P2MP Tree . . . . . . . . . . . . . . . . . . .
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . .
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
6. Objective Functions . . . . . . . . . . . . . . . . . . . . .
7. Protocol Procedures . . . . . . . . . . . . . . . . . . . . .
7.1. Per Domain P2MP Path Computation . . . . . . . . . . . . .
7.2. Extending BRPC for P2MP Computation . . . . . . . . . . .
7.2.1. Definition of X-VSPT(i) . . . . . . . . . . . . . . . .
7.2.2. Definition of X-VSPT(i, d) . . . . . . . . . . . . . .
7.2.3. P2MP-BRPC Procedure . . . . . . . . . . . . . . . . . .
7.2.4. P2MP-BRPC Procedure Completion Failure . . . . . . . .
7.2.5. P2MP-BRPC Example . . . . . . . . . . . . . . . . . . .
7.3. Using Core Tree Based Path Computation . . . . . . . . . .
7.3.1. Core Tree Procedure . . . . . . . . . . . . . . . . . .
7.3.2. Core Tree Procedure Completion Failure . . . . . . . .
7.3.3. Core Tree Example . . . . . . . . . . . . . . . . . . .
8. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . .
8.1. P2MP-BRPC Procedure . . . . . . . . . . . . . . . . . . . .
8.1.2 VSPT Encoding . . . . . . . . . . . . . . . . . . . . .
8.2 Core Tree Procedure . . . . . . . . . . . . . . . . . . . .
8.2.1. The Extension of RP Object . . . . . . . . . . . . . .
8.2.2 The PCE Sequence Object . . . . . . . . . . . . . . . .
9. Manageability Considerations . . . . . . . . . . . . . . . . .
9.1. Control of Function and Policy . . . . . . . . . . . . . .
9.2. Information and Data Models . . . . . . . . . . . . . . .
9.3. Liveness Detection and Monitoring . . . . . . . . . . . .
9.4. Verifying Correct Operation . . . . . . . . . . . . . . .
9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . .
9.6. Impact on Network Operation . . . . . . . . . . . . . . .
10. Security Considerations . . . . . . . . . . . . . . . . . . .
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
Zhao, et al. [Page 2]
Internet-Draft February 2010
13. References . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1. Normative References . . . . . . . . . . . . . . . . . . .
13.2. Informative References . . . . . . . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . .
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction
Multicast services are increasingly in demand for high-capacity
applications such as multicast Virtual Private Networks (VPNs),
IP-television (IPTV) which may be on-demand or streamed, and
content-rich media distribution (for example, software distribution,
financial streaming, or data-sharing). The ability to compute
constrained Traffic Engineering Label Switched Paths (TE LSPs) for
point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks across multiple domains.
A domain can be defined as a collection of network elements within a
common sphere of address management or path computational
responsibility such as an IGP area or an Autonomous Systems.
The applicability of the Path Computation Element (PCE) [RFC4655]
for the computation of such paths is discussed in [RFC5671], and
the requirements placed on the PCE communications Protocol (PCEP)
for this are given in [PCE-P2MP-REQ].
This document describes how multiple PCE techniques can be combined
to address the requirements. These mechanisms include the use of the
per-domain path computation technique specified in [RFC5152],
extensions to the backward recursive path computation (BRPC)
technique specified in [RFC5441] for P2MP LSP path computation in an
inter-domain environment, and a new procedure for core-tree based
path computation defined in this document. These three mechanisms are
suitable for different environments (topologies, administrative
domains, policies, service requirements, etc.) and can also be
effectively combined.
Zhao, et al. [Page 3]
Internet-Draft February 2010
1.1 Computing a P2MP Tree
As discussed in [RFC4461], a P2MP tree is a graphical representation
of all TE links that are committed for a particular P2MP LSP. In
other words, a P2MP tree is a representation of the corresponding
P2MP tunnel on the TE network topology. A sub-tree is a part of the
P2MP tree describing how the root or an intermediate P2MP LSPs
minimizes packet duplication when P2P TE sub-LSPs traverse common
links. As described in [RFC5671] the computation of a P2MP tree
requires three major pieces of information. The first is the path
from the ingress LSR of a P2MP LSP to each of the egress LSRs, the
second is the traffic engineering related parameters, and the third
is the branch capability information.
Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source
and at least one destination residing in different domains) is
particularly difficult to compute even for a distributed PCE
architecture. For instance, while the BRPC recursive path
computation may be well-suited for P2P paths, P2MP path computation
involves multiple branching path segments from the source to the
multiple destinations. As such, inter-domain P2MP path computation
may result in a plurality of per-domain path options that may be
difficult to coordinate efficiently and effectively between domains.
That is, when one or more domains have multiple ingress and/or egress
border nodes, there is currently no known technique for one domain to
determine which border routers another domain will utilize for the
inter-domain P2MP tree, and no way to limit the computation of the
P2MP tree to those utilized border nodes.
A trivial solution to the computation of inter-domain P2MP tree would
be to compute shortest inter-domain P2P paths from source to each
destination and then combine them to generate an inter-domain,
shortest-path-to-destination P2MP tree. This solution, however,
cannot be used to trade cost to destination for overall tree cost
(i.e., it cannot produce a Steiner tree) and in the context of
inter-domain P2MP LSPs it cannot be used to reduce the number of
domain border nodes that are transited.
Apart from path computation difficulties faced due to the inter-
domain topology visibility issues, the computation of the minimum
P2MP Steiner tree, i.e. one which guarantees the least cost
resulting tree, is an NP-complete problem. Moreover, adding and/or
removing a single destination to/from the tree may result in an
entirely different tree. In this case, the frequent Steiner I tree
computation process may prove computationally intensive, and the
resulting frequent tunnel reconfiguration may even cause network
destabilization. There are several heuristic algorithms presented
in the literature that approximate the result within polynomial
time that are applicable within the context of a single-domain.
Zhao, et al. [Page 4]
Internet-Draft February 2010
1. Terminology and Acronyms
Terminology used in this document is consistent with the related
MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875],
[RFC5376], [RFC5440], [RFC5441]. [RFC5671], and [PCE-P2MP-REQ].
ABR: Area Border Router. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).
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.
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.
Core Tree: The core tree is a P2MP tree where the root is the
ingress LSR, the transit node and branch node are the BNs of the
transit domains and the leaf nodes are the leaf BNs of the leaf
domains.
Destination: The leaf nodes can be in the Root Domain, in a
Transit Domain, or in a Leaf Domain.
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n)
along a sequence of domains.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1)
along a 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.
P2MP LSP Path Tree: A set of LSRs and TE links that comprise the
path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs.
Root Boundary Node: An egress LSR from the root domain on the path
of the P2MP LSP.
Root Domain: The domain that includes the ingress (root) LSR.
TED: Traffic Engineering Database.
Transit Domain: A domain that has an upstream and one or more
downstream neighbour domain.
Branch Domain: A domain that has an upstream and more than one
downstream neighbour domain.
Zhao, et al. [Page 5]
Internet-Draft February 2010
Leaf Domain: A domain that doesn't have a downstream neighbor domain.
Leaf Boundary Node: An entry boundary node in the leaf domain.
Leaf Nodes: The LSRs that are the P2MP LSP's final destinations.
OF: Objective Function: A set of one or more optimization criteria
used for the computation of a single path (e.g., path cost
minimization), or the synchronized computation of a set of paths
(e.g., aggregate bandwidth consumption minimization). See [RFC4655]
and [RFC5541].
Path Domain Sequence: The sequence of domains for a path
between the ingress LSR and a leaf node.
PCE Sequence: The known sequence of PCEs for calculating a path
between the ingress LSR and leaf node.
PCE Topology Tree: A list of PCE Sequences which includes all the PCE
Sequences for each leaf node of the P2MP LSP.
PCE(i): A PCE that performs path computations for domain(i).
VSPT: Virtual Shortest Path Tree [RFC5441].
X-VSPT: Extended Virtual Shortest Path Tree.
3. Problem Statement
The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
[RFC4875] describes how to set up P2MP TE LSPs for use in MPLS and
GMPLS networks. The PCE is identified as a suitable application for
the computation of paths for P2MP TE LSPs [RFC5671].
[RFC5441] specifies a procedure relying on the use of multiple PCEs
to compute (P2P) inter-domain constrained shortest paths across a
predetermined sequence of domains, using a backward recursive path
computation technique. The technique can be combined with the use
of path keys [RFC5520] to preserve confidentiality across domains,
which is sometimes required when domains are managed by different
Service Providers.
Zhao, et al. [Page 6]
Internet-Draft February 2010
The PCE communication Protocol (PCEP) [RFC5440] is extended for
point-to-multipoint(P2MP) path computation requests and in
[PCE-P2MP-EXT]. However, that specification does not provide all
the necessary mechanisms to request the computation of inter-domain
P2MP TE LSPs.
This document presents a solution, and procedures and extensions to
PCEP to support P2MP inter-domain path computation.
4. Assumptions
It is assumed that due to deployment and commercial limitations
(e.g., inter-AS peering agreements) the sequence of domains for a
path (the path domain tree) will be known in advance.
The examples and scenarios used in this document are also based on
the following assumptions:
- The PCE that serves each domain in the path domain tree is known,
and the set of PCEs and their relationships is propagated to each PCE
during the first exchange of path computation requests;
- Each PCE knows about any leaf LSRs in the domain it serves;
- The boundary nodes to use on the LSP are pre-determined and form
path of the path domain tree. In this version of the document we do
not consider multi-homed domains.
Additional assumptions are documented in [RFC5441] and will not
be repeated here.
5. Requirements
This section summarizes the requirements specific to computing
inter-domain P2MP paths. In these requirements we note that the
actual computation times by any PCE implementation are outside the
scope of this document, but we observe that reducing the complexity
of the required computations has a beneficial effect on the
computation time regardless of implementation. Additionally,
reducing the number of message exchanges and the amount of
information exchanged will reduce the overall computation time for
the entire P2MP tree. We refer to the "Complexity of the
computation" as the impact on these aspects of path computation
time as various parameters of the topology and the P2MP LSP are
changed.
Zhao, et al. [Page 7]
Internet-Draft February 2010
Its also important that the solution preserves confidentiality
across domains, which is required when domains are managed by
different Service Providers.
A number of specific requirements are detailed below:
1. The requirements specified in [RFC5376];
1.1 PCEP must allow an SP to hide from other SPs the set of hops
within its own ASes that are traversed by an inter-AS inter-provider
TE LSP for each inter-AS TE LSP path segment an inter-AS PCE
computes, it may return to the requesting inter-AS PCE an inter-AS TE
LSP path segment from its own ASes without detailing the explicit
intra-AS hops.
2. A number of additional requirements have also been identified in
[RFC4461].
3. The computed P2MP LSP should be optimal when only considering the
paths among the BNs.
4. Grafting and pruning of multicast destinations in a domain should
have no impact on other domains and on the paths among BNs.
5. The complexity of the computation for each sub-tree within each
domain should be dependent only on the topology of the domain and it
should be independent of the domain sequence.
6. The number of PCEP request and reply messages should be
independent of the number of multicast destinations in each
domain.
7. Specifying the domain entry and exit nodes.
8. Specifying which nodes should be used as branch nodes.
9. Reoptimization of existing sub-trees.
10. Computation of P2MP paths that need to be diverse from existing
P2MP paths.
6. Objective Functions
During the computation of a single or a set of P2MP TE LSPs a request
to meet specific optimization criteria, called an Objective Function
(OF), may be requested.
Zhao, et al. [Page 8]
Internet-Draft February 2010
The computation of one or more P2MP TE-LSPs maybe subject to an OF in
order to select the "best" candidate paths. A variety of objective
functions have been identified as being important during the
computation of inter-domain P2MP LSPs. These are:
1. The sub-tree within each domain should be optimized.
1.1 Minimum cost tree [PCE-P2MP-REQ].
1.2 Shortest path tree [PCE-P2MP-REQ].
2. The P2MP LSP paths should be optimal while only considering the
entry and exit nodes of each domain as the transit, branch and leaf
nodes of the P2MP LSP path. (That is, the Core Tree should be
optimized.)
3. It should be possible to limit the number of entry points to a
domain.
4. It should be possible to force the branches for all leaves within
a domain to be in that domain.
7. Protocol Procedures
The following sections describe the procedures to satisfy the
requirements specified in the previous section.
7.1. Per Domain P2MP Path Computation
Computing P2P LSPs individually is an acceptable solution for
computing a P2MP tree. Per domain path computation [RFC5152] can be
used to compute P2P multi-domain paths, but it does not guarantee
to find the optimal path which crosses multiple domains.
Furthermore, constructing a P2MP tree from individual source to leaf
P2P LSPs does not guarantee to produce a least-cost tree.
This approach may be considered to have scaling issues during LSP
setup. That is, the LSP to each leaf is signaled separately, and
each border node must perform path computation for each leaf. A per
domain solution does suit simply-connected domains and where the
preferred points of interconnection are known.
7.2. Extending BRPC for P2MP Computation
This section describes the extension to BRPC procedures defined
in [RFC5441]. It also details procedure on how extended BRPC
can be used for path computation of a P2MP LSP.
Zhao, et al. [Page 9]
Internet-Draft February 2010
7.2.1. Definition of X-VSPT(i)
The definition of an X-VSPT(i) is similar to definition of that
of a VSPT(i) in [RFC5441], with a few exceptions outlined in the
following.
In the case of computation of a VSPT(i), PCE(i) only considers
the entry BNs of domain(i). That is, only the BNs that provide
connectivity from domain(i-1). This works well in the P2P case as
there is only one destination and there is no added value in
knowing connectivity from BNs that do not provide connectivity
from domain(i-1). However, for the case of P2MP tree path
computation, and since there is usually more than one destination
per P2MP LSP (some residing in different destination domains)
knowing the connectivity from BNs that are not connected with
domain(i-1) is useful. Specifically, it improves the ability of
the ingress PCE to compute lower cost P2MP trees by favoring
paths for new destination that branch off existing sub-tree as
opposed to shortest end-to-end P2P path from source to
destination. The set of exit BNs of the domain remains the same as
defined in [RFC5441].
X-VSPT(i) is defined as follows-
In each domain (i),
o There is a set of X-en(i) all entry BNs, such that BN-
en(k,i) is the kth entry BN of domain(i).
o There is a set of Y-ex(i) exit BNs, such that BN-
ex(k,i) is the kth exit BN of domain(i).
VSPT(i), as defined in [RFC5441], for P2P LSP is a tree that
provides a list of shortest paths from BN-en(1,i), BN-en(2,i),
... BN-en(j,i) to destination such that j <= [X-en(i)], where
[X-en(i)] is the number of entry BNs in domain(i). The X-
VSPT(i), in addition to the VSPT(i), includes the shortest paths from
the BN-en(k,i) to all BN-ex(i), such that k is the BN that is
along the shortest path to destination, and BN-ex(i) is an exit
BN in domain (i). Nonetheless, the X-VSPT(i) may exclude some
BN-ex(i) according to policy constraints (either due to local
policy or policies signaled in the path computation request).
Also, when more than one BN-ex(i) connect to the same
neighboring domain (domain (i+1)), the X-VSPT(i) only includes
the BN-ex along the least cost path to domain (i+1). In the
presence of inter-AS link, the X-VSPT includes the path of the
inter-AS TE links connecting domain(i) to domain(i+1).
For a destination domain, the X-VSPT(i) includes shortest paths from
the destination node to the set of BN-en nodes.
Zhao, et al. [Page 10]
Internet-Draft February 2010
7.2.2. Definition of X-VSPT(i, d)
X-VSPT(i, d) is defined as X-VSPT at domain(i) to reach destination
d of a P2MP tree.
7.2.3. P2MP-BRPC Procedure
In the following section we outline steps of the P2MP-BRPC procedure.
Given a set of destinations D = 1, 2, ... d, where |D| is the
total number of destinations in the P2MP LSP. This draft assumes
that the ingress PCE, PCE(1), has a mechanism to determine the set
of PCEs (i.e. PCE-chain) to be traversed for the computation of
the inter-domain path on per destination basis. The said mechanism
is outside the scope of this document.
Denote by n^d the domain of destination d.
Note, it is possible for the ingress PCE, PCE(1), to request path
computation for destinations sequentially (one-by-one), or
simultaneously (in-parallel). In the former case, the computation
burden in P2MP-BRPC can be further reduced. PCE(1) can include the
P2MP sub-tree(d-1), which includes X-VSPT(1, 1), X-VSPT(1, 2),
..., X-VSPT(1, d-1), i.e. that for destinations up to (d-1), in
the PCE request for destination (d). By doing so, it is possible
for PCE(n^d) to immediately compute a best path for (d) by
computing a path from (d) to the closest branching node within the
P2MP sub-tree(d-1). However, in this version of the draft only
parallel requests for computation of X-VSPT(n^d, d) for d = 1, 2, .
. . D are considered.
A PCC discovers a PCE, PCE(1), that is capable of
serving its path computation request and forwards to it the P2MP
path computation request.
PCE(1) will then iteratively send P2MP path requests to all
destinations d = 1, 2, ... D, in the P2MP tree, as follows:
Start of iteration(d):
Step (1, d): PCE(1) forwards the P2MP path computation
Request such that it traverses a set of PCE(s) until it
reaches PCE(n^d).
Zhao, et al. [Page 11]
Internet-Draft February 2010
Step (2, d): PCE(n^d) computes X-VSPT(n^d, d) by
including, in addition to VSPT(i), constraints shortest
paths from the destination node (d) to all exit BNs BN-
ex(i), as described earlier. When multiple BN-ex(n^d)
connect to the same neighboring domain (domain (n^d +1)),
the X-VSPT(n^d) only includes the BN-ex along the least
cost path to domain (n^d +1). In the presence of inter-AS
link, the X-VSPT includes the path of the inter-AS TE
links connecting domain(n^d) to domain(n^d +1).
Step (3, d): X-VSPT(n^d) is forwarded to PCE((n-1)^d).
According to [RFC5441], PCE((n-1)^d) computes
VSPT((n-1)^d) by finding constrained shortest paths from all
BN-en((n-1)^d) to the destination (d) using VSPT(n^d).
When this step is completed, only a sub-set of BN-
en(n^d) are selected. At this point, PCE((n-1)^d) can
prune X-VSPT(n-1) to exclude those BN-en (and the
respective X-VSPT(n^d) branches attached to them) that
were not considered in computation of VSPT((n-1)^d),
and the respective X-VSPT(n^d) branches attached to
them.
PCE((n-1)^d) appends to VSPT((n-1)^d) the
X-VSPT((n-1)^d) by by finding constrained shortest paths from
all BN-en((n-1)^d) to all other BN-ex((n-1)^d). When multiple
BN-ex((n-1)^d) connect to the same neighboring domain,
the X-VSPT((n-1)^d) only includes the BN-ex along the
least cost path to that domain.
Step(i,d): The previous procedure is repeated at each PCE(i^d)
where i = n-1 ... 2.
End of iteration.
When PCE(1) receives replies with X-VSPTs(2,d) for all
destinations, it forms a virtual graph composed of the source
node, BNs included in the X-VSPTs, and the destinations. PCE(1)
can then use a suitable heuristic to compute a feasible P2MP tree.
Note, an X-VSPT(i, d) tree may be returned in the form of an
explicit path (in which case all the hops along the path segment
are listed) or a loose path (in which case only the BN is
specified) so as to preserve confidentiality along with the
respective cost. In the later case, various techniques can be
used in order to retrieve the computed explicit paths on a per
domain basis during the signaling process thanks to the use of
path keys as described in [RFC5520].
Zhao, et al. [Page 12]
Internet-Draft February 2010
7.2.4. P2MP-BRPC Procedure Completion Failure
To be described in a later version of this document.
7.2.5. P2MP-BRPC Example
To be described in a later version of this document.
7.3. Using Core Tree Based Path Computation
A core tree based solution provides an optimal inter-domain P2MP TE
LSP and meets the requirements and OFs outlined in previous sections.
A core tree is a path tree with nodes from each domain corresponding
to the PCE topology which satisfies the following conditions:
- The root of the core tree is the ingress LSR in the root domain;
- The leaf of the core tree is the entry node in the leaf domain;
- The transit and branch nodes of the core tree are from the entry
and exit nodes from the transit and branch domains.
7.3.1 Core Tree Procedure
Computing the complete P2MP LSP path tree is done in two phases:
Procedure Phase 1: Build the P2MP LSP Core Tree.
The algorithms to compute the optimal large core tree are outside
scope of this document. In the case that the number of domains and
the number of BNs are not big, the following extended BRPC based
procedure can be used to compute the core tree.
BRPC Based Core Tree Path Computation Procedure
(1). Using the BRPC procedures to compute the VSPT(i) for each leaf
BN(i), i=1 to n, where n is the total number of entry nodes for all
the leaf domains. In each VSPT(i), there are a number of P(i) paths.
(2). When the root PCE has computed all the VSPT(i), i=1 to n, take
one path from each VSPT and form a set of paths, we call it a
PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n);
(3). For each PathSet(j), there are n S2L (Source to Leaf BN) paths
and form these n paths into a Core Tree(j);
(4). There will be M number of Core Trees computed from step3.
Apply the OF to each of these M Core Trees and find the optimal
Core Tree.
Zhao, et al. [Page 13]
Internet-Draft February 2010
Procedure Phase 2: Grafting destinations to the P2MP LSP Core Tree.
Once the core tree is built, the grafting of all the leaf nodes from
each domain to the core tree can be achieved by a number of
algorithms. One algorithm for doing this phase is that the root PCE
will send the request with C bit set for the path computation to the
destination(s) directly to the PCE where the destination(s) belong(s)
along with the core tree computed from the phase 1.
7.3.2. Core Tree Procedure Completion Failure
To be described in a later version of this document.
7.3.3. Core Tree Example
To be described in a later version of this document.
8. PCEP Protocol Extensions
8.1. P2MP-BRPC Procedure
The X-BRPC procedure proposed in this document requires the
specification of a new flag of the RP object carried within the
PCReq message (defined in [RFC5440]), as follows
X-VSPT Flag
Bit Number Name Flag
TBD X-VSPT
When set, the VSPT Flag indicates that the PCC requests the
computation of an inter-domain P2MP-TE TE LSP using the X-BRPC
procedure defined in this document.
8.1.2 VSPT Encoding
Similar to the VSPT, the X-VSPT can be returned within a PCRep
message. The encoding may consist of non-ordered lists of EROs
where each ERO represents a path segment from a entry BN to the
exit BNs, or from destination to an exit BN as described earlier
in Section 7.2.3.
Encoding using SERO is to be considered in the later version
of this document.
8.2 Core Tree Based Procedure
The following section describes the protocol extensions for Core Tree
based inter-domain P2MP path calculation.
Zhao, et al. [Page 14]
Internet-Draft February 2010
8.2.1. The Extension of RP Object
The extended format of the RP object body to include the C bit is as
follows:
The C bit is added in the flag bits field of the RP object to signal
the receiver of the message that the request/reply is for inter-
domain P2MP Core Tree or not.
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 |C|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RP Object Body Format
The following flags are added in this draft:
o C ( P2MP Core Tree bit - 1 bit):
0: This indicates that this is normal PCReq/PCRrep for P2MP.
1: This indicates that this is PCReq or PCRep message for
inter-domain Core Tree P2MP. When the C bit is set, then the
request message should have the Core Tree passed along with the
destinations which and then graphed to the tree.
8.2.2 The PCE Sequence Object
The PCE Sequence Object is added to the existing PCE protocol. A
list of this objects will represent the PCE topology tree. A list of
Sequence Objects can be exchanged between PCEs during the PCE
capability exchange or on the first path computation request message
between PCEs. In this case, the request message format needs to be
changed to include the list of PCE Sequence Objects for the PCE
inter-domain P2MP calculation request.
Each PCE Sequence can be obtained from the domain sequence for a
specific path. All the PCE sequences for all the paths of P2MP
inter-domain form the PCE Topology Tree of the P2MP LSP.
The format of the new PCE Sequence Object for IPv4 (Object-Type 3) is
as follows:
Zhao, et al. [Page 15]
Internet-Draft February 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for root PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| !! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the PCE corresponding to the leafDomain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The New PCE Sequence Object Body Format for IPv4
The format of the new PCE Sequence Object for IPv6 (Object-Type 3) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for root PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| !! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for the PCE corresponding to the leafDomain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The New PCE Sequence Object Body Format for IPv6
9. Manageability Considerations
[PCE-P2MP-REQ] describes various manageability requirements in
support of P2MP path computation when applying PCEP. This section
describes how manageability requirements mentioned in [PCE-P2MP-REQ]
are supported in the context of PCEP extensions specified in this
document.
Note that [RFC5440] describes various manageability considerations in
PCEP, and most of manageability requirements mentioned in [PCE-P2MP
P2MP] are already covered there.
Zhao, et al. [Page 16]
Internet-Draft February 2010
9.1. Control of Function and Policy
In addition to configuration parameters listed in [RFC5440], the
following parameters MAY be required.
o P2MP path computations enabled or disabled.
o Advertisement of P2MP path computation capability enabled or
disabled (discovery protocol, capability exchange).
9.2. Information and Data Models
As described in [PCE-P2MP-REQ], MIB objects MUST be supported for
PCEP extensions specified in this document.
9.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements.
9.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements.
9.5. Requirements on Other Protocols and Functional Components
As described in [PCE-P2MP-REQ], the PCE MUST obtain information
about the P2MP signaling and branching capabilities of each LSR in
the network.
Protocol extensions specified in this document does not provide such
capability. Other mechanisms MUST be present.
9.6. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document
will not have significant impact on network operations.
10. Security Considerations
As described in [PCE-P2MP-REQ], P2MP path computation requests are
more CPU-intensive and also use more link bandwidth. Therefore, it
may be more vulnerable to denial of service attacks. Therefore, it is
more important that implementations conform to security requirements
of [RFC5440], and the implementer utilize those security features.
Zhao, et al. [Page 17]
Internet-Draft February 2010
11. IANA Considerations
A new flag of the RP object (specified in [RFC5440]) is defined in
this document.
X-VSPT Flag
Bit Number Name Flag Reference
TBD X-VSPT This document.
A number of additional IANA considerations exist and this section
will highlight those requests in future versions of this document.
12. Acknowledgements
The authors would like to thank Adrian Farrel and Dan Tappan for
their valuable comments on this draft.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
April 2009.
[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.
[RFC5541] Roux, J., Vasseur, J., and Y. Lee, "Encoding
of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, June 2009.
Zhao, et al. [Page 18]
Internet-Draft February 2010
13.2. Informative References
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
Computation Element (PCE) to Point-to-Multipoint (P2MP)
MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
October 2009.
[PCE-P2MP-REQ]
Yasukawa, S. and A. Farrel, "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)",
draft-ietf-pce-p2mp-req-05 (work in progress),
December 2009.
[PCE-P2MP-EXT] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
Zhao, Q., King, D., "Extensions to the Path Computation
Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", draft-ietf-pce-pcep-p2mp-extensions-07.txt,
work in progress, February, 2010.
Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
USA
Email: qzhao@huawei.com
Zafar Ali
Cisco Systems, Inc.
USA
Email: zali@cisco.com
Tarek Saad
Cisco Systems, Inc.
USA
Email: tsaad@cisco.com
Zhao, et al. [Page 19]
Internet-Draft February 2010
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Contributors' Addresses
David Amzallag
British Telecommunications plc
UK
Email: david.Amzallag@bt.com
Fabien Verhaeghe
Thales Communication France
160 Bd Valmy 92700 Colombes
France
Email: fabien.verhaeghe@gmail.com
Kenji Kumaki
KDDI R&D Laboratories, Inc.
Japan
Email: ke-kumaki@kddi.com
Zhao, et al. [Page 20]
Internet-Draft February 2010
| PAFTECH AB 2003-2026 | 2026-04-23 09:58:27 |