Internet Engineering Task Force Q. Zhao, Ed.
Internet-Draft Huawei Technology
Intended Status: Standards Track Daniel King, Ed.
Created: March 24, 2010 Old Dog Consulting
Expires: September 24, 2010
Extensions to the Path Computation Element Communication Protocol
(PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-p2mp-extensions-08.txt
Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs.
This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of 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 September 24, 2010.
Zhao, King, et al. [Page 1]
Internet-Draft September 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. 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.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5
3. Protocol Procedures and Extensions . . . . . . . . . . . . . .6
3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .6
3.1.1. P2MP Computation TLV in the Existing PCE Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . .6
3.1.2. Open Message Extension . . . . . . . . . . . . . . . .6
3.2. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7
3.3. P2MP Path Computation Request/Reply Message Extensions . .8
3.3.1. The Extension of the RP Object . . . . . . . . . . . .8
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .9
3.4. Request Message Format . . . . . . . . . . . . . . . . . .11
3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .12
Zhao, King, et al. [Page 2]
Internet-Draft September 2010
3.6. P2MP Objective Functions and Metric Types . . . . . . . .13
3.6.1. New Objective Functions . . . . . . . . . . . . . . .13
3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .14
3.8. Non-Support by Back-Level PCE Implementations. . . . . . .14
3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .14
3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .15
3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .18
3.11.1 Branch Node Object . . . . . . . . . . . . . . . . . .18
3.12. Synchronization of P2MP TE Path Computation Requests . . .19
3.13. Request and Response Fragmentation . . . . . . . . . . . .20
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .20
3.13.2 Response Fragmentation Procedure . . . . . . . . . . .20
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .20
3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .21
3.15. P2MP PCEP Error Object and Types . . . . . . . . . . . . .22
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .23
4. Manageability Considerations . . . . . . . . . . . . . . . . .23
4.1. Control of Function and Policy . . . . . . . . . . . . . .23
4.2. Information and Data Models . . . . . . . . . . . . . . .24
4.3. Liveness Detection and Monitoring . . . . . . . . . . . .24
4.4. Verifying Correct Operation . . . . . . . . . . . . . . .24
4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . .24
4.6. Impact on Network Operation . . . . . . . . . . . . . . .24
5. Security Considerations . . . . . . . . . . . . . . . . . . .24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .25
6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .25
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25
6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .26
6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27
7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .27
8.1. Normative References . . . . . . . . . . . . . . . . . . .27
8.2. Informative References . . . . . . . . . . . . . . . . . .29
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .29
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .29
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .30
Zhao, King, et al. [Page 3]
Internet-Draft September 2010
1. Introduction
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 point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE has been identified as a suitable application for the
computation of paths for P2MP TE LSPs [RFC5671].
The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path
computation of P2MP TE LSPs.
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
These S2L sub-LSPs are set up between ingress and egress LSRs and are
appropriately overlaid to construct a P2MP TE LSP. During path
computation, the P2MP TE LSP may be determined as a set of S2L sub-
LSPs that are computed separately and combined to give the path of
the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
tree in a single computation.
This document relies on the mechanisms of PCEP to request path
computation for P2MP TE LSPs. One path computation request message
from a PCC may request the computation of the whole P2MP TE LSP, or
the request may be limited to a sub-set of the S2L sub-LSPs. In the
extreme case, the PCC may request the S2L sub-LSPs to be computed
individually with it being the PCC's responsibility to decide whether
to signal individual S2L sub-LSPs or combine the computation results
to signal the entire P2MP TE LSP. Hence the PCC may use one path
computation request message or may split the request across multiple
path computation messages.
1.1 Terminology
Terminology used in this document.
TE LSP: Traffic Engineered Label Switched Path.
LSR: Label Switching Router.
Zhao, King, et al. [Page 4]
Internet-Draft September 2010
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 for the synchronized computation of a set of paths
(e.g., aggregate bandwidth consumption minimization).
P2MP: Point-to-Multipoint.
P2P: Point-to-Point.
This document also uses the terminology defined in [RFC4655],
[RFC4875], and [RFC5440].
2. Requirements
This section summarizes the PCC-PCE Communication Requirements for
P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system
corresponds to the requirement numbers used in [PCE-P2MP-REQ].
1. Indication of P2MP Path Computation Request.
2. Indication of P2MP Objective Functions.
3. Non-Support of P2MP Path Computation.
4. Non-Support by Back-Level PCE Implementations.
5. Specification of Destinations.
6. Indication of P2MP Paths.
7. Multi-Message Requests and Responses.
8. Non-Specification of Per-Destination Constraints and Parameters.
9. Path Modification and Path Diversity.
10. Reoptimization of P2MP TE LSPs.
11. Addition and Removal of Destinations from Existing Paths.
12. Specification of Applicable Branch Nodes.
13. Capabilities Exchange.
14. Path-Tree Diversity.
Zhao, King, et al. [Page 5]
Internet-Draft September 2010
3. Protocol Procedures and Extensions
The following section describes the protocol extensions required to
satisfy the requirements specified in the Requirements section
(Section 2) of this document.
3.1. P2MP Capability Advertisement
3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an an OSPF
Router Information LSA defined in [RFC4970] to facilitate PCE
discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be
added to the PCED TLV, so this document defines a new flag in the
PCE-CAP-FLAGS sub-TLV of the PCED TLV to indicate the capability of
P2MP computation.
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
Discovery using IS-IS. This document defines a new flag in the
PCE-CAP-FLAGS sub-TLV of the PCED sub-TLV to indicate the capability
of P2MP computation.
The PCE-CAP-FLAGS sub-TLV uses a common codepoint registry for OSPF
and IS-IS PCE discovery.
PCEs wishing to advertise that they support P2MP path computation set
bit 10 (TBA by IANA) in the PCE-CAP-FLAGS sub-TLV. PCCs that do not
understand this bit will ignore it (per [RFC5088] and [RFC5089]).
PCEs that do not support P2MP will leave the bit clear (per the
default behavior defined in [RFC5088] and [RFC5089]).
PCEs that set the bit to indicate support of P2MP path computation
MUST follow the procedures in Section 3.1.2 to further qualify the
level of support
3.1.2. Open Message Extension
Based on the Capabilities Exchange requirement described in
[PCE-P2MP-REQ], if a PCE does not advertise its P2MP capability
during discovery, PCEP should be used to allow a PCC to discover
which PCEs are capable of supporting P2MP path computation.
To satisfy this requirement, we extend the PCEP OPEN object by
defining a new optional TLV to indicate the PCE's capability to
perform P2MP path computations.
Zhao, King, et al. [Page 6]
Internet-Draft September 2010
The TLV type number is TBA by IANA. The length value is 2 bytes.
The value field is set to default value 0.
The inclusion of this TLV in an OPEN object indicates that the sender
can perform P2MP path computations.
Note that the capability TLV is meaningful only for a PCE so it will
typically appear only in one of the two Open messages during PCE
session establishment. However, in case of PCE cooperation (e.g.,
inter-domain), when a PCE behaving as a PCC initiates a PCE session
it SHOULD also indicate its path computation capabilities.
3.2. Efficient Presentation of P2MP LSPs
When specifying additional leaves, or optimizing existing P2MP TE
LSPs as specified in [PCE-P2MP-REQ], it may be necessary to pass
existing P2MP LSP route information between the PCC and PCE in the
request and reply message. In each of these scenarios, we need new
path objects for efficiently passing the existing P2MP LSP between
the PCE and PCC.
We specify the use of the Reservation Protocol Traffic Engineering
Extensions (RSVP-TE)Explicit Route Object (ERO) to encode the
explicit route of a TE LSP through the network. PCEP ERO sub-object
types correspond to RSVP-TE ERO sub-object types. The format and
content of the ERO object are defined in [RFC3209] and [RFC3473].
The Secondary Explicit Route Object (SERO) is used to specify the
explicit route of a S2L sub-LSP. The path of each subsequent S2L
sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO.
The format of the SERO is the same as an ERO defined in [RFC3209]
and [RFC3473].
The Secondary Recorded Route Object (SRRO) is used to record
the explicit route of the S2L sub-LSP. The class of the P2MP SRRO
is the same as the SRRO defined in [RFC4873].
The SERO and SRRO are used to report the route of an existing TE
LSP for which a reoptimization is desired. The format and content
of the SERO and SRRO are defined in [RFC4875].
A new PCEP object class and type are requested for SERO and SRRO.
Object-Class Value 26
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference This.I-D
Zhao, King, et al. [Page 7]
Internet-Draft September 2010
Object-Class Value 27
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference This.I-D
The request is referenced in the IANA Considerations section of this
document.
Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO.
3.3. P2MP Path Computation Request/Reply Message Extensions
This document extends the existing P2P RP (Request Parameters) object
so that a PCC can signal a P2MP path computation request to the PCE
receiving the PCEP request. The END-POINT object is also extended
to improve the efficiency of the message exchange between PCC and PCE
in the case of P2MP path computation.
3.3.1. The Extension of the RP Object
The PCE path computation request and reply message will need the
following additional parameters to allow a receiving PCE to
identify that the request and reply message has been fragmented
across multiple messages, has been requested for a P2MP path and to
specify if the route is represented in the compressed or uncompressed
format.
The F bit is added to the flag bits of the RP object to indicate
to the receiver that the request is part of a fragmented request, or
is not a fragmented request.
The N 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 P2MP or
not.
The E bit is added in the flag bits field of the RP object to signal
the receiver of the message that the route is in the compressed
format or not. By default, the path returned by the PCE will use the
compressed format.
Zhao, King, et al. [Page 8]
Internet-Draft September 2010
This document adds the following flags to the RP Object:
o F ( RP fragmentation bit - 1 bit):
0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver
needs to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0.
o N ( P2MP bit - 1 bit):
0: This indicates that this is not PCReq/PCRep for P2MP.
1: This indicates that this is PCReq or PCRep message for P2MP.
o E ( ERO-compression bit - 1 bit):
0: This indicates that the route is not in the compressed
format.
1: This indicates that the route is in the compressed format.
The IANA request is referenced in Section 6.2 of this document.
3.3.2. The New P2MP END-POINTS Object
To represent the end points for a P2MP path efficiently, we define a
new type of end-points object for the P2MP path.
With the new END-POINTS object, the PCE path computation request
message is expanded in a way which allows a single request
message to list multiple destinations.
There are 4 types of leaves in a P2MP request:
o New leaves to add;
o Old leaves to remove;
o Old leaves whose path can be modified/reoptimized;
o Old leaves whose path must be left unchanged.
A given END-POINTS object gathers the leaves of a given type. The
type of leaf in a given END-POINTS object is identified by the END-
POINTS object leaf type field.
Four values are possible for the leaf type field:
Zhao, King, et al. [Page 9]
Internet-Draft September 2010
1. New leaves to add;
2. Old leaves to remove;
3. Old leaves whose path can be modified/reoptimized;
4. Old leaves whose path must be left unchanged.
With the new END-POINTS object, the END-POINTS portion of a request
message for the multiple destinations can be reduced by up to 50% for
a P2MP path where a single source address has a very large number of
destinations.
Note that a P2MP path computation request can mix the different types
of leaves by including several END-POINTS object per RP object as
shown in the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format
in following Request Message Formats section (Section 3.4).
The format of the new END-POINTS object body for IPv4 (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The New P2MP END-POINTS Object Body Format for IPv4
Zhao, King, et al. [Page 10]
Internet-Draft September 2010
The format of the END-POINTS object body for IPv6 (Object-Type 4) 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 IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The New P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length. These are multiples
of 4 bytes for IPv4, and multiples of 16 bytes for IPv6.
3.4. Request Message Format
The PCReq message is encoded as follows using RBNF as defined in
[RFC5511].
Below is the message format for the request message:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
Zhao, King, et al. [Page 11]
Internet-Draft September 2010
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 3: The Message Format for the Request Message
Note we preserve compatibility with the [RFC5440] definition of
<request>. At least one instance of <endpoints> must be present
in this definition.
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
3.5. Reply Message Format
The PCReq message is encoded as follows using RBNF as defined in
[RFC5511].
Below is the message format for the reply message:
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Figure 4: The Message Format for the Reply Message
The optional END-POINTS in the reply message is used to specify which
paths are removed, changed, not changed, or added for the request.
The path is only needed for the end points which are added or
changed.
Zhao, King, et al. [Page 12]
Internet-Draft September 2010
If the E bit (ERO-Compress bit) was set to 1 in the request then the
path will be formed by an ERO followed by a list of SEROs.
Note that we preserve compatibility with the [RFC5440] definition of
<response> and the optional <end-point-pair-list> and <path>.
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
3.6. P2MP Objective Functions and Metric Types
3.6.1. New Objective Functions
Six objective functions have been defined in [RFC5541] 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 or to the TE metric used as the default metric when
the metric is not specified. (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 or to the
TE metric used as the default metric when the metric is not
specified.
Processing these two new objective functions is subject to the rules
defined in [RFC5541].
3.6.2. New Metric Object Types
There are three types defined for the <METRIC> object in [RFC5440],
namely, the IGP metric, the TE metric and the Hop Count metric. This
document defines three additional 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:
Zhao, King, et al. [Page 13]
Internet-Draft September 2010
o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA)
o P2MP TE metric: T=9 (suggested value, to be assigned by IANA)
o P2MP hop count metric: T=10 (suggested value, to be assigned by
IANA)
3.7. Non-Support of P2MP Path Computation.
o If a PCE receives a P2MP path request and it understands the P2MP
flag in the RP object, but the PCE is not capable of P2MP
computation, the PCE MUST send a PCErr message with a PCEP-ERROR
Object and corresponding Error-Value. The original P2MP path
computation request MUST then be cancelled. New Error-Types and
Error-Values are requested in the IANA Considerations section of
this document.
o If the PCE does not understand the P2MP flag in the RP object,
then the PCE MUST send a PCErr message with a new error type
"Unknown RP flag".
3.8. Non-Support by Back-Level PCE Implementations.
If a PCC inadvertently sends a P2MP request to a PCE which does not
support P2MP path computation and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request.
3.9. P2MP TE Path Reoptimization Request
A reoptimization request for a P2MP TE path is specified by the use
of the R bit within the RP object as defined in [RFC5440] and is
similar to the reoptimization request for a P2P TE path. The only
difference is that the user must insert the list of RROs and SRROs
after each type of END-POINTS in the PCReq message, as described in
the Request Message Format section (Section 3.4) of this document.
An example of a reoptimization request and subsequent PCReq message
is described below:
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 3
RRO list
OF (optional)
Figure 6: PCReq Message Example 1 for Optimization
Zhao, King, et al. [Page 14]
Internet-Draft September 2010
In this example, we request reoptimization of the path to all leaves
without adding or pruning leaves. The reoptimization request would
use an END-POINT type 3. The RRO list would represent the P2MP LSP
before the optimization and the modifiable path leaves would be
indicated in the END-POINTS object.
It is also possible to specify specific leaves whose path cannot
be modified. An example of the PCReq message in this scenario would
be:
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 7: PCReq Message Example 2 for Optimization
A P2MP reoptimization request could contain a parameter that allows
the PCC to express a cost-benefit reoptimization threshold for the
whole LSP as well as per destination. This function would be set by
the local PCC and subject to the PCE policy [RFC5394]. This
specification does not provide a mechanism to address this threshold
function. The function may be addressed in a future document.
3.10. Adding and Pruning Leaves to the P2MP Tree
When adding new leaves or removing old leaves to the existing P2MP
tree, by supplying a list of existing leaves, it SHOULD be possible
to optimize the existing P2MP tree. This section explains the
methods to add new leaves or remove old leaves to the existing
P2MP tree.
To add new leaves the user must build a P2MP request using
END-POINTS with leaf type 1.
To remove old leaves the user must build a P2MP request using
END-POINTS with leaf type 2.
The PCC must also provide the list of old leaves and indicate if
they should be reoptimized or not by including END-POINTS with leaf
type 3, leaf type 4 or both. The error values when the conditions
are not satisfied (i.e., when there is no END-POINTS with leaf type
3 or 4, in the presence of END-POINTS with leaf type 1 or 2), are
documented in the IANA Considerations section (Section 6) of this
document.
Zhao, King, et al. [Page 15]
Internet-Draft September 2010
For old leaves the user must provide the old path as a list of RROs
that immediately follows each END-POINTS object. This document
specifies error values when specific conditions are not satisfied.
The following examples demonstrate full and partial reoptimization
of existing P2MP LSPs:
Case 1: Adding leaves with full reoptimization of existing paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)
Figure 8: Adding Leaves with Full Reoptimization
Case 2: Adding leaves with partial reoptimization of existing paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 9: Adding Leaves with Partial Reoptimization
Case 3: Adding leaves without reoptimization of existing paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 10: Adding Leaves without Reoptimization
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)
Figure 11: Pruning Leaves with Full Reoptimization
Zhao, King, et al. [Page 16]
Internet-Draft September 2010
Case 5: Pruning leaves with partial reoptimization of existing paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 12: Pruning Leaves with Partial Reoptimization
Case 6: Pruning leaves without reoptimization of existing paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 13: Pruning Leaves without Reoptimization
Case 7: Adding and pruning leaves full reoptimization of existing
paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)
Figure 14: Adding and Pruning Leaves full Reoptimization
Case 8: Adding and pruning leaves with partial reoptimization of
existing paths
Zhao, King, et al. [Page 17]
Internet-Draft September 2010
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 15: Adding and Pruning Leaves with Partial
Reoptimization
Case 9: Adding and pruning leaves without reoptimization of existing
paths
Common Header
RP with P2MP flag/R bits set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 16: Adding and Pruning Leaves without Reoptimization
3.11. Discovering 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 capabilities by using the mechanisms defined in
[RFC5073].
3.11.1 Branch Node Object
The PCC can specify a list of nodes that can be used as branch
nodes or a list of nodes that cannot be used as branch nodes by
using the a BRANCH NODE Capability (BNC) Object. The BNC Object has
the same format as the IRO object defined in [RFC5440] except that
it only supports IPv4 and IPv6 prefix sub-objects. Two Object-
types are also defined:
o Branch node list: List of nodes that can be used as branch
nodes.
o Non-branch node list: List of nodes that cannot be used as branch
nodes.
Zhao, King, et al. [Page 18]
Internet-Draft September 2010
The object can only be carried in a PCReq message. A Path Request
may carry at most one BRANCH NODE Object.
The Object-Class and Object-types will need to allocated by IANA. The
IANA request is documented in Section 6.5.
3.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs computations need to be
synchronized. For example, one P2MP LSP is the designated backup of
another P2MP LSP. In this case, path diversity for these dependent
LSPs may need to be considered during the path computation.
The synchronization can be done by just using the existing SVEC
functionality.
An example of synchronizing two P2MP LSPs, each has two leaves for
Path Computation Request Messages is illustrated as below:
Common Header
SVEC for sync of LSP1 and LSP2
OF (optional)
END-POINTS1 for P2MP
RRO1 list
END-POINTS2 for P2MP
RRO2 list
Figure 17: PCReq Message Example for Synchronization
This specification also defines two new flags to the SVEC object
for P2MP path dependent computation requests. The first new flag is
to allow the PCC to request that the PCE should compute a secondary
P2MP pathtree with partial path diversity for specific leaves or a
specific S2L sub-path to the primary P2MP path tree. The second flag,
would allow the PCC to request that partial paths should be link
direction diverse.
The following flags are added to the SVEC object body in this
document:
o P ( Partial Path Diversity bit - 1 bit):
When set this would indicate a request for path diversity
for a specific leaf, a set of leaves or all leaves.
o D ( Link Direction Diverse bit - 1 bit):
When set this would indicate a request that a partial path or
paths should be link direction diverse.
The IANA request is referenced in Section 6.2 of this document.
Zhao, King, et al. [Page 19]
Internet-Draft September 2010
3.13. Request and Response Fragmentation
The total PCEP message-length, including the common header, is 16
bytes. In certain scenarios the P2MP computation request may not fit
into a single request or response message. For example, if a tree has
many hundreds or thousands of leaves. Then the request or response
may need to be fragmented into multiple messages.
The F bit has been outlined in the Extension of the RP Object section
(Section 3.3.1) of this document. The F bit is used in the RP object
header to signal that the initial request or response was too large
to fit into a single message and will be fragmented into multiple
messages. In order to indentify the single request or response, each
message will use the same request ID.
3.13.1 Request Fragmentation Procedure
If the initial request is too large to fit into a single request
message the PCC will split the request over multiple messages. Each
message sent to the PCE, except the last one, will have the F bit set
in the RP object to signify that the request has been fragmented
into multiple messages. In order to indentify that a series of
request messages represents a single request, each message will
use the same request ID.
The assumption is that request messages are reliably delivered
and in sequence since PCEP relies on TCP.
3.13.2 Response Fragmentation Procedure
Once the PCE computes a path based on the initial request, a response
is sent back to the PCC. If the response is too large to fit into a
single response message the PCE will split the request over multiple
messages. Each message sent to the PCE, except the last one, will
have the F bit set in the RP object to signify that the response
has been fragmented into multiple messages. In order to identify
that a series of response messages represents a single request,
each message will use the same request ID.
Again, the assumption is that response messages are reliably
delivered and in sequence since PCEP relies on TCP.
3.13.3 Fragmentation Examples
The following example illustrates the PCC sending a request message
with Req-ID1 to the PCE, in order to add one leaf to an existing tree
with 1200 leaves. The assumption is that the one request message can
hold up to 800 leaves. In this scenario, the original single message
needs to be fragmented and sent using two smaller messages, which
have the Req-ID1 specified in the RP object, and with the F bit set on
the first message.
Zhao, King, et al. [Page 20]
Internet-Draft September 2010
Common Header
RP1 with Req-ID1 and P2MP flag and F bit set
OF (optional)
END-POINTS1 for P2MP
RRO1 list
Common Header
RP2 with Req-ID1 and P2MP flag and F bit cleared
OF (optional)
END-POINTS1 for P2MP
RRO1 list
Figure 18: PCReq Message Fragmentation Example
To handle the scenario that the last fragmented message piece is
lost, the receiver side of the fragmented message may start a timer
once it receives the first piece of the fragmented message. When
the timer expires and it has not received the last piece of the
fragmented message, it should send an error message to the sender
to signal that it has received an incomplete message.
3.14. UNREACH-DESTINATION Object
The PCE path computation request may fail because all or a subset of
the destinations are unreachable.
In such a case, the UNREACH-DESTINATION object allows the PCE to
optionally specify the list of unreachable destinations.
This object can be present in PCRep messages. There can be up to one
such object per RP.
The following UNREACH-DESTINATION objects will be required:
UNREACH-DESTINATION Object-Class is to be assigned by IANA.
UNREACH-DESTINATION Object-Type for IPv4 is to be assigned by IANA
UNREACH-DESTINATION Object-Type for IPv6 is to be assigned by IANA.
The format of the UNREACH-DESTINATION object body for IPv4 (Object-
Type=1) is as follows:
Zhao, King, et al. [Page 21]
Internet-Draft September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: UNREACH-DESTINATION Object Body for IPv4
The format of the UNREACH-DESTINATION object body for IPv6 (Object-
Type=2) 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 IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: UNREACH-DESTINATION Object Body for IPv6
3.15. P2MP PCEP Error Objects and Types
To indicate errors associated with the P2MP path request, a new
Error-Type (16) and subsequent error-values are defined as follows
for inclusion in the PCEP-ERROR object:
Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path
request and the PCE is not capable to satisfy the request due to
insufficient memory, the PCE MUST send a PCErr message with a PCEP
ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The
corresponding P2MP path computation request MUST also be cancelled.
Zhao, King, et al. [Page 22]
Internet-Draft September 2010
Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request
and the PCE is not capable of P2MP computation, the PCE MUST send a
PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error-
Value (Error-Value=2). The corresponding P2MP path computation
request MUST be also cancelled.
To indicate an error associated with policy violation, a new error
value "P2MP Path computation not allowed" should be added to the
existing error code for policy violation (Error-Type=5) as defined
in [RFC5440]:
Error-Type=5; Error-Value=6: if a PCE receives a P2MP path
computation request which is not compliant with administrative
privileges (i.e., "The PCE policy does not support P2MP path
computation"), the PCE MUST send a PCErr message with a PCEP-ERROR
Object (Error-Type=5) and an Error-Value (Error-Value=6). The
corresponding P2MP path computation request MUST also be cancelled.
3.16. PCEP NO-PATH Indicator
To communicate the reasons for not being able to find P2MP path
computation, the NO-PATH object can be used in the PCRep message.
One new bit is defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object:
0x24: when set, the PCE indicates that there is a reachability
problem with all or a subset of the P2MP destinations. Optionally
the PCE can specify the destination or list of destinations that are
not reachable using the new UNREACH-DESTINATION object defined in
section 3.6.
4. 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.
4.1. Control of Function and Policy
In addition to configuration parameters listed in [RFC5440], the
following parameters MAY be required.
Zhao, King, et al. [Page 23]
Internet-Draft September 2010
o P2MP path computations enabled or disabled.
o Advertisement of P2MP path computation capability enabled or
disabled (discovery protocol, capability exchange).
4.2. Information and Data Models
As described in [PCE-P2MP-REQ], MIB objects MUST be supported for
PCEP extensions specified in this document.
4.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.
4.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements.
4.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.
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) can be used to
advertise capabilities to PCCs. A new flag (value=10) could be
defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation
capability. Extensions for PCE discovery are out of scope of this
document.
4.6. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document
does not have significant impact on network operations.
5. 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, King, et al. [Page 24]
Internet-Draft September 2010
6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this
document. IANA is requested to make the following allocations.
6.1 P2MP Capability TLV
As described in Section 3.1.2, the newly defined P2MP capability TLV
allows the PCE to advertize its P2MP path computation capability.
IANA is requested to make the following allocation from the "PCEP
TLV Type Indicators" sub-registry.
Value Description Reference
6 P2MP capability This.I-D
6.2 Request Parameter Bit Flags
As described in Section 3.3.1., three new RP Object Flags have
been defined. IANA is requested to make the following allocations
from the "RP Object Flag Field" Sub-Registry:
Bit Description Reference
18 Fragmentation(F-bit) This.I-D
19 P2MP (N-bit) This.I-D
20 ERO-compression (E-bit) This.I-D
6.3 Objective Functions
As described in Section 3.6.1., two new Objective Functions have been
defined. IANA is requested to make the following allocations from the
"Objective Function" sub-registry:
Code Point Name Reference
7 SPT This.I-D
8 MCT This.I-D
6.4 Metric Object Types
As described in Section 3.6.2., three new metric object T fields have
been defined. IANA is requested to make the following allocations
from the "METRIC Object T Field" sub-registry:
Value Description Reference
8 P2MP IGP metric This.I-D
9 P2MP TE metric This.I-D
10 P2MP hop count metric This.I-D
Zhao, King, et al. [Page 25]
Internet-Draft September 2010
6.5 PCEP Objects
As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have
been defined. IANA is requested to make the following allocations
from the "PCEP Objects" sub-registry
Object-Class Value 25
Name UNREACH-DESTINATION
Object-Type 1: IPv4
2: IPv6
3-15: Unassigned
Reference This.I-D
Object-Class Value 26
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference This.I-D
Object-Class Value 27
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference This.I-D
Object-Class Value 28
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference This.I-D
6.6 PCEP Error Objects and Types
As described in Section 3.15., a number of new PCEP-ERROR Object
Error Types and Values have been defined. IANA is requested to
make the following allocations from the "PCEP-ERROR Object Error
Type and Value" sub-registry:
Error
Type Meaning Reference
5 Policy violation
Error-value=6: This.I-D
P2MP Path computation is not allowed
Zhao, King, et al. [Page 26]
Internet-Draft September 2010
16 P2MP Error This.I-D
Error-Value=0: Unassigned
Error-Value=1: This.I-D
The PCE is not capable to satisfy the request
due to insufficient memory
Error-Value=2: This.I-D
The PCE is not capable of P2MP computation
17 P2MP Error This.I-D
Error-Value=0: Unassigned
Error-Value=1: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 2
Error-Value=2: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3
Error-Value=3: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4
6.7 PCEP NO-PATH Indicator
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field
has been defined. IANA is requested to make the following
allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry:
Bit Description Reference
24 P2MP Reachability Problem This.I-D
7. Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh
Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas
Manral for their valuable comments and input on this draft.
8. References
8.1. Normative References
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
Zhao, King, et al. [Page 27]
Internet-Draft September 2010
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007
[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.
[RFC4970] Lindem A., et al.
"Extensions to OSPF for Advertising Optional Router
Capabilities', RFC 4970, July 2007
[RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node
Capabilities", RFC 5073, December 2007.
[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., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5541]
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
Functions in the Path Computation Element Communication
Protocol (PCEP)", RFC5541, December 2008.
Zhao, King, et al. [Page 28]
Internet-Draft September 2010
8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[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.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008.
9. Authors' Addresses
Quintin Zhao (editor)
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
Daniel King (editor)
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Fabien Verhaeghe
Thales Communication France
160 Bd Valmy 92700 Colombes
France
Email: fabien.verhaeghe@gmail.com
Tomonori Takeda
NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585
Japan
Email: takeda.tomonori@lab.ntt.co.jp
Zhao, King, et al. [Page 29]
Internet-Draft September 2010
Zafar Ali
Cisco systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: zali@cisco.com
Julien Meuric
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex,
julien.meuric@orange-ftgroup.com
9.1 Contributors
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex,
France
Email: jeanlouis.leroux@orange-ftgroup.com
Mohamad Chaitou
France
Email: mohamad.chaitou@gmail.com
Appendix A. RBNF Code Fragments
This appendix contains the full set of code fragments defined in this
document.
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
Zhao, King, et al. [Page 30]
Internet-Draft September 2010
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Below is the message format for the request message:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Below is the message format for the reply message:
Below is the message format for the reply message:
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
Zhao, King, et al. [Page 31]
Internet-Draft September 2010
where:
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::=(ERO)|(SERO)|<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]