draft-ietf-pce-pcep-p2mp-extensions-03.txt   draft-ietf-pce-pcep-p2mp-extensions-04.txt 
Internet Engineering Task Force Q. Zhao, Ed. Internet Engineering Task Force Q. Zhao, Ed.
Internet-Draft Huawei Technology Internet-Draft Huawei Technology
Intended Status: Standards Track Daniel King Intended Status: Standards Track Daniel King
Expires: January 12, 2009 Old Dog Consulting Expires: February 19, 2010 Old Dog Consulting
July 12, 2009 August 18, 2009
Extensions to the Path Computation Element Communication Protocol Extensions to the Path Computation Element Communication Protocol
(PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-p2mp-extensions-03.txt draft-ietf-pce-pcep-p2mp-extensions-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 6, 2009. This Internet-Draft will expire on January 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 22 skipping to change at page 2, line 22
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
be determined. The Path Computation Element (PCE) has been need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs. paths of P2MP TE LSPs.
This document describes extensions to the PCE communication Protocol This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of paths (PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs. for P2MP TE LSPs.
Requirements Language 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].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5
3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 3. Protocol Procedures and Extensions . . . . . . . . . . . . . .6
3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .6
3.1.1. Extend the TLV in the Existing PCE Discovery 3.1.1. Extend the TLV in the Existing PCE Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . . Protocol . . . . . . . . . . . . . . . . . . . . . . .6
3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 3.1.2. Open Message Extension . . . . . . . . . . . . . . . .6
3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . .7
3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 3.3. P2MP Path Computation Request/Reply Message Extensions . .7
3.3. Indication of P2MP Path Computation Request/Reply . . . . 3.3.1. The Extension of RP Object . . . . . . . . . . . . . .7
3.3.1. The Extension of RP Object . . . . . . . . . . . . . . 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .8
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 3.4. Request Message Formats . . . . . . . . . . . . . . . . .10
3.4. Request Message Formats . . . . . . . . . . . . . . . . . 3.5. Reply Message Formats . . . . . . . . . . . . . . . . . .11
3.5. Reply Message Formats . . . . . . . . . . . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . .12
3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6.1. New Object Functions . . . . . . . . . . . . . . . . .12
3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13
3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .13
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .13
3.8. Non-Support by Back-Level PCE Implementations. . . . . . . 3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . .13
3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . . 3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . .14
3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . 3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . .17
3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . 3.12. Synchronization of P2MP TE Path Computation Requests . . .17
3.12. Synchronization of P2MP TE Path Computation Requests . . . 3.13. Request and Response Fragmentation . . . . . . . . . . . .19
3.13. Request and Response Fragmentation . . . . . . . . . . . . 3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .19
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . . 3.13.2 Response Fragmentation Procedure . . . . . . . . . . .19
3.13.2 Response Fragmentation Procedure . . . . . . . . . . . 3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .19
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . . 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .20
3.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . 3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .21
3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .22
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 4. Manageability Considerations . . . . . . . . . . . . . . . . .22
4. Manageability Considerations . . . . . . . . . . . . . . . . . 4.1. Control of Function and Policy . . . . . . . . . . . . . .23
4.1. Control of Function and Policy . . . . . . . . . . . . . . 4.2. Information and Data Models . . . . . . . . . . . . . . .23
4.2. Information and Data Models . . . . . . . . . . . . . . . 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .23
4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 4.4. Verifying Correct Operation . . . . . . . . . . . . . . .23
4.4. Verifying Correct Operation . . . . . . . . . . . . . . .
4.5. Requirements on Other Protocols and Functional 4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . Components . . . . . . . . . . . . . . . . . . . . . . . .23
4.6. Impact on Network Operation . . . . . . . . . . . . . . . 4.6. Impact on Network Operation . . . . . . . . . . . . . . .23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . .23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .24
6.1 New Object Functions . . . . . . . . . . . . . . . . . . . 6.1 P2MP Capability TLV . . . . . . . . . . . . . . . . . . .24
6.2 New Metric Object Types . . . . . . . . . . . . . . . . . 6.2 Object Functions . . . . . . . . . . . . . . . . . . . . .24
5.3 UNREACH_DESTINATION objects . . . . . . . . . . . . . . . 6.3 Metric Object Types . . . . . . . . . . . . . . . . . . .24
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6.4 UNREACH_DESTINATION objects . . . . . . . . . . . . . . .24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 P2MP PCEP Error Objects and Types . . . . . . . . . . . .24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6.6 SERO and SRO Object-Class . . . . . . . . . . . . . . . .25
8.2. Informative References . . . . . . . . . . . . . . . . . . 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .25
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .25
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . .25
10. Intellectual Property Consideration. . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . .26
11. Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .26
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .27
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .27
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE is identified as a suitable application for the computation The PCE has been identified as a suitable application for the
of paths for P2MP TE LSPs [PCE-P2MP-APP]. computation of paths for P2MP TE LSPs [PCE-P2MP-APP].
The PCE communication protocol (PCEP) is designed as a communication The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path specification does not provide a mechanism to request path
computation of P2MP TE LSPs. computation of P2MP TE LSPs.
This document presents extensions to PCEP to support P2MP path This document presents extensions to PCEP to support P2MP path
computation satisfying the set of requirements described in [PCE- computation satisfying the set of requirements described in [PCE-
P2MP-REQ]. P2MP-REQ].
This document relies on the semantics of PCEP for requesting path This document relies on the mechanisms of PCEP for requesting path
computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple
source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between
ingress and egress LSRs and are appropriately combined by the branch ingress and egress LSRs and are appropriately combined by the branch
LSRs using computation result from PCE to result in a P2MP TE LSP. LSRs using computation results from the PCE to determine the path of
a P2MP TE LSP.
One request message from a PCC may signal one or more S2L sub-LSP One request message from a PCC may signal one or more S2L sub-LSP
path computation requests to the PCE for a single P2MP LSP with path computation requests to the PCE for a single P2MP LSP with
certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP
can use one path computation request message or be split across can use one path computation request message or be split across
multiple path computation messages. multiple path computation messages.
1.1 Terminology 1.1 Terminology
Terminology used in this document Terminology used in this document.
TE LSP: Traffic Engineered Label Switched Path. TE LSP: Traffic Engineered Label Switched Path.
LSR: Label Switch Router. LSR: Label Switch Router.
OF: Objective Function: A set of one or more optimization criterion OF: Objective Function: A set of one or more optimization criterion
(criteria) used for the computation of a single path (e.g. path cost (criteria) used for the computation of a single path (e.g. path cost
minimization), or the synchronized computation of a set of paths minimization), or the synchronized computation of a set of paths
(e.g. aggregate bandwidth consumption minimization, etc.). (e.g. aggregate bandwidth consumption minimization, etc.).
skipping to change at page 6, line 13 skipping to change at page 6, line 7
R9: Path Modification and Path Diversity. R9: Path Modification and Path Diversity.
R10: Reoptimization of P2MP TE LSPs. R10: Reoptimization of P2MP TE LSPs.
R11: Addition and Removal of Destinations from Existing Paths. R11: Addition and Removal of Destinations from Existing Paths.
R12: Specification of Applicable Branch Nodes. R12: Specification of Applicable Branch Nodes.
R13: Capabilities Exchange. R13: Capabilities Exchange.
The following additional requirements have also been identified:
R14: The PCC should be able to request a PCE to compute secondary R14: The PCC should be able to request a PCE to compute secondary
P2MP path tree with partial path diversity for specific leaves or a P2MP path tree with partial path diversity for specific leaves or a
specific S2L sub-path. specific S2L sub-path.
R15: Sender of the request message can specify if the return result R15: Sender of the request message can specify if the return result
from the PCE need to be represented in the compressed format or not. from the PCE need to be represented in the compressed format or not.
3. Protocol Procedures and Extensions 3. Protocol Procedures and Extensions
The following sections describe the protocol extensions to satisfy The following section describe the protocol extensions required to
the requirements specified in the previous section. satisfy the requirements specified in the requirements section
(section 2).
3.1. P2MP Capability Advertisement 3.1. P2MP Capability Advertisement
3.1.1. Extend the TLV in the Existing PCE Discovery Protocol 3.1.1. Extend the TLV in the Existing PCE Discovery Protocol
Since the [RFC5088] has specified that we can not add additional sub- Since [RFC5088] has specified that we cannot add an additional
TLV to the PCED TLV, we will define new bits to go in the existing 32 sub-TLV to the PCEP TLV, we will define s new bit to go in the
bits PCE Caps Flags to indicate the capability of P2MP for the PCC existing 32 bit PCE capabilities flags to indicate the capability
and PCE. of P2MP computation.
3.1.2. Open Message Extension 3.1.2. Open Message Extension
Based on the Capabilities Exchange requirement described in [PCE- Based on the Capabilities Exchange requirement described in [PCE-
P2MP-REQ], if a PCE does not advertise its P2MP capability through P2MP-REQ], if a PCE does not advertise its P2MP capability during
discovery and the capability is not configured to the PCC, we need to discovery and the PCC does not have an alternative PCE capable of
use PCEP to allow a PCC to discover which PCEs with which it P2MP computation. We need to use PCEP to allow a PCC to discover
communicates support P2MP path computation. To satisfy this which PCEs with which it communicates support P2MP path
requirement, we extend the OPEN object format by including a new computation. To satisfy this requirement, we extend the OPEN
defined TLV for the capability of P2MP in the optional field. The object format by including a new defined TLV for the capability of
new defined capability TLV allows the PCE to advertise its path P2MP in the optional field. The new defined capability TLV allows
computation capabilities. the PCE to advertise its P2MP path computation capability.
The TLV type number will be assigned by IANA, the LENGTH value is 2 The TLV type number will be assigned by IANA, the LENGTH value is 2
bytes. The value field is set to default value 0. bytes. The value field is set to default value 0.
Note that the capability TLV is meaningful only for a PCE so it will 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 typically appear only in one of the two Open messages during PCE
session establishment. However, in case of PCE cooperation (e.g., session establishment. However, in case of PCE cooperation (e.g.,
inter-domain), when a PCE behaving as a PCC initiates a PCE session inter-domain), when a PCE behaving as a PCC initiates a PCE session
it SHOULD also indicate its Path Computation capability. it SHOULD also indicate its path computation capabilities.
3.2. P2MP LSPs Efficient Presentation 3.2. P2MP LSPs Efficient Presentation
In the request message of the adding of leaves, optimization of P2MP When specifying additional leaves, or optimizing existing P2MP TE
TE LSPs as specified in [PCE-P2MP-REQ], and in the reply message, we LSPs as specified in [PCE-P2MP-REQ], we need to pass existing
need to pass an existing P2MP LSP between the PCC and PCE. In these P2MP LSP route information between the PCC and PCE in the request and
cases, we need new path objects for efficiently passing the existing reply message. In each of these scenarios, we need new path
P2MP LSP between PCE to PCC. objects for efficiently passing the existing P2MP LSP between
the PCE and PCC.
We suggest to using the ERO/SERO and RRO/SRRO to represent each We specify the use of the Explicit Route Object (ERO)
individual S2L sub-LSP. The contents of ERO/RRO are same as defined to encode the explicit route of a TE LSP through the network. The
in the [RFC5440] and the contents of SERO and SRRO are same as Secondary Explicit Route object (SERO) is used to specify the
defined in RFC4875 for the RSVP extension of P2MP except we need explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and
assign the new class and type for all of them. Secondary Reported Route Object (SERO) are used to report
the routes of existing TE LSP for which a reoptimization is
desired.
3.3. Indication of P2MP Path Computation Request/Reply The format and contents of the ERO and RRO are defined in [RFC5440].
The format and contents of the SERO and SRRO are defined in
[RFC4875]. A new class and type are requested for SERO and SRRO in
the IANA Considerations section of this document.
3.3. P2MP Path Computation Request/Reply Message Extensions
The existing P2P RP object is extended so that it can signal to the The existing P2P RP object is extended so that it can signal to the
receiver of the request or reply message that it is for P2P or P2MP receiver of the PCEP request that it is for P2P or P2MP path
path computation. Also the END-POINT object is extended to improve computation. Also the END-POINT object is extended to improve the
the efficiency of the message exchange between PCC and PCE in the efficiency of the message exchange between PCC and PCE in the case
case of P2MP path computation. of P2MP path computation.
3.3.1. The Extension of RP Object 3.3.1. The Extension of RP Object
The PCE path computation request/reply message adds an explicit The PCE path computation request and reply message will need the
parameter to allow a receiving PCE to identify that the request/reply following additional parameter to allow a receiving PCE to
is for a P2MP path and also to specify if the route is represented in identify that the request and reply message has been fragmented
the compress format or not. across multiple messages, is for a P2MP path and to specify if the
route is represented in the compressed format or not.
The F bit The F bit is added to the flag bits of the RP object to indicate
to the receiver that the request is a fragmented request, or is not
fragmented request.
The M bit is added in the flag bits field of the RP object to signal The M 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 the receiver of the message that the request/reply is for P2MP or
not. not.
The E bit is added in the flag bits field of the RP object to signal 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 compress format the receiver of the message that the route is in the compress format
or not. or not.
The extended format of the RP object body to include the F bit, M The extended format of the RP object body to include the F bit, M
skipping to change at page 9, line 30 skipping to change at page 9, line 34
3. Old leaves whose path can be modified/reoptimized; 3. Old leaves whose path can be modified/reoptimized;
4. Old leaves whose path must be left unchanged. 4. Old leaves whose path must be left unchanged.
With this new END-POINTS object, the END-POINTS portions of a request With this new END-POINTS object, the END-POINTS portions of a request
message for the multiple destinations can be roughly reduced up to message for the multiple destinations can be roughly reduced up to
50% for a P2MP path where a single source address has a very large 50% for a P2MP path where a single source address has a very large
number of destinations. number of destinations.
Note that A P2MP path computation request can mix the different type Note that A P2MP path computation request can mix the different type
of leaves by including several END-POINTS object per RP object as of leaves by including several END-POINTS object per RP object as
shown in PCReq BNF format in next section. shown in PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in
next section.
The format of the new END-POINTS object body for IPv4 (Object-Type 3) The format of the new END-POINTS object body for IPv4 (Object-Type 3)
is as follows: is as follows:
0 1 2 3 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 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 | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
skipping to change at page 10, line 34 skipping to change at page 10, line 34
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The New P2MP END-POINTS Object Body Format for IPv6 Figure 3: The New P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length of multiple of 4 The END-POINTS object body has a variable length of multiple of 4
bytes for IPv4 and multiple of 16 bytes for IPv6. bytes for IPv4 and multiple of 16 bytes for IPv6.
3.4. Request Message Formats 3.4. Request Message Formats
As per [RFC5511] the format of the PCReq message is as follows. As per [RFC5511] the RBNF format of the PCReq message is as follows.
Please see Appendix A for a full set of RBNF fragments defined in Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license. this document and the necessary code license.
Below is the message format for the request message: Below is the message format for the request message:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<request> <request>
where: where:
<request>::= <RP> <request>::= <RP>
<end-point-rro-pair-list> <end-point-rro-pair-list>
skipping to change at page 11, line 21 skipping to change at page 11, line 21
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
Figure 4: The Message Format for the Request Message Figure 4: The Message Format for the Request Message
Note we preserve compatibility with the [RFC5440] definition of Note we preserve compatibility with the [RFC5440] definition of
<request>. At least one instance of <endpoints> must be present <request>. At least one instance of <endpoints> must be present
in this definition. in this definition.
3.5. Reply Message Formats 3.5. Reply Message Formats
As per [RFC5511] the format of the PCRep message is as follows. As per [RFC5511] the RBNF format of the PCRep message is as follows.
Please see Appendix A for a full set of RBNF fragments defined in Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license. this document and the necessary code license.
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response> <response>
<response>::=<RP> <response>::=<RP>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<NO-PATH>] [<NO-PATH>]
skipping to change at page 12, line 45 skipping to change at page 12, line 45
a specific metric or to the TE metric used as the default metric when 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) the metric is not specified. (e.g. TE or IGP metric)
Objective Function Code: 8 (suggested value, to be assigned by IANA) Objective Function Code: 8 (suggested value, to be assigned by IANA)
Name: Minimum Cost Tree (MCT) Name: Minimum Cost Tree (MCT)
Description: Minimize the total cost of the tree, that is the sum of 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 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 TE metric used as the default metric when the metric is not
specified.. specified.
Processing these two new objective functions is subject to the rules Processing these two new objective functions is subject to the rules
defined in [RFC5541]. defined in [RFC5541].
3.6.2. New Metric Object Types 3.6.2. New Metric Object Types
There are three types defined for the <METRIC> object in [RFC5440], There are three types defined for the <METRIC> object in [RFC5440],
namely, the IGP metric, the TE metric and the hop count metric. This namely, the IGP metric, the TE metric and the Hop Count metric. This
document defines three other types for the <METRIC> object: the P2MP document defines three other types for the <METRIC> object: the P2MP
IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They 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 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 the following values for these new metric types:
IANA):
o P2MP IGP metric: T=4 o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA)
o P2MP TE metric: T=5 o P2MP TE metric: T=9 (suggested value, to be assigned by IANA)
o P2MP hop count metric: T=6 o P2MP hop count metric: T=10 (suggested value, to be assigned by
IANA)
3.7. Non-Support of P2MP Path Computation. 3.7. Non-Support of P2MP Path Computation.
o if a PCE receives a P2MP path request and it understands the P2MP o If a PCE receives a P2MP path request and it understands the P2MP
flag in RP object, but the PCE is not capable of P2MP computation, flag in RP object, but the PCE is not capable of P2MP computation,
the PCE MUST send a PCErr message with a PCEP-ERROR Object and an the PCE MUST send a PCErr message with a PCEP-ERROR Object and
Error-Value. The corresponding P2MP path computation request MUST corresponding Error-Value. The original P2MP path
be cancelled. (Error-Type and Error-Value are defined in this computation request MUST then be cancelled. New Error-Types and
document). 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, 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 then the PCE MUST send a PCErr message with a new error type
"Unknown RP flag". "Unknown RP flag".
3.8. Non-Support by Back-Level PCE Implementations. 3.8. Non-Support by Back-Level PCE Implementations.
If we accidentally send the P2MP request to a PCE which does not If a PCC inadvertently sends the P2MP request to a PCE which does not
support the PCEP P2MP extensions yet, then it will reject the request support the PCEP P2MP extensions, then it SHOULD reject the request
because it cannot understand the new END-POINTS object. because it cannot understand the new P2MP END-POINTS object.
3.9. P2MP TE Path Re-optimization Request 3.9. P2MP TE Path Re-optimization Request
The re-optimization request for a P2MP TE path is specified by R bit The re-optimization request for a P2MP TE path is specified by R bit
in the RP object similarly to the re-optimization request for a P2P in the RP object similarly to the re-optimization request for a P2P
TE path. The only difference is that the user must insert the list TE path. The only difference is that the user must insert the list
of RRO after each type of END-POINTS as described in the PCReq of RRO and SRRO after each type of END-POINTS as described in the
message format section. PCReq message format section.
So the PCReq message would look like this: So the PCReq message would look like this:
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 6: PCReq Message Example 1 for Optimization Figure 6: PCReq Message Example 1 for Optimization
skipping to change at page 14, line 44 skipping to change at page 14, line 44
3.10. Adding/pruning Leaves 3.10. Adding/pruning Leaves
When adding new leaves or removing old leaves to the existing P2MP When adding new leaves or removing old leaves to the existing P2MP
tree, by supplying a list of existing leaves, one may be able to tree, by supplying a list of existing leaves, one may be able to
optimize the new P2MP tree. This section explains ways to add new optimize the new P2MP tree. This section explains ways to add new
leaves or remove old leaves to the existing P2MP tree. leaves or remove old leaves to the existing P2MP tree.
To add new leaves the user must build a P2MP request with an END- To add new leaves the user must build a P2MP request with an END-
POINTS with leaf type 1. POINTS with leaf type 1.
To Remove old leaves the user must build a P2MP request with an END- To remove old leaves the user must build a P2MP request with an END-
POINTS with leaf type 2. POINTS with leaf type 2.
In any case it must also provides the list of old leaves and indicate In any case it must also provide the list of old leaves and indicate
if they must be reoptimized or not by including END-POINTS with leaf if they must be reoptimized or not by including END-POINTS with leaf
type 3 or 4 or both. In the future version, we may want to consider type 3 or 4 or both. This document also define error values when the
to define error values when the condition is not satisfied (i.e., condition is not satisfied (i.e., when there is no END-POINTS with
when there is no END-POINTS with leaf type 3 or 4, in the presence of leaf type 3 or 4, in the presence of END-POINTS with leaf type 1
END-POINTS with leaf type 1 or 2). or 2). This are documented in the IANA Considerations section.
For old leaves the user must provide the old path as list of RROs For old leaves the user must provide the old path as list of RROs
that immediately follows each END-POINTS object. In the future that immediately follows each END-POINTS object. This document
version, we may want to consider to define error values when the specifies error values when specific conditions are not satisfied.
condition is not satisfied.
So eventually the following cases are possible when modifying an The following cases are possible when modifying an existing P2MP
existing P2MP LSP: LSP:
Case 1: Adding leaves with full reoptimization of existing paths Case 1: Adding leaves with full reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
skipping to change at page 17, line 39 skipping to change at page 17, line 39
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 16: Adding and Pruning Leaves without Reoptimization Figure 16: Adding and Pruning Leaves without Reoptimization
3.11. Branch Nodes 3.11. Branch Nodes
Before computing the P2MP path, a PCE must be provided means to know 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 which nodes in the network are capable of acting as branch LSRs. A
PCE can discover such capability by using the mechanisms defined in PCE can discover such capabilities by using the mechanisms defined in
[PCE-P2MP-REQ]. [PCE-P2MP-REQ].
3.12. Synchronization of P2MP TE Path Computation Requests 3.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs' computations need to be There are cases when multiple P2MP LSPs' computations need to be
synchronized. For example, one P2MP LSP is the backup of another synchronized. For example, one P2MP LSP is the designated backup of
P2MP LSP. In this case, the path diversity for these two LSPs need another P2MP LSP. In this case, path diversity for these two
to be considered during the path computation. LSPs may need to be considered during the path computation.
The synchronization can be done by just using the existing SVEC The synchronization can be done by just using the existing SVEC
functionality. functionality.
Example of synchronizing two P2MP LSPs, each has two leaves for Path Example of synchronizing two P2MP LSPs, each has two leaves for Path
Computation Request Messages is illustrated as below: Computation Request Messages is illustrated as below:
Common Header Common Header
SVEC for sync of LSP1 and LSP2 SVEC for sync of LSP1 and LSP2
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
END-POINTS2 for P2MP END-POINTS2 for P2MP
RRO2 list RRO2 list
Figure 17: PCReq Message Example for Synchronization Figure 17: PCReq Message Example for Synchronization
We propose that two new flags are also added to the SVEC object for We propose that two new flags are also added to the SVEC object for
path dependent computation requests. The first new flag is to allow P2MP path dependent computation requests. The first new flag is to
the PCC to request that the PCE should compute a secondary P2MP path allow the PCC to request that the PCE should compute a secondary
tree with partial path diversity for specific leaves or a specific P2MP path tree with partial path diversity for specific leaves or
S2L sub- path to the primary P2MP path tree. The second flag, would a specific S2L sub-path to the primary P2MP path tree. The second
allow the PCC to request that partial paths should be link flag, would allow the PCC to request that partial paths should be
direction diverse. link direction diverse.
The format of the SVEC object body 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|P|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SVEC Body Object Format with Additional Flags
The following flags are added to the SVEC object body in this draft:
o P ( Partial Path Diversity bit - 1 bit):
When set this would indicate a request for partial path
diversity for a specific leave or set of 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.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
In certain scenarios the request may not fit into a single request or In certain scenarios the request may not fit into a single request or
response message. For example, if a tree has many hundreds or response message. For example, if a tree has many hundreds or
thousands of leaves. Then the request or response may need to thousands of leaves. Then the request or response may need to
be fragmented into multiple messages. be fragmented into multiple messages.
The F bit has been outlined in section 3.3.1. The Extension of RP The F bit has been outlined in section 3.3.1. The Extension of RP
Object, of this document. The F bit is used in the RP object header Object, of this document. The F bit is used in the RP object header
to signal that the an intial request or response was too large to fit to signal that the an initial request or response was too large to
into a single message and should therfore be fragmented into fit into a single message and should therefore be fragmented into
multiple requests. In order to indentify the single request or multiple requests. In order to indentify the single request or
response, each message will use the same request ID. response, each message will use the same request ID.
3.13.1 Request Fragmentation Procedure 3.13.1 Request Fragmentation Procedure
If the intial request is too large to fit into a single request If the initial request is too large to fit into a single request
message the PCC will split the requst over multiple messages. Each message the PCC will split the requst over multiple messages. Each
message sent to the PCE will have the F bit set in the RP object message sent to the PCE will have the F bit set in the RP object
to signify that the request has been fragmented into multiple to signify that the request has been fragmented into multiple
messages. In order to indentify that a series of request messages messages. In order to indentify that a series of request messages
represents a single request, each message will use the same represents a single request, each message will use the same
request ID. request ID.
The assumption is that request messages are reliably delivered The assumption is that request messages are reliably delivered
and in sequence since PCEP relies on TCP. and in sequence since PCEP relies on TCP.
3.13.2 Response Fragmentation Procedure 3.13.2 Response Fragmentation Procedure
Once the PCE computes a path based on the intial request a 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 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 requst over into a single response message the PCE will split the request over
multiple messages. Each message sent to the PCE with the F bit set multiple messages. Each message sent to the PCE with the F bit set
in the RP object to signify that the response has been fragmented in the RP object to signify that the response has been fragmented
into multiple messages. In order to indentify that a series of into multiple messages. In order to indentify that a series of
response messages represents a single request, each message will response messages represents a single request, each message will
use the same request ID. use the same request ID.
The assumption is that response messages are reliably delivered The assumption is that response messages are reliably delivered
and in sequence since PCEP relies on TCP. and in sequence since PCEP relies on TCP.
3.13.3 Fragmentation Examples 3.13.3 Fragmentation Examples
skipping to change at page 19, line 45 skipping to change at page 20, line 22
RP2 with Req-ID1 and P2MP flag and F bit cleared RP2 with Req-ID1 and P2MP flag and F bit cleared
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
To handle the case that the last fragmented message piece is lost, the To handle the case that the last fragmented message piece is lost, the
receiver side of the fragmented message may start a timer once it receiver side of the fragmented message may start a timer once it
receives the first piece of the fragmented message. When timer expires receives the first piece of the fragmented message. When timer expires
and it still doesn't receive the last piece of the fragmented message, and it still doesn't receive the last piece of the fragmented message,
it should send an error message to the receiver to signal that it it should send an error message to the receiver to signal that it
have recieved an incomplete message. have received an incomplete message.
3.14. UNREACH_DESTINATION object 3.14. UNREACH-DESTINATION Object
The PCE path computation request may fail because all or a subset of The PCE path computation request may fail because all or a subset of
the destinations are unreachable. the destinations are unreachable.
In such a case, the UNREACH-DESTINATION object allows the PCE to In such a case, the UNREACH-DESTINATION object allows the PCE to
optionally specify the list of unreachable destinations. optionally specify the list of unreachable destinations.
This object can be present in PCRep messages. There can be up to one This object can be present in PCRep messages. There can be up to one
such object per RP. such object per RP.
UNREACH_DESTINATION Object-Class is to be assigned by IANA. 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 IPv4 is to be assigned by IANA
UNREACH_DESTINATION Object-Type for IPv6 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- The format of the UNREACH-DESTINATION object body for IPv4 (Object-
Type=1) is as follows: Type=1) is as follows:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: UNREACH_DESTINATION Object Body for IPv4 Figure 20: UNREACH-DESTINATION Object Body for IPv4
The format of the UNREACH_DESTINATION object body for IPv6 (Object- The format of the UNREACH-DESTINATION object body for IPv6 (Object-
Type=2) is as follows: Type=2) is as follows:
0 1 2 3 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 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) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: UNREACH_DESTINATION Object Body for IPv6 Figure 21: UNREACH-DESTINATION Object Body for IPv6
3.15. P2MP PCEP Error Object 3.15. P2MP PCEP Error Objects and Types
To indicate errors associated with the P2MP path request, a new To indicate errors associated with the P2MP path request, a new
Error-Type (16) and subsequent error-values are defined as follows Error-Type (16) and subsequent error-values are defined as follows
for inclusion in the PCEP-ERROR object: for inclusion in the PCEP-ERROR object:
A new Error-Type (16) and subsequent error-values are defined as
follows:
Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path 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 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 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 ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The
corresponding P2MP path computation request MUST be cancelled. corresponding P2MP path computation request MUST be cancelled.
Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 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 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- PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error-
Value (Error-Value=2). The corresponding P2MP path computation Value (Error-Value=2). The corresponding P2MP path computation
request MUST be cancelled. request MUST be cancelled.
To indicate an error associated with policy violation, a new error To indicate an error associated with policy violation, a new error
value "P2MP Path computation not allowed" should be added to an value "P2MP Path computation not allowed" should be added to an
existing error code for policy violation (Error-Type=5) as defined in existing error code for policy violation (Error-Type=5) as defined
[RFC5440]. in [RFC5440]:
Error-Type=5; Error-Value=4: if a PCE receives a P2MP path Error-Type=5; Error-Value=6: if a PCE receives a P2MP path
computation request which is not compliant with administrative computation request which is not compliant with administrative
privileges (i.e., the PCE policy does not support P2MP path privileges (i.e., "The PCE policy does not support P2MP path
computation), the PCE sends a PCErr message with a PCEP-ERROR Object computation"), the PCE sends a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=4). The corresponding (Error-Type=5) and an Error-Value (Error-Value=6). The corresponding
P2MP path computation request MUST be cancelled. P2MP path computation request MUST be cancelled.
3.16. PCEP NO-PATH Indicator 3.16. PCEP NO-PATH Indicator
To communicate the reason(s) for not being able to find P2MP path To communicate the reason(s) for not being able to find P2MP path
computation, the NO-PATH object can be used in the PCRep message. computation, the NO-PATH object can be used in the PCRep message.
The format of the NO-PATH object body is as follows: The format of the NO-PATH object body is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: The Format of the NO-PATH Object Body Figure 22: The Format of the NO-PATH Object Body
One new bit flags is defined in the NO-PATH-VECTOR TLV carried in One new bit flags is defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object: the NO-PATH Object:
0x20: when set, the PCE indicates that there is a reachability 0x20: when set, the PCE indicates that there is a reachability
problem with all or a subset of the P2MP destinations. Optionally problem with all or a subset of the P2MP destinations. Optionally
the PCE can specify the list of destination(s) that are not reachable the PCE can specify the list of destination(s) that are not reachable
using the new UNREACH_DESTINATION object defined in section 3.6. using the new UNREACH-DESTINATION object defined in section 3.6.
4. Manageability Considerations 4. Manageability Considerations
[PCE-P2MP-REQ] describes various manageability requirements in [PCE-P2MP-REQ] describes various manageability requirements in
support of P2MP path computation when applying PCEP. This section support of P2MP path computation when applying PCEP. This section
describes how manageability requirements mentioned in [PCE-P2MP-REQ] describes how manageability requirements mentioned in [PCE-P2MP-REQ]
are supported in the context of PCEP extensions specified in this are supported in the context of PCEP extensions specified in this
document. document.
Note that [RFC5440] describes various manageability considerations in Note that [RFC5440] describes various manageability considerations in
skipping to change at page 24, line 39 skipping to change at page 24, line 11
may be more vulnerable to denial of service attacks. Therefore it is may be more vulnerable to denial of service attacks. Therefore it is
more important that implementations conform to security requirements more important that implementations conform to security requirements
of [RFC5440], and the implementor utilize those security features of [RFC5440], and the implementor utilize those security features
6. IANA Considerations 6. IANA Considerations
A number of IANA considerations have been highlighted in previous A number of IANA considerations have been highlighted in previous
sections of this document. In summary, IANA is requested to make sections of this document. In summary, IANA is requested to make
allocations for the following PCEP parameters. allocations for the following PCEP parameters.
6.1 New Object Functions 6.1 P2MP Capability TLV
The new defined P2MP capability TLV allows the PCE to advertise
its P2MP path computation capability. The LENGTH value is 2
bytes. The value field is set to default value 0.
6.2 Object Functions
Objective Function Code: 7 (suggested value) Objective Function Code: 7 (suggested value)
Name: Shortest Path Tree (SPT) Name: Shortest Path Tree (SPT)
Objective Function Code: 8 (suggested value) Objective Function Code: 8 (suggested value)
Name: Minimum Cost Tree (MCT) Name: Minimum Cost Tree (MCT)
6.2 New Metric Object Types 6.3 Metric Object Types
P2MP IGP metric: T=4 (suggested value) P2MP IGP metric: T=8 (suggested value)
P2MP TE metric: T=5 (suggested value) P2MP TE metric: T=9 (suggested value)
P2MP hop count metric: T=6 (suggested value) P2MP hop count metric: T=10 (suggested value)
6.3 UNREACH_DESTINATION objects 6.4 UNREACH_DESTINATION Objects
UNREACH_DESTINATION Object-Class UNREACH_DESTINATION Object-Class
UNREACH_DESTINATION Object-Type for IPv4 UNREACH_DESTINATION Object-Type for IPv4
UNREACH_DESTINATION Object-Type for IPv6 UNREACH_DESTINATION Object-Type for IPv6
6.5 P2MP PCEP Error Objects and Types
To indicate errors associated with the P2MP path request, one new
Error-Type 5 Error-Value and two new Error-Types (16) and
subsequent error-values will need to be defined and included in
the PCEP-ERROR object:
Error-Type=5; Error-Value=6: To indicate an error associated with
policy violation, a new error value "P2MP Path computation is not
allowed".
Error-Type=16 and Error-Value=1: The PCE is not capable to satisfy
the request due to insufficient memory.
Error-Type=16 and Error-Value=2: The PCE is not capable of P2MP
computations.
Additionally a new Error-Type and corresponding values will be needed
to report reoptimization requests that fail due to END-POINT
leaf type failures. These are:
Error-Type=17 and Error-Value=1: The PCE is not capable to satisfy
the request due to no END-POINTS with leaf type 2.
Error-Type=17 and Error-Value=2: The PCE is not capable to satisfy
the request due to no END-POINTS with leaf type 3.
Error-Type=17 and Error-Value=2: The PCE is not capable to satisfy
the request due to no END-POINTS with leaf type 4.
6.6 SERO and SRO Object-Class
SERO Object-Class is 25 (suggested value)
SERO Object-Type is 1 (suggested value).
SSRO Object-Class is 26 (suggested value).
SSRO Object-Type is 1 (suggested value).
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan, Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable Tappan, Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable
comments on this draft. comments on this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 26, line 17 skipping to change at page 26, line 30
Functions in the Path Computation Element Communication Functions in the Path Computation Element Communication
Protocol (PCEP)", RFC5541, December 2008. Protocol (PCEP)", RFC5541, December 2008.
8.2. Informative References 8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[PCE-P2MP-APP] [PCE-P2MP-APP]
Yasukawa, S. and A. Farrel, Yasukawa, S. and A. Farrel,
"draft-ietf-pce-p2mp-app-01.txt", "draft-ietf-pce-p2mp-app-02.txt",
draft-ietf-pce-p2mp-app-01 (work in progress), draft-ietf-pce-p2mp-app-02 (work in progress),
February 2009. August 2009.
[PCE-P2MP-REQ] [PCE-P2MP-REQ]
Yasukawa, S. and A. Farrel, "PCC-PCE Communication Yasukawa, S. and A. Farrel, "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)", Switching Traffic Engineering (MPLS-TE)",
draft-ietf-pce-p2mp-req-01 (work in progress), draft-ietf-pce-p2mp-req-01 (work in progress),
February 2008. February 2008.
9. Authors' Addresses 9. Authors' Addresses
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technology Huawei Technology
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US US
Email: qzhao@huawei.com Email: qzhao@huawei.com
Daniel King Daniel King (editor)
Old Dog Consulting Old Dog Consulting
UK UK
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Fabien Verhaeghe Fabien Verhaeghe
France France
Email: fabien.verhaeghe@gmail.com Email: fabien.verhaeghe@gmail.com
Tomonori Takeda Tomonori Takeda
NTT Corporation NTT Corporation
3-9-11, Midori-Cho 3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Musashino-Shi, Tokyo 180-8585
Japan Japan
Email: takeda.tomonori@lab.ntt.co.jp Email: takeda.tomonori@lab.ntt.co.jp
skipping to change at page 28, line 28 skipping to change at page 28, line 41
where: where:
<end-point-rro-pair-list>::= <end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>] <END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>] <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
Below is the bessage format for the reply message: Below is the message format for the reply message:
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response> <response>
<response>::=<RP> <response>::=<RP>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
where: where:
<end-point-path-pair-list>::= <end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>] [<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::=(ERO)|(SERO)|<path>] <path> ::=(ERO)|(SERO)|<path>]
<attribute-list>::=[<OF>] <attribute-list>::=[<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
 End of changes. 73 change blocks. 
178 lines changed or deleted 261 lines changed or added

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