draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07.txt   draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08.txt 
PCE Working Group Q. Zhao PCE Working Group Q. Zhao
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Experimental Huawei Technology Intended status: Experimental Huawei Technology
Expires: December 3, 2014 D. King Expires: December 17, 2014 D. King
Old Dog Consulting Old Dog Consulting
Z. Ali Z. Ali
Cisco Systems Cisco Systems
R. Casellas R. Casellas
CTTC CTTC
June 3, 2014 June 17, 2014
PCE-based Computation Procedure To Compute Shortest Constrained P2MP PCE-based Computation Procedure To Compute Shortest Constrained P2MP
Inter-domain Traffic Engineering Label Switched Paths Inter-domain Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08
Abstract Abstract
The ability to compute paths for constrained point-to-multipoint The ability to compute paths for constrained point-to-multipoint
(P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across
multiple domains has been identified as a key requirement for the multiple domains has been identified as a key requirement for the
deployment of P2MP services in MPLS and GMPLS-controlled networks. deployment of P2MP services in MPLS and GMPLS-controlled networks.
The Path Computation Element (PCE) has been recognized as an The Path Computation Element (PCE) has been recognized as an
appropriate technology for the determination of inter-domain paths of appropriate technology for the determination of inter-domain paths of
P2MP TE LSPs. P2MP TE LSPs.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2014. This Internet-Draft will expire on December 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.2. Requirements Language . . . . . . . . . . . . . . . . . .3 1.2. Requirements Language . . . . . . . . . . . . . . . . . .2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .2
3. Examination of Existing Mechanisms . . . . . . . . . . . . .5 3. Examination of Existing Mechanisms . . . . . . . . . . . . .3
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .6 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .7 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5
6. Objective Functions and Constraints. . . . . . . . . . . . . .8 6. Objective Functions and Constraints. . . . . . . . . . . . . .7
7. P2MP Path Computation Procedures . . . . . . . . . . . . . . .8 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . .8
7.1. Core-Trees . . . . . . . . . . . . . . . . . . . . . . . .9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . .8
7.2. Optimal Core-Tree Computation Procedure. . . . . . . . . .12 7.2. Core-Trees . . . . . . . . . . . . . . . . . . . . . . . .9
7.3. Sub-tree Computation Procedures . . . . . . . . . . . . .13 7.3. Optimal Core-Tree Computation Procedure. . . . . . . . . .12
7.4. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .13 7.4. Sub-tree Computation Procedures . . . . . . . . . . . . .13
7.4.1. The Extension of RP Object . . . . . . . . . . . . . .13 7.5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .13
7.4.2. Domain and PCE Sequence . . . . . . . . . . . . . . .14 7.5.1. The Extension of RP Object . . . . . . . . . . . . . .13
7.5. Relationship with Hierarchical PCE . . . . . . . . . . . .14 7.5.2. Domain and PCE Sequence . . . . . . . . . . . . . . .14
7.6. Parallelism . . . . . . . . . . . . . . . . . . . . . . .14 7.6. Relationship with Hierarchical PCE . . . . . . . . . . . .14
7.7. Parallelism . . . . . . . . . . . . . . . . . . . . . . .15
8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .15 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .15
8.1. End-to-end Protection . . . . . . . . . . . . . . . . . .15 8.1. End-to-end Protection . . . . . . . . . . . . . . . . . .15
8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .15 8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .15
9. Manageability Considerations . . . . . . . . . . . . . . . . .16 9. Manageability Considerations . . . . . . . . . . . . . . . . .16
9.1. Control of Function and Policy . . . . . . . . . . . . . .16 9.1. Control of Function and Policy . . . . . . . . . . . . . .16
9.2. Information and Data Models . . . . . . . . . . . . . . .16 9.2. Information and Data Models . . . . . . . . . . . . . . .16
9.3. Liveness Detection and Monitoring . . . . . . . . . . . .16 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .16
9.4. Verifying Correct Operation . . . . . . . . . . . . . . .16 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .16
9.5. Requirements on Other Protocols and Functional Components.17 9.5. Requirements on Other Protocols and Functional Components.17
9.6. Impact on Network Operation . . . . . . . . . . . . . . .17 9.6. Impact on Network Operation . . . . . . . . . . . . . . .17
9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .17 9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .17
10. Security Considerations . . . . . . . . . . . . . . . . . . .17 10. Security Considerations . . . . . . . . . . . . . . . . . . .17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . .18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .19
13.1. Normative References . . . . . . . . . . . . . . . . . . .18 13.1. Normative References . . . . . . . . . . . . . . . . . . .19
13.2. Informative References . . . . . . . . . . . . . . . . . .19 13.2. Informative References . . . . . . . . . . . . . . . . . .19
14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .21 14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .21
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .21 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .21
1. Introduction 1. Introduction
Multicast services are increasingly in demand for high-capacity Multicast services are increasingly in demand for high-capacity
applications such as multicast Virtual Private Networks (VPNs), IP- applications such as multicast Virtual Private Networks (VPNs), IP-
television (IPTV) which may be on-demand or streamed, and content- television (IPTV) which may be on-demand or streamed, and content-
rich media distribution (for example, software distribution, rich media distribution (for example, software distribution,
financial streaming, or database-replication). The ability to financial streaming, or database-replication). The ability to
compute constrained Traffic Engineering Label Switched Paths (TE compute constrained Traffic Engineering Label Switched Paths (TE
LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks across Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains are therefore required. multiple domains are therefore required.
The applicability of the Path Computation Element (PCE) [RFC4655] for The applicability of the PCE [RFC4655] for the computation of such
the computation of such paths is discussed in [RFC5671], and the paths is discussed in [RFC5671], and the requirements placed on the
requirements placed on the PCE communications Protocol (PCEP) for PCE communications Protocol (PCEP) for this are given in [RFC5862].
this are given in [RFC5862].
This document details the requirements for inter-domain P2MP path This document details the requirements for inter-domain P2MP path
computation, it then describes the experimental procedure computation, it then describes the experimental procedure
"core-tree" path computation, developed to address the requirements "core-tree" path computation, developed to address the requirements
and objectives for inter-domain P2MP path computation. and objectives for inter-domain P2MP path computation.
When results of implementation and deployment are available, this When results of implementation and deployment are available, this
document will be updated and refined, and then moved from document will be updated and refined, and then moved from
Experimental status to Standards Track. Experimental status to Standards Track.
1.2. Scope 1.2. Scope
The inter-domain P2MP path computation procedures described in this The inter-domain P2MP path computation procedures described in this
document is experimental. The experiment is intended to enable document is experimental. The experiment is intended to enable
research for the Path Computation Element (PCE) to support research for the usage of the PCE to support inter-domain P2MP path
inter-domain P2MP path computation. computation.
This document is not intended to replace the intra-domain P2MP path This document is not intended to replace the intra-domain P2MP path
computation approach supported by [RFC6006], and will not impact computation approach defined by [RFC6006], and will not impact
existing PCE procedures and operations. existing PCE procedures and operations.
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
Terminology used in this document is consistent with the related Terminology used in this document is consistent with the related
MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875], MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875],
[RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862]. [RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862].
The additional terms Core-Tree, Leaf Domain, Path Tree, Path Domain The additional terms Core-Tree, Leaf Domain, Path Tree, Path Domain
Sequence, Path Domain Tree, Root Domain, Sub-Tree and Transit/branch Sequence, Path Domain Tree, Root Domain, Sub-Tree and Transit/branch
Domain are further defined below. Domain are further defined below.
Core-Tree: a P2MP tree where the root is the ingress Label Switching Core-Tree: a P2MP tree where the root is the ingress Label Switching
Router (LSR), and the leaf nodes are the entry BNs of the leaf Router (LSR), and the leaf nodes are the entry BNs of the leaf
skipping to change at page 5, line 25 skipping to change at page 4, line 19
application for the computation of paths for P2MP TE LSPs [RFC5671]. application for the computation of paths for P2MP TE LSPs [RFC5671].
[RFC5441] specifies a procedure relying on the use of multiple PCEs [RFC5441] specifies a procedure relying on the use of multiple PCEs
to compute Point to Point (P2P) inter-domain constrained shortest to compute Point to Point (P2P) inter-domain constrained shortest
paths across a predetermined sequence of domains, using a Backward paths across a predetermined sequence of domains, using a Backward
Recursive Path Computation (BRPC) technique. The technique can be Recursive Path Computation (BRPC) technique. The technique can be
combined with the use of Path-Keys [RFC5520] to preserve combined with the use of Path-Keys [RFC5520] to preserve
confidentiality across domains, which is sometimes required when confidentiality across domains, which is sometimes required when
domains are managed by different Service Providers. domains are managed by different Service Providers.
The PCE communication Protocol (PCEP) [RFC5440] is extended for PCEP [RFC5440] was extended for point-to-multipoint (P2MP) path
point-to-multipoint (P2MP) path computation requests in [RFC6006]. computation requests in [RFC6006].
As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and
TE links that comprise the path of a P2MP TE LSP from its ingress LSR TE links that comprise the path of a P2MP TE LSP from its ingress LSR
to all of its egress LSRs. A P2MP LSP is set up with TE constraints to all of its egress LSRs. A P2MP LSP is set up with TE constraints
and allows efficient packet or data replication at various branching and allows efficient packet or data replication at various branching
points in the network. As per [RFC5671] branch point selection is points in the network. As per [RFC5671] branch point selection is
fundamental to the determination of the paths for a P2MP TE LSP. Not fundamental to the determination of the paths for a P2MP TE LSP. Not
only is this selection constrained by the network topology and only is this selection constrained by the network topology and
available network resources, but it is determined by the objective available network resources, but it is determined by the objective
functions (OF) that may be applied to path computation. functions (OF) that may be applied to path computation.
skipping to change at page 8, line 51 skipping to change at page 8, line 32
o The stability of the core-tree. o The stability of the core-tree.
The solution SHOULD allow these trade-offs to be made at computation The solution SHOULD allow these trade-offs to be made at computation
time. time.
The algorithms used to compute optimal paths using a combination of The algorithms used to compute optimal paths using a combination of
OFs and multiple constraints is out of scope of this document. OFs and multiple constraints is out of scope of this document.
7. P2MP Path Computation Procedures 7. P2MP Path Computation Procedures
A P2MP Path computation can be broken down into two steps of core- 7.1. General
tree computation and grafting of sub-trees. Breaking the procedure
into two steps has following impact - A P2MP path computation can be broken down into two steps of
core-tree computation and grafting of sub-trees. Breaking the
procedure into these specific steps has the following impact:
o The core-tree and sub-tree are smaller in comparison to o The core-tree and sub-tree are smaller in comparison to
the full P2MP Tree and are thus easier to compute. the full P2MP Tree and are thus easier to compute.
o An implementation MAY choose to keep the core-tree fairly static o An implementation MAY choose to keep the core-tree fairly static
or computed offline (trade-off with optimality). or computed offline (trade-off with optimality).
o Adding/Pruning of leaves which require changes to sub-tree in leaf- o Adding/Pruning of leaves which require changes to sub-tree in leaf-
domain only. domain only.
o The PCEP message size is smaller in comparison. o The PCEP message size is smaller in comparison.
The following sections describe the core-tree based procedures to Allowing the core-tree based solution to provide an optimal
satisfy the requirements specified in the previous section. A core- inter-domain P2MP TE LSP.
tree based solution provides an optimal inter-domain P2MP TE LSP.
7.1. Core-Trees The following sub-sections describe the core-tree based
mechanism, including procedures and PCEP extensions, that satisfy
the requirements and objectives specified in Section 5 and Section 6
of this document.
7.2. Core-Trees
A core-tree is defined as a tree that satisfies the following A core-tree is defined as a tree that satisfies the following
conditions: conditions:
o The root of the core-tree is the ingress LSR in the root domain; o The root of the core-tree is the ingress LSR in the root domain;
o The leaves of the core-tree are the entry boundary nodes in the o The leaves of the core-tree are the entry boundary nodes in the
leaf domains. leaf domains.
To support confidentiality these nodes and links MAY be hidden using To support confidentiality these nodes and links MAY be hidden using
skipping to change at page 12, line 5 skipping to change at page 12, line 5
|PK1| |PK2| |PK1| |PK2|
/ / \ / / \
/ / \ / / \
(I) (J) (K) (I) (J) (K)
/ \ / \ / \ / \
/ \ / \ / \ / \
(L) (W) (P) (T) (L) (W) (P) (T)
Figure 3: Core-Tree with Path-Key Figure 3: Core-Tree with Path-Key
7.2. Optimal Core-Tree Computation Procedure 7.3. Optimal Core-Tree Computation Procedure
Applying the core-tree procedure to large groups of domains, such as Applying the core-tree procedure to large groups of domains, such as
the Internet, is not considered feasible or desirable, and is out of the Internet, is not considered feasible or desirable, and is out of
scope for this document. scope for this document.
The following extended BRPC-based procedure can be used to compute The following extended BRPC-based procedure can be used to compute
the core-tree. Note that a root PCE MAY further use its own enhanced the core-tree. Note that a root PCE MAY further use its own enhanced
optimization techniques in future to compute the core-tree. optimization techniques in future to compute the core-tree.
A BRPC-based core-tree path computation procedure is described below: A BRPC-based core-tree path computation procedure is described below:
skipping to change at page 12, line 33 skipping to change at page 12, line 33
one path from each VSPT and form all possible sets of paths, we one path from each VSPT and form all possible sets of paths, we
call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n); call them 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 3. For each PathSet(j), there are n S2L (Source-to-Leaf) BN paths
and form these n paths into a core-tree(j); and form these n paths into a core-tree(j);
4. There will be M number core-trees computed from step 3. An 4. There will be M number core-trees computed from step 3. An
optimal core-tree is selected based on the OF and constraints. optimal core-tree is selected based on the OF and constraints.
Note that, since point to point BRPC procedure is used to compute Note that, since point to point BRPC procedure is used to compute
VSPT, the path request and response messages format as per [RFC5440] VSPT, the path request and response message format defined in
are used. [RFC5440] are used.
Also note that the application of BRPC in the aforementioned Also note that the application of BRPC in the aforementioned
procedure differs from the typical one since paths returned from a procedure differs from the typical one since paths returned from a
downstream PCE are not necessarily pruned from the solution set downstream PCE are not necessarily pruned from the solution set
(extended VSPT) by intermediate PCEs. The reason for this is that if (extended VSPT) by intermediate PCEs. The reason for this is that if
the PCE in a downstream domain does the pruning and returns the the PCE in a downstream domain does the pruning and returns the
single optimal sub-path to the upstream PCE, the combination of these single optimal sub-path to the upstream PCE, the combination of these
single optimal sub-paths into a core-tree is not necessarily optimal single optimal sub-paths into a core-tree is not necessarily optimal
even if each S2L (Source-to-Leaf) sub-path is optimal. even if each S2L (Source-to-Leaf) sub-path is optimal.
skipping to change at page 13, line 24 skipping to change at page 13, line 24
speaking the number of potential paths at the ingress PCE Q = speaking the number of potential paths at the ingress PCE Q =
prod E(k) x X(k). prod E(k) x X(k).
Consequently, it is expected that the core-tree will be typically Consequently, it is expected that the core-tree will be typically
computed offline, without precluding the use of dynamic, online computed offline, without precluding the use of dynamic, online
mechanisms such as the one presented here, in which case it SHOULD be mechanisms such as the one presented here, in which case it SHOULD be
possible to configure transit PCEs to control the number of paths possible to configure transit PCEs to control the number of paths
sent upstream during BRPC (trading trimming for optimality at the sent upstream during BRPC (trading trimming for optimality at the
point of trimming and downwards). point of trimming and downwards).
7.3. Sub-tree Computation Procedures 7.4. Sub-tree Computation Procedures
Once the core-tree is built, the grafting of all the leaf nodes from 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 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 algorithms. One algorithm for doing this phase is that the root PCE
will send the request with C bit set (as defined in section 7.4.1 of will send the request with C bit set (as defined in section 7.4.1 of
this document) for the path computation to the destination(s) this document) for the path computation to the destination(s)
directly to the PCE where the destination(s) belong(s) along with the directly to the PCE where the destination(s) belong(s) along with the
core-tree computed from section 7.2. core-tree computed from section 7.2.
This approach requires that the root PCE manage a potentially large This approach requires that the root PCE manage a potentially large
skipping to change at page 13, line 51 skipping to change at page 13, line 51
PCEs forward requests and responses from the root PCE towards the PCEs forward requests and responses from the root PCE towards the
leaf PCEs and vice-versa. leaf PCEs and vice-versa.
Note that the P2MP path request and response format is as per Note that the P2MP path request and response format is as per
[RFC6006], where Record Route Object (RRO) are used to carry the [RFC6006], where Record Route Object (RRO) are used to carry the
core-tree paths in the P2MP grafting request. core-tree paths in the P2MP grafting request.
The algorithms to compute the optimal large sub-tree are outside The algorithms to compute the optimal large sub-tree are outside
scope of this document. scope of this document.
7.4. PCEP Protocol Extensions 7.5. PCEP Protocol Extensions
7.4.1. The Extension of RP Object 7.5.1. The Extension of RP Object
This experiment will be carried out by extending the RP (Request This experiment will be carried out by extending the RP (Request
Parameters) object (defined in [RFC5440]) used in PCEP requests Parameters) object (defined in [RFC5440]) used in PCEP requests
and responses. and responses.
The extended format of the RP object body to include the C bit is as The extended format of the RP object body to include the C bit is as
follows: follows:
The C bit is added in the flag bits field of the RP object to signal 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- the receiver of the message that the request/reply is for inter-
domain P2MP core-tree or not. domain P2MP core-tree or not.
skipping to change at page 14, line 29 skipping to change at page 14, line 29
C bit (Core-Tree bit - 1 bit): C bit (Core-Tree bit - 1 bit):
0: This indicates that this is not for an inter-domain P2MP 0: This indicates that this is not for an inter-domain P2MP
core-tree. core-tree.
1: This indicates that this is a PCEP request or a response 1: This indicates that this is a PCEP request or a response
for the computation of a inter-domain core-tree or for the for the computation of a inter-domain core-tree or for the
grafting of a sub-tree to a inter-domain core-tree. grafting of a sub-tree to a inter-domain core-tree.
7.4.2. Domain and PCE Sequence 7.5.2. Domain and PCE Sequence
The procedure as described in this document requires the domain-tree The procedure described in this document requires the domain-tree
to be known in advance. This information MAY be either to be known in advance. This information MAY be either
administratively predetermined or dynamically discovered by some administratively predetermined or dynamically discovered by some
means such as Hierarchical PCE (H-PCE) [RFC6805] framework, or means such as Hierarchical PCE (H-PCE) [RFC6805] framework, or
derived through the IGP/BGP routing information. derived through the IGP/BGP routing information.
Examples of ways to encode the domain path tree include [RFC5886] Examples of ways to encode the domain path tree include [RFC5886]
using PCE-ID Object and [DOMAIN-SEQ]. using PCE-ID Object and [DOMAIN-SEQ].
7.5. Using H-PCE for Scalability 7.6. Using H-PCE for Scalability
The ingress/root PCE is responsible for the core-tree computation as The ingress/root PCE is responsible for the core-tree computation as
well as grafting of sub-trees into the multi-domain tree. Therefore, well as grafting of sub-trees into the multi-domain tree. Therefore,
the ingress/root PCE will receive all computed path segments from all the ingress/root PCE will receive all computed path segments from all
the involved domains. When the ingress/root PCE chooses to have a the involved domains. When the ingress/root PCE chooses to have a
PCEP session with all involved PCEs, this may cause an excessive PCEP session with all involved PCEs, this may cause an excessive
number of sessions or added complexity in implementations. number of sessions or added complexity in implementations.
The use of the H-PCE framework [RFC6805] may be used to establish a The use of the H-PCE framework [RFC6805] may be used to establish a
dedicated PCE with the capability (memory and CPU) and knowledge to dedicated PCE with the capability (memory and CPU) and knowledge to
maintain the necessary PCEP sessions. The parent PCE would be maintain the necessary PCEP sessions. The parent PCE would be
responsible to request intra-domain path computation request to the responsible to request intra-domain path computation request to the
PCEs, combine them and return the overall P2MP tree. PCEs, combine them and return the overall P2MP tree.
7.6. Parallelism 7.7. Parallelism
In order to minimize latency in path computation in multi-domain In order to minimize latency in path computation in multi-domain
networks, intra-domain path segments and intra-domain sub-trees networks, intra-domain path segments and intra-domain sub-trees
can be computed in parallel when possible. The proposed can be computed in parallel when possible. The proposed
procedures in this draft present opportunities for parallelism: procedures in this draft present opportunities for parallelism:
1. The BRPC procedure for each leaf boundary node can be launched in 1. The BRPC procedure for each leaf boundary node can be launched in
parallel by the ingress/root PCE for dynamic computation of parallel by the ingress/root PCE for dynamic computation of
core-tree. core-tree.
2. The grafting of sub-trees can be triggered in parallel once the 2. The grafting of sub-trees can be triggered in parallel once the
skipping to change at page 18, line 25 skipping to change at page 18, line 33
(Section 10.6 of [RFC5440]). (Section 10.6 of [RFC5440]).
PCEP operates over TCP, so it is also important to secure the PCE and PCEP operates over TCP, so it is also important to secure the PCE and
PCC against TCP denial of service attacks. Section 10.7.1 of PCC against TCP denial of service attacks. Section 10.7.1 of
[RFC5440] outlines a number of mechanisms for minimizing the risk of [RFC5440] outlines a number of mechanisms for minimizing the risk of
TCP-based denial of service attacks against PCEs and PCCs. TCP-based denial of service attacks against PCEs and PCCs.
PCEP implementations SHOULD also consider the additional security PCEP implementations SHOULD also consider the additional security
provided by the TCP Authentication Option (TCP-AO) [RFC5925]. provided by the TCP Authentication Option (TCP-AO) [RFC5925].
Finally, any multi-domain operation necessarily involves the exchange
of information across domain boundaries. This may represent a
significant security and confidentiality risk especially when the
domains are controlled by different commercial entities. PCEP
allows individual PCEs to maintain confidentiality of their domain
path information by using path-keys [RFC5520] and would allow for
securing of domain path information when performing core-tree
based path computations.
11. IANA Considerations 11. IANA Considerations
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry with the "RP Object Flag Field" sub-registry. registry with the "RP Object Flag Field" sub-registry.
IANA is requested to allocate a new bit from this registry as IANA is requested to allocate a new bit from this registry as
follows: follows:
Bit Description Reference Bit Description Reference
TBA Core-tree computation (C-bit) [This.I-D] TBA Core-tree computation (C-bit) [This.I-D]
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi
Komolafe, Oscar Gonzalez de Dios and Julien Meuric for their Komolafe, Oscar Gonzalez de Dios and Julien Meuric for their
valuable comments on this document. valuable comments on this document.
13. References 13. References
skipping to change at page 19, line 13 skipping to change at page 19, line 29
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation
Element (PCE) Communication Protocol (PCEP)", Element (PCE) Communication Protocol (PCEP)",
RFC 5440, March 2009. RFC 5440, March 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC) "A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter- Procedure to Compute Shortest Constrained Inter-
Domain Traffic Engineering Label Switched Paths", Domain Traffic Engineering Label Switched Paths",
RFC 5441, April 2009. RFC 5441, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali,
Z., and J. Meuric, "Extensions to the Path Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
for Point-to-Multipoint Traffic Engineering Label for Point-to-Multipoint Traffic Engineering Label
Switched Paths", RFC 6006, September 2010. Switched Paths", RFC 6006, September 2010.
13.2. Informative References 13.2. Informative References
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Multipoint Traffic-Engineered MPLS Label Switched
 End of changes. 27 change blocks. 
55 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/