Internet DRAFT - draft-chaitou-pce-p2mp-ext
draft-chaitou-pce-p2mp-ext
Network Working Group M. Chaitou
Internet Draft J.L. Le Roux
Intended status: Standard Track France Telecom
Expires: August 2008 Zafar Ali
Cisco Systems
February 18, 2008
Path Computation Element communication Protocol (PCEP) Extensions
for Point to Multipoint Label Switched Paths (LSPs)
draft-chaitou-pce-p2mp-ext-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 1]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
Abstract
The Path Computation Element communication Protocol (PCEP) enables
computing point-to-point Traffic Engineered (TE) paths in Multi Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
This document describes extensions to PCEP in order to support the
computation of point-to-multipoint (P2MP) Traffic Engineered (TE) paths.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Terminology....................................................3
2. Introduction...................................................3
3. PCEP extensions................................................4
3.1. PCReq message format......................................4
3.2. PCRep message format......................................5
3.3. New SVEC object flag......................................5
3.3.1. Elements of procedure................................6
3.4. Objective functions.......................................6
3.5. New metric object types...................................7
3.6. P2MP TE path re-optimization request......................7
3.6.1. The Non-Modifiable Path flag.........................7
3.7. Adding/pruning leaves.....................................8
3.8. Branch nodes..............................................8
3.9. Route compression indication..............................8
3.10. Synchronization of P2MP TE path computation requests.....8
4. Security considerations........................................8
5. IANA considerations............................................9
6. References.....................................................9
7. Author's Addresses:...........................................10
8. Intellectual Property Statement...............................10
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 2]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
1. Terminology
Terminology used in this document
TE LSP: Traffic Engineered Label Switched Path.
LSR: Label Switch Router.
OF: Objective Function: A set of one or more optimization criterion
(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, etc.).
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 (component, application, or
network node) that is capable of computing a network path or route
based on a network graph, and applying computational constraints.
PCEP: Path Computation Element communication Protocol.
P2MP: Point-to-MultiPoint.
P2P: Point-to-Point.
2. Introduction
The Path Computation Element defined in [RFC4655] is an entity capable
of computing TE LSP paths based on a network graph, and applying
computational constraints. A PCE serves path computation requests sent
by Path Computation Clients (PCC).
The PCE communication Protocol (PCEP), defined in [PCEP], allows for
communication between a PCC and a PCE or between two PCEs, in compliance
with requirements and guidelines set forth in [RFC4657]. Such
interactions include path computation requests and path computation
replies.
At present, PCEP supports P2P TE path computations. As mentioned in
[PCE-P2MP-REQ], it may be useful to rely on one or more PCE for the
computation of P2MP paths, for the same reasons as for P2P path, that is
to handle complex P2MP computations as well as to support inter domain
P2MP computation.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 3]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
To address the above mentioned requirement of P2MP path computation in
[P2MP-PCE-REQ], this document defines extensions to PCEP [PCEP].
Specifically, the format of PCReq and PCRep messages is extended to
support P2MP path computation requests and replies.
Two new objective functions are defined for trees, namely SPT (Shortest
Path Tree) and MCT (Minimum Cost Tree), which define the optimization
criteria that may apply when computing a tree. Also three new metric
types are defined in order to indicate the cost of a tree.
3. PCEP extensions
This section defines extensions to PCEP ([PCEP]) so as to support the
communication of P2MP path computation requests and replies.
In order to minimize extensions to PCEP and maximize backward
compatibility, a P2MP request is represented as a synchronized set of
P2P path requests from the root to each leaf following synchronization
procedures defined in [PCEP]. For that purpose a new synchronization
flag, the P2MP flag is defined.
In order to request the computation of a P2MP path towards a set of
leaves the PCC will issue one or more PCReq message including a set of
P2P path requests towards each leaf synchronized using the SVEC object,
with a new flag indicating P2MP synchronization.
3.1. PCReq message format
A request for a P2MP path computation is built as a synchronized set of
P2P path request from the root to each leaf. The TE constraints and
objective function MUST directly follow the SVEC object, and MUST NOT
repeated for each elementary request.
The PCReq message for a particular P2MP path computation request has the
following format:
<PCReq Message>::= <Common Header>
<SVEC>
[<BANDWIDTH>]
[<LSPA>]
[OF]
[<metric-list>]
[<LOAD-BALANCING>]
<request-list>
where:
<request-list>::=<request>[<request-list>]
<request>::= <RP>
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 4]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
<END-POINTS>
[<RRO>]
[<IRO>]
[<metric-list>]
where:
<metric-list>::=<METRIC>[<metric-list>]
Note that a P2MP request may be divided into multiple PCReq messages
following synchronization procedures defined in [PCEP].
3.2. PCRep message format
A PCRep message for a P2MP path is comprised of a set of synchronized
P2P replies including the P2P path towards each leaf.
The format of the PCRep message for a P2MP request is as follows:
<PCRep Message> ::= <Common Header>
<SVEC>
[<BANDWIDTH>]
[<LSPA>]
[OF]
[<metric-list>]
[<LOAD-BALANCING>]
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO>
[<metric-list>]
[<IRO>]
where:
<metric-list>::=<METRIC>[<metric-list>
3.3. New SVEC object flag
A new bit flag, referred to as the P2MP flag, is defined in the SVEC
object, so as to indicate within a PCReq message a request for a P2MP
path computation and within a PCRep message to indicate a reply for a
P2MP computation request.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 5]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
Note that the ability of a PCE to support P2MP TE path computation
requests may be dynamically discovered by the PCC(s) by means of PCE
capability discovery protocols [RFC5088], [RFC5089].
3.3.1. Elements of procedure
On receipt of a PCReq message with the P2MP flag in the SVEC object set,
the PCE has to proceed as follows:
o If the PCE understands the P2MP flag and supports computing P2MP
paths, then the PCE starts P2MP path computation.
o If the PCE understands the P2MP flag but does not support the
computation of P2MP paths, it must send a PCErr message with a new
error type "P2MP path computation not supported" (defined in this
document).
o If the PCE does not understand the P2MP flag then the PCE MUST
send a PCErr message with a new error type "Unknown SVEC flag"
(defined in this document).
3.4. Objective functions
Six objective functions have been defined in [PCE-OF] for P2P path
computation.
This document defines two additional objective functions, namely SPT
(Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP path
computation. Hence two new objective function codes have to be defined.
The description of the two new objective functions is as follows.
Objective Function Code: 7 (suggested value, to be assigned by IANA)
Name: Shortest Path Tree (SPT)
Description: Minimize the maximum source-to-leaf cost with respect to
a specific metric (e.g. TE or IGP metric)
Objective Function Code: 8 (suggested value, to be assigned by IANA)
Name: Minimum Cost Tree (MCT)
Description: Minimize the total cost of the tree, that is the sum of
the costs of tree links, with respect to a specific metric.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 6]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
Processing these two new objective functions is subject to the rules
defined in [PCE-OF].
3.5. New metric object types
There are three types defined for the <METRIC> object in [PCEP], namely,
the IGP metric, the TE metric and the hop count metric. This document
defines three other types for the <METRIC> object: the P2MP IGP metric,
the P2MP TE metric, and the P2MP Hop Count metric. They encode the sum
of the metrics of all links of the tree. We propose the following values
for these new metric types (to be assigned by IANA):
o P2MP IGP metric: T=4
o P2MP TE metric: T=5
o P2MP hop count metric: T=6
These three new metric objects MUST follow the SVEC object in a PCReq or
PCRep message and MUST not appear for each elementary P2P request (i.e.
they MUST not appear after a RP object).
3.6. P2MP TE path re-optimization request
A request for the re-optimization of a P2MP path is issued with a PCReq
message including all the P2P path requests towards each leaf with the R
bit set in the <RP> objects and the old P2P paths carried within the
<RROs>.
As indicated in [PCE-P2MP-REQ] it must be possible to indicate in a
request whether a P2P path towards a leaf can be modified or not and in
a response whether a P2P path has been modified or not. For that purpose
we introduce a new flag within the <RP> object.
3.6.1. The Non-Modifiable Path flag
A new flag of the <RP> object (specified in [PCEP]) is defined in this
document. The IANA is requested to make the following allocation
(suggested value):
Bit Hex Name Reference
Number
14 0x02000 NP (Non-modifiable Path) (this document)
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 7]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
When cleared within a PCReq message this indicates that the P2P path can
be modified and when cleared within a PCRep message this indicates that
the P2P path has been modified. When set in a PCReq message this
indicates that the P2P path cannot be modified, and when set within a
PCRep message this indicates that the P2P path has not been modified.
The flag is meaningful only if the R flag is set.
3.7. Adding/pruning leaves
To request the modification of an existing P2MP tree that includes new
leaves, the request message MUST include the set of new P2P path
requests with the R flag cleared in the <RP> objects as well as all the
existing P2P path requests with the R flag set in the <RP> objects with
the corresponding <RROs>.
If an existing P2P path must not be changed the NP bit MUST be set in
the corresponding <RP> object.
To request the modification of a P2MP tree that looses some leaves the
PCReq message MUST include only the set of P2P path requests
corresponding to the remaining leaves.
3.8. Branch nodes
Before computing the P2MP path, a PCE must be provided means to know
which nodes in the network are capable of acting as branch LSRs. A PCE
can discover such capability by using the mechanisms defined in [NODE-
CAP].
3.9. Route compression indication
To be completed.
3.10. Synchronization of P2MP TE path computation requests
It is possible to synchronize the computation of n, n>=2, P2MP path
requests by including in a PCReq messages (n+1) <SVEC> objects. Each of
the first n <SVEC> objects contains the request-id-numbers that
represent all the P2P paths that constitute one P2MP TE LSP. The last
<SVEC> object contains n request-id-numbers where each request-id-number
represents a P2P request belonging to a different P2MP path, following
procedures for hierarchical synchronization defined in [PCE-SVEC-LIST].
4. Security considerations
To be completed.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 8]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
5. IANA considerations
To be completed.
6. 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.-P., " A Path Computation Element
(PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J., Le Roux, J.L.," Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S. "Extensions to
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-
to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[NODE-CAP] Vasseur, J.-P., Le Roux, J.L., "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node Capabilities", RFC
5073, December 2007
[RFC5088] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R., "OSPF
Protocol Extensions for Path Computation Element (PCE) Discovery", RFC
5088, January 2008.
[RFC5089] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R., "IS-IS
Protocol Extensions for Path Computation Element (PCE) Discovery", RFC
5089, January 2008.
[PCEP] Vasseur, J.-P., Le Roux, J.L., "Path Computation Element (PCE)
communication Protocol (PCEP)", draft-ietf-pce-pcep, work in progress.
[PCE-P2MP-REQ] Yasukawa, S., "PCC-PCE Communication Requirements for
Point to Multipoint Multiprotocol Label Switching Traffic Engineering
(MPLS-TE)", draft-yasukawa-pce-p2mp-req, work in progress.
[PCE-OF] Le Roux, J.L., Vasseur, J.-P., Lee, Y. "Encoding of Objective
Functions in Path Computation Element (PCE) communication and discovery
protocols", draft-ietf-pce-of, work in progress.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 9]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
[PCE-SVEC-LIST] Nishioka, I., King, D., "The use of SVEC
(Synchronization VECtor) list for Synchronized dependent path
computations", draft-nishioka-pce-svec-list, work in progress.
7. Author's Addresses:
Mohamad Chaitou
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: Mohamad.Chaitou@orange-ftgroup.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: Jeanlouis.Leroux@orange-ftgroup.com
Zafar Ali
Cisco systems, Inc.,
2000 Innovation Drive
Kanata, Ontario
Canada K2K 3E8
Phone: 613 254 3498
Email: zali@cisco.com
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 10]
Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 11]
