draft-ietf-pce-pcep-p2mp-extensions-10.txt   draft-ietf-pce-pcep-p2mp-extensions-11.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, Ed. Intended Status: Standards Track Daniel King, Ed.
Expires: October 30, 2010 Old Dog Consulting Expires: November 25, 2010 Old Dog Consulting
April 19, 2010 May 25, 2010
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-10.txt draft-ietf-pce-pcep-p2mp-extensions-11.txt
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
need to 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.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 19, 2010. This Internet-Draft will expire on May 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
to format it for publication as an RFC or to translate it into to format it for publication as an RFC or to translate it into
languages other than English. languages other than English.
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 . . . . . . . . . . . . . . . . . . . . . . . . .4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5
3. Protocol Procedures and Extensions . . . . . . . . . . . . . .6 3. Protocol Procedures and Extensions . . . . . . . . . . . . . .6
3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .6 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .6
3.1.1. P2MP Computation TLV in the Existing PCE Discovery 3.1.1. P2MP Computation TLV in the Existing PCE Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . .6 Protocol . . . . . . . . . . . . . . . . . . . . . . .6
3.1.2. Open Message Extension . . . . . . . . . . . . . . . .6 3.1.2. Open Message Extension . . . . . . . . . . . . . . . .6
3.2. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7 3.2. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7
3.3. P2MP Path Computation Request/Reply Message Extensions . .8 3.3. P2MP Path Computation Request/Reply Message Extensions . .8
3.3.1. The Extension of the RP Object . . . . . . . . . . . .8 3.3.1. The Extension of the RP Object . . . . . . . . . . . .8
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .9 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .9
3.4. Request Message Format . . . . . . . . . . . . . . . . . .11 3.4. Request Message Format . . . . . . . . . . . . . . . . . .11
3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .12 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .11
3.6. P2MP Objective Functions and Metric Types . . . . . . . .13 3.6. P2MP Objective Functions and Metric Types . . . . . . . .12
3.6.1. New Objective Functions . . . . . . . . . . . . . . .13 3.6.1. New Objective Functions . . . . . . . . . . . . . . .12
3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .14 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .13
3.8. Non-Support by Back-Level PCE Implementations. . . . . . .14 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .13
3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .14 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .14
3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .15 3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .14
3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .18 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .17
3.11.1 Branch Node Object . . . . . . . . . . . . . . . . . .18 3.11.1 Branch Node Object . . . . . . . . . . . . . . . . . .17
3.12. Synchronization of P2MP TE Path Computation Requests . . .19 3.12. Synchronization of P2MP TE Path Computation Requests . . .18
3.13. Request and Response Fragmentation . . . . . . . . . . . .20 3.13. Request and Response Fragmentation . . . . . . . . . . . .19
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .20 3.13.1. Request Fragmentation Procedure . . . . . . . . . . .19
3.13.2 Response Fragmentation Procedure . . . . . . . . . . .20 3.13.2. Response Fragmentation Procedure . . . . . . . . . . .19
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .20 3.13.3. Fragmentation Examples . . . . . . . . . . . . . . . .19
3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .21 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .20
3.15. P2MP PCEP Error Object and Types . . . . . . . . . . . . .22 3.15. P2MP PCEP Error Object and Types . . . . . . . . . . . . .21
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .23 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .22
4. Manageability Considerations . . . . . . . . . . . . . . . . .23 4. Manageability Considerations . . . . . . . . . . . . . . . . .22
4.1. Control of Function and Policy . . . . . . . . . . . . . .23 4.1. Control of Function and Policy . . . . . . . . . . . . . .23
4.2. Information and Data Models . . . . . . . . . . . . . . .24 4.2. Information and Data Models . . . . . . . . . . . . . . .23
4.3. Liveness Detection and Monitoring . . . . . . . . . . . .24 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .23
4.4. Verifying Correct Operation . . . . . . . . . . . . . . .24 4.4. Verifying Correct Operation . . . . . . . . . . . . . . .23
4.5. Requirements on Other Protocols and Functional 4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . .24 Components . . . . . . . . . . . . . . . . . . . . . . . .23
4.6. Impact on Network Operation . . . . . . . . . . . . . . .24 4.6. Impact on Network Operation . . . . . . . . . . . . . . .24
5. Security Considerations . . . . . . . . . . . . . . . . . . .24 5. Security Considerations . . . . . . . . . . . . . . . . . . .24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .24
6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .25 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . .25
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25
6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25 6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .26 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .25
6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27
6.8 SVEC Object Flag . . . . . . . . . . . . . . . . . . . . .27 6.8. SVEC Object Flag . . . . . . . . . . . . . . . . . . . .27
6.9 OSPF PCE Capability Flag . . . . . . . . . . . . . . . .28 6.9. OSPF PCE Capability Flag . . . . . . . . . . . . . . . .28
7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .28 7. Acknowledgement's . . . . . . . . . . . . . . . . . . . . . .28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .28
8.1. Normative References . . . . . . . . . . . . . . . . . . .28 8.1. Normative References . . . . . . . . . . . . . . . . . . .28
8.2. Informative References . . . . . . . . . . . . . . . . . .29 8.2. Informative References . . . . . . . . . . . . . . . . . .29
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .30 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .30
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .30 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .31
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
skipping to change at page 5, line 23 skipping to change at page 5, line 14
This document also uses the terminology defined in [RFC4655], This document also uses the terminology defined in [RFC4655],
[RFC4875], and [RFC5440]. [RFC4875], and [RFC5440].
2. Requirements 2. Requirements
This section summarizes the PCC-PCE Communication Requirements for This section summarizes the PCC-PCE Communication Requirements for
P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system
corresponds to the requirement numbers used in [PCE-P2MP-REQ]. corresponds to the requirement numbers used in [PCE-P2MP-REQ].
1. Indication of P2MP Path Computation Request. 1. The PCC MUST be able to specify that the request is a P2MP path
computation request.
2. Indication of P2MP Objective Functions. 2. The PCC MUST be able to specify that objective functions are to be
applied to the P2MP path computation request.
3. Non-Support of P2MP Path Computation. 3. The PCE MUST have the capability to reject a P2MP path request
and indicate non-support of P2MP path computation.
4. Non-Support by Back-Level PCE Implementations. 4. The PCE MUST provide an indication of non-support of P2MP path
computation by back-level PCE implementations.
5. Specification of Destinations. 5. A P2MP path computation request MUST be able to list multiple
destinations.
6. Indication of P2MP Paths. 6. A P2MP path computation response MUST be able to carry the path
of a P2MP LSP.
7. Multi-Message Requests and Responses. 7. It MUST be possible for a single P2MP path computation request or
response to be conveyed by a sequence of messages.
8. Non-Specification of Per-Destination Constraints and Parameters. 8. It MUST NOT be possible for a single P2MP path computation
request to specify a set of different constraints, traffic
parameters, or quality-of-service requirements for different
destinations of a P2MP LSP.
9. Path Modification and Path Diversity. 9. P2MP path modification and P2MP path diverse MUST be supported.
10. Reoptimization of P2MP TE LSPs. 10. It MUST be possible to reoptimize existing P2MP TE LSPs.
11. Addition and Removal of Destinations from Existing Paths. 11. It MUST be possible to add and remove P2MP destinations
from existing paths.
12. Specification of Applicable Branch Nodes. 12. It MUST be possible to specify a list of applicable branch
nodes to use when computing the P2MP path.
13. Capabilities Exchange. 13. It MUST be possible for a PCC to discover P2MP path computation
capability.
14. Path-Tree Diversity. 14. The PCC MUST be able to request diverse paths when requesting a
P2MP path.
3. Protocol Procedures and Extensions 3. Protocol Procedures and Extensions
The following section describes the protocol extensions required to The following section describes the protocol extensions required to
satisfy the requirements specified in the Requirements section satisfy the requirements specified in Section 2. (Requirements)
(Section 2) of this document. of this document.
3.1. P2MP Capability Advertisement 3.1. P2MP Capability Advertisement
3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF
Router Information LSA defined in [RFC4970] to facilitate PCE Router Information LSA defined in [RFC4970] to facilitate PCE
discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be
added to the PCED TLV. This document defines a new flag in the added to the PCED TLV. This document defines a new flag in the OSPF
OSPF PCE Capability Flags to indicate the capability of P2MP PCE Capability Flags to indicate the capability of P2MP computation.
computation.
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
Discovery using IS-IS. This document will use the same flag Discovery using IS-IS. This document will use the same flag
requested for the OSPF PCE Capability Flags sub-TLV requested for the OSPF PCE Capability Flags sub-TLV
to allow IS-IS to indicate the capability of P2MP computation. to allow IS-IS to indicate the capability of P2MP computation.
The IANA request for a shared OSPF and IS-IS P2MP capability flag The IANA request for a shared OSPF and IS-IS P2MP capability flag
is documented in Section 6.9 of this document. is documented in Section 6.9. (OSPF PCE Capability Flag) of this
document.
PCEs wishing to advertise that they support P2MP path computation PCEs wishing to advertise that they support P2MP path computation
would set the bit (to be assigned by IANA) accordingly. PCCs that would set the bit (to be assigned by IANA) accordingly. PCCs that
do not understand this bit will ignore it (per [RFC5088] and do not understand this bit will ignore it (per [RFC5088] and
[RFC5089]). PCEs that do not support P2MP will leave the bit clear [RFC5089]). PCEs that do not support P2MP will leave the bit clear
(per the default behavior defined in [RFC5088] and [RFC5089]). (per the default behavior defined in [RFC5088] and [RFC5089]).
PCEs that set the bit to indicate support of P2MP path computation 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 MUST follow the procedures in Section 3.1.2. (The New P2MP END-POINTS
level of support Object)to further qualify the level of support
3.1.2. Open Message Extension 3.1.2. Open Message Extension
Based on the Capabilities Exchange requirement described in Based on the Capabilities Exchange requirement described in
[PCE-P2MP-REQ]. If a PCE does not advertise its P2MP capability [PCE-P2MP-REQ]. If a PCE does not advertise its P2MP capability
during discovery, PCEP should be used to allow a PCC to discover during discovery, PCEP should be used to allow a PCC to discover
during the Open Message Exhange, which PCEs are capable of during the Open Message Exchange, which PCEs are capable of
supporting P2MP path computation. supporting P2MP path computation.
To satisfy this requirement, we extend the PCEP OPEN object by To satisfy this requirement, we extend the PCEP OPEN object by
defining a new optional TLV to indicate the PCE's capability to defining a new optional TLV to indicate the PCE's capability to
perform P2MP path computations. perform P2MP path computations.
The TLV type number will be assigned by IANA. The length value is 2 The allocation from the "PCEP TLV Type Indicators" sub-registry will
bytes. The value field is set to default value 0. be assigned by IANA and the request is documented in Section 6.1.
(PCEP TLV Type Indicators). The description is "P2MP capable", 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 The inclusion of this TLV in an OPEN object indicates that the sender
can perform P2MP path computations. can perform P2MP path computations.
Note that the capability TLV is meaningful only for a PCE so it will The capability TLV is meaningful only for a PCE so it will typically
typically appear only in one of the two Open messages during PCE appear only in one of the two Open messages during PCE session
session establishment. However, in case of PCE cooperation (e.g., 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 capabilities. it SHOULD also indicate its path computation capabilities.
3.2. Efficient Presentation of P2MP LSPs 3.2. Efficient Presentation of P2MP LSPs
When specifying additional leaves, or optimizing existing P2MP TE When specifying additional leaves, or optimizing existing P2MP TE
LSPs as specified in [PCE-P2MP-REQ], it may be necessary to pass 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 existing P2MP LSP route information between the PCC and PCE in the
request and reply message. In each of these scenarios, we need new request and reply message. In each of these scenarios, we need new
path objects for efficiently passing the existing P2MP LSP between path objects for efficiently passing the existing P2MP LSP between
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Name SERO Name SERO
Object-Type 1: SERO Object-Type 1: SERO
2-15: Unassigned 2-15: Unassigned
Reference This.I-D Reference This.I-D
Object-Class Value 27 Object-Class Value 27
Name SRRO Name SRRO
Object-Type 1: SRRO Object-Type 1: SRRO
2-15: Unassigned 2-15: Unassigned
Reference This.I-D Reference This.I-D
The request is referenced in the IANA Considerations section of this The IANA request is referenced in Section 6.5. (PCEP Objects).
document.
Since the explicit path is available for immediate signaling by the Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects 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. and fields in this object are identical to those defined for the ERO.
3.3. P2MP Path Computation Request/Reply Message Extensions 3.3. P2MP Path Computation Request/Reply Message Extensions
This document extends the existing P2P RP (Request Parameters) object This document extends the existing P2P RP (Request Parameters) object
so that a PCC can signal a P2MP path computation request to the PCE 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 receiving the PCEP request. The END-POINT object is also extended
skipping to change at page 8, line 34 skipping to change at page 8, line 33
3.3.1. The Extension of the RP Object 3.3.1. The Extension of the RP Object
The PCE path computation request and reply message will need the The PCE path computation request and reply message will need the
following additional parameters to allow a receiving PCE to following additional parameters to allow a receiving PCE to
identify that the request and reply message has been fragmented identify that the request and reply message has been fragmented
across multiple messages, has been requested for a P2MP path and to across multiple messages, has been requested for a P2MP path and to
specify if the route is represented in the compressed or uncompressed specify if the route is represented in the compressed or uncompressed
format. format.
This document adds the following flags to the RP Object:
The F bit is added to the flag bits of the RP object to indicate 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 to the receiver that the request is part of a fragmented request, or
is not a fragmented request. 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.
This document adds the following flags to the RP Object:
o F ( RP fragmentation bit - 1 bit): o F ( RP fragmentation bit - 1 bit):
0: This indicates that the RP is not fragmented or it is the 0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP. last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not 1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver the last piece of the fragmented RP. The receiver
needs to wait until it receives an RP with the same RP-ID needs to wait for additional fragments until it receives
and with the F bit is set to 0. an RP with the same RP-ID and with the F bit is set to 0.
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.
o N ( P2MP bit - 1 bit): o N ( P2MP bit - 1 bit):
0: This indicates that this is not PCReq/PCRep for P2MP. 0: This indicates that this is not PCReq/PCRep for P2MP.
1: This indicates that this is PCReq or PCRep message for P2MP. 1: This indicates that this is PCReq or PCRep message for P2MP.
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.
o E ( ERO-compression bit - 1 bit): o E ( ERO-compression bit - 1 bit):
0: This indicates that the route is not in the compressed 0: This indicates that the route is not in the compressed
format. format.
1: This indicates that the route is 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. The IANA request is referenced in Section 6.2 (Request Parameter Bit
Flags) of this document.
3.3.2. The New P2MP END-POINTS Object 3.3.2. The New P2MP END-POINTS Object
The END-POINTS object is used in a PCReq message to specify the The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for source IP address and the destination IP address of the path for
which a path computation is requested. To represent the end points which a path computation is requested. To represent the end points
for a P2MP path efficiently, we define two new types of end-point for a P2MP path efficiently, we define two new types of end-point
objects for the P2MP path: objects for the P2MP path:
o Old leaves whose path can be modified/reoptimized; o Old leaves whose path can be modified/reoptimized;
o Old leaves whose path must be left unchanged. o Old leaves whose path must be left unchanged.
With the new END-POINTS object, the PCE path computation request With the new END-POINTS object, the PCE path computation request
message is expanded in a way which allows a single request message is expanded in a way which allows a single request
message to list multiple destinations. message to list multiple destinations.
In total there are now 4 possible types of leaves in a P2MP request: In total there are now 4 possible types of leaves in a P2MP request:
o New leaves to add; o New leaves to add (leaf type = 1)
o Old leaves to remove; o Old leaves to remove (leaf type = 2)
o Old leaves whose path can be modified/reoptimized; o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o Old leaves whose path must be left unchanged. o Old leaves whose path must be left unchanged (leaf type = 4)
A given END-POINTS object gathers the leaves of a given type. The 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- type of leaf in a given END-POINTS object is identified by the END-
POINTS object leaf type field. POINTS object leaf type field.
Four values are possible for the leaf type field: Using the new END-POINTS object, the END-POINTS portion of a request
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 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 a P2MP path where a single source address has a very large number of
destinations. destinations.
Note that a P2MP path computation request can mix the different types Note that a P2MP path computation request can mix the different types
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 the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format shown in the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format
in following Request Message Formats section (Section 3.4). in Section 3.4. (Request Message Format).
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 11, line 30 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The New P2MP END-POINTS Object Body Format for IPv6 Figure 2: The New P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length. These are multiples The END-POINTS object body has a variable length. These are
of 4 bytes for IPv4, and multiples of 16 bytes for IPv6. multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4
bytes, for IPv6.
3.4. Request Message Format 3.4. Request Message Format
The PCReq message is encoded as follows using RBNF as defined in The PCReq message is encoded as follows using RBNF as defined in
[RFC5511]. [RFC5511].
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>
skipping to change at page 12, line 17 skipping to change at page 11, line 40
<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>]
Figure 3: The Message Format for the Request Message Figure 3: 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 message.
We have requested the additional END-POINTS Object-Types in the IANA We have documented the IANA request for additional END-POINTS
section of this document. Object-Types in Section 6.5 (PCEP Objects) of this document.
3.5. Reply Message Format 3.5. Reply Message Format
The PCReq message is encoded as follows using RBNF as defined in The PCRep message is encoded as follows using RBNF as defined in
[RFC5511]. [RFC5511].
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>]
skipping to change at page 13, line 9 skipping to change at page 12, line 36
The optional END-POINTS in the reply message is used to specify which The optional END-POINTS in the reply message is used to specify which
paths are removed, changed, not changed, or added for the request. paths are removed, changed, not changed, or added for the request.
The path is only needed for the end points which are added or The path is only needed for the end points which are added or
changed. changed.
If the E bit (ERO-Compress bit) was set to 1 in the request then the 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. path will be formed by an ERO followed by a list of SEROs.
Note that we preserve compatibility with the [RFC5440] definition of Note that we preserve compatibility with the [RFC5440] definition of
<response> and the optional <end-point-pair-list> and <path>. <response> and the optional <end-point-path-pair-list> and <path>.
3.6. P2MP Objective Functions and Metric Types 3.6. P2MP Objective Functions and Metric Types
3.6.1. New Objective Functions 3.6.1. New Objective Functions
Six objective functions have been defined in [RFC5541] for P2P path Six objective functions have been defined in [RFC5541] for P2P path
computation. computation.
This document defines two additional objective functions, namely SPT This document defines two additional objective functions, namely SPT
(Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP
skipping to change at page 14, line 17 skipping to change at page 13, line 41
o P2MP TE metric: T=9 (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 o P2MP hop count metric: T=10 (suggested value, to be assigned by
IANA) 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 the RP object, but the PCE is not capable of 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 computation, the PCE MUST send a PCErr message with a PCEP-ERROR
Object and corresponding Error-Value. The original P2MP path Object and corresponding Error-Value. The request MUST then be
computation request MUST then be cancelled. New Error-Types and cancelled at the PCC. New Error-Types and Error-Values are
Error-Values are requested in the IANA Considerations section of requested in Section 6. (IANA Considerations) of this document.
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 Error-value=2
"Unknown RP flag". (capability not supported).
3.8. Non-Support by Back-Level PCE Implementations. 3.8. Non-Support by Back-Level PCE Implementations.
If a PCC inadvertently sends a P2MP request to a PCE which does not If a PCE receives a P2MP request and the PCE does not understand the
support P2MP path computation and therefore the PCEP P2MP extensions, P2MP flag in the RP object, and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request. then the PCE SHOULD reject the request.
3.9. P2MP TE Path Reoptimization Request 3.9. P2MP TE Path Reoptimization Request
A reoptimization request for a P2MP TE path is specified by the use 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 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 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 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 after each type of END-POINTS in the PCReq message, as described in
the Request Message Format section (Section 3.4) of this document. the Request Message Format section (Section 3.4) of this document.
An example of a reoptimization request and subsequent PCReq message An example of a reoptimization request and subsequent PCReq message
is described below: is described below:
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 5: PCReq Message Example 1 for Optimization
In this example, we request reoptimization of the path to all leaves In this example, we request reoptimization of the path to all leaves
without adding or pruning leaves. The reoptimization request would without adding or pruning leaves. The reoptimization request would
use an END-POINT type 3. The RRO list would represent the P2MP LSP use an END-POINT type 3. The RRO list would represent the P2MP LSP
before the optimization and the modifiable path leaves would be before the optimization and the modifiable path leaves would be
indicated in the END-POINTS object. indicated in the END-POINTS object.
It is also possible to specify specific leaves whose path cannot It is also possible to specify specific leaves whose path cannot
be modified. An example of the PCReq message in this scenario would be modified. An example of the PCReq message in this scenario would
be: be:
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)
Figure 7: PCReq Message Example 2 for Optimization Figure 6: 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 3.10. Adding and Pruning Leaves to the P2MP Tree
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, it SHOULD be possible tree, by supplying a list of existing leaves, it SHOULD be possible
to optimize the existing P2MP tree. This section explains the to optimize the existing P2MP tree. This section explains the methods
methods to add new leaves or remove old leaves to the existing to add new leaves or remove old leaves to the existing P2MP tree.
P2MP tree.
To add new leaves the user must build a P2MP request using To add new leaves the user MUST build a P2MP request using
END-POINTS with leaf type 1. END-POINTS with leaf type 1.
To remove old leaves the user must build a P2MP request using To remove old leaves the user must build a P2MP request using
END-POINTS with leaf type 2. END-POINTS with leaf type 2. If no type-2 end-points exist, then the
PCE MUST send an error type 17, value=1: The PCE is not capable to
satisfy the request due to no END-POINTS with leaf type 2.
The PCC must also provide the list of old leaves and indicate if The PCC must also provide the list of old leaves, if any, including
they should be reoptimized or not by including END-POINTS with leaf END-POINTS with leaf type 3, leaf type 4 or both. The error values
type 3, leaf type 4 or both. The error values when the conditions when the conditions are not satisfied (i.e., when there is no
are not satisfied (i.e., when there is no END-POINTS with leaf type END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with
3 or 4, in the presence of END-POINTS with leaf type 1 or 2), are leaf type 1 or 2). A generic "Inconsistent END-POINT" error is also
documented in the IANA Considerations section (Section 6) of this requested if a PCC receives a request that has an inconsistent
document. END-POINT (i.e., if a leaf specified as type 1 already exists). The
The IANA request for all new error values is documented in Section
6.6. (PCEP Error Objects and Types) of this document.
For old leaves the user must provide the old path as a list of RROs For old leaves the user MUST provide the old path as a list of RROs
that immediately follows each END-POINTS object. This document that immediately follows each END-POINTS object. This document
specifies error values when specific conditions are not satisfied. specifies error values when specific conditions are not satisfied.
The following examples demonstrate full and partial reoptimization The following examples demonstrate full and partial reoptimization
of existing P2MP LSPs: of existing P2MP LSPs:
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 1 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 8: Adding Leaves with Full Reoptimization
Case 2: Adding leaves with partial reoptimization of existing paths Case 2: Adding leaves with partial 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 1 END-POINTS for leaf type 1
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)
Figure 9: Adding Leaves with Partial Reoptimization
Case 3: Adding leaves without reoptimization of existing paths Case 3: Adding leaves without 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 1 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 10: Adding Leaves without Reoptimization Case 4: Pruning Leaves with Full Reoptimization
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 11: Pruning Leaves with Full Reoptimization
Case 5: Pruning leaves with partial reoptimization of existing paths Case 5: Pruning leaves with partial 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 2 END-POINTS for leaf type 2
RRO list RRO list
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)
Figure 12: Pruning Leaves with Partial Reoptimization
Case 6: Pruning leaves without reoptimization of existing paths Case 6: Pruning leaves without 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 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 13: Pruning Leaves without Reoptimization
Case 7: Adding and pruning leaves full reoptimization of existing Case 7: Adding and pruning leaves full reoptimization of existing
paths paths
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 14: Adding and Pruning Leaves full Reoptimization
Case 8: Adding and pruning leaves with partial reoptimization of Case 8: Adding and pruning leaves with partial reoptimization of
existing paths 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 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
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 18, line 15 skipping to change at page 17, line 27
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
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)
Figure 15: Adding and Pruning Leaves with Partial
Reoptimization
Case 9: Adding and pruning leaves without reoptimization of existing Case 9: Adding and pruning leaves without reoptimization of existing
paths paths
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
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
3.11. Discovering Branch Nodes 3.11. Discovering Branch Nodes
Before computing the P2MP path, a PCE must be provided means to know Before computing the P2MP path, a PCE may need to be provided means
which nodes in the network are capable of acting as branch LSRs. A to know which nodes in the network are capable of acting as branch
PCE can discover such capabilities by using the mechanisms defined in LSRs. A PCE can discover such capabilities by using the mechanisms
[RFC5073]. defined in [RFC5073].
3.11.1 Branch Node Object 3.11.1 Branch Node Object
The PCC can specify a list of nodes that can be used as branch 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 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 using the a BRANCH NODE Capability (BNC) Object. The BNC Object has
the same format as the IRO object defined in [RFC5440] except that the same format as the IRO object defined in [RFC5440] except that
it only supports IPv4 and IPv6 prefix sub-objects. Two Object- it only supports IPv4 and IPv6 prefix sub-objects. Two Object-
types are also defined: types are also defined:
o Branch node list: List of nodes that can be used as branch o Branch node list: List of nodes that can be used as branch
nodes. nodes.
o Non-branch node list: List of nodes that cannot be used as branch o Non-branch node list: List of nodes that cannot be used as branch
nodes. nodes.
The object can only be carried in a PCReq message. A Path Request The object can only be carried in a PCReq message. A Path Request
may carry at most one BRANCH NODE Object. may carry at most one BRANCH NODE Object.
The Object-Class and Object-types will need to allocated by IANA. The The Object-Class and Object-types will need to allocated by IANA. The
IANA request is documented in Section 6.5. IANA request is documented in Section 6.5. (PCEP Objects).
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 designated backup of synchronized. For example, one P2MP LSP is the designated backup of
another P2MP LSP. In this case, path diversity for these dependent another P2MP LSP. In this case, path diverse for these dependent
LSPs may need 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 using the existing SVEC
functionality. functionality defined in [RFC5440]
An example of synchronizing two P2MP LSPs, each has two leaves for An example of synchronizing two P2MP LSPs, each has two leaves for
Path Computation Request Messages is illustrated as below: Path 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 7: PCReq Message Example for Synchronization
This specification also defines two new flags to the SVEC Object Flag This specification also defines two new flags to the SVEC Object Flag
Field for P2MP path dependent computation requests. The first new Field for P2MP path dependent computation requests. The first new
flag is to allow the PCC to request that the PCE should compute a flag is to allow the PCC to request that the PCE should compute a
secondary P2MP pathtree with partial path diversity for specific secondary P2MP path tree with partial path diverse for specific
leaves or a specific S2L sub-path to the primary P2MP path tree. 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 The second flag, would allow the PCC to request that partial paths
should be link direction diverse. should be link direction diverse.
The following flags are added to the SVEC object body in this The following flags are added to the SVEC object body in this
document: document:
o P ( Partial Path Diverse bit - 1 bit): o P ( Partial Path Diverse bit - 1 bit):
When set this would indicate a request for path diversity When set this would indicate a request for path diverse
for a specific leaf, a set of leaves or all leaves. for a specific leaf, a set of leaves or all leaves.
o D ( Link Direction Diverse bit - 1 bit): o D ( Link Direction Diverse bit - 1 bit):
When set this would indicate a request that a partial path or When set this would indicate a request that a partial path or
paths should be link direction diverse. paths should be link direction diverse.
The IANA request is referenced in Section 6.8 of this document. The IANA request is referenced in Section 6.8. of this document.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
The total PCEP message-length, including the common header, is 16 The total PCEP message-length, including the common header, is 16
bytes. In certain scenarios the P2MP computation request may not fit bytes. In certain scenarios the P2MP computation request may not fit
into a single request or response message. For example, if a tree has into a single request or response message. For example, if a tree has
many hundreds or thousands of leaves. Then the request or response many hundreds or thousands of leaves, then the request or response
may need to be fragmented into multiple messages. may need to be fragmented into multiple messages.
The F bit has been outlined in the Extension of the RP Object section 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 (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 header to signal that the initial request or response was too large
to fit into a single message and will be fragmented into multiple to fit into a single message and will be fragmented into multiple
messages. In order to indentify the single request or response, each messages. In order to identify the single request or response, each
message will use the same request ID. message will use the same request ID.
3.13.1 Request Fragmentation Procedure 3.13.1 Request Fragmentation Procedure
If the initial 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 request over multiple messages. Each 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 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 in the RP object to signify that the request has been fragmented
into multiple messages. In order to indentify that a series of into multiple messages. In order to identify that a series of
request messages represents a single request, each message will request messages represents a single request, each message will
use the same request ID. use the same 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 initial request, a response 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 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 single response message the PCE will split the response over multiple
messages. Each message sent to the PCE, except the last one, will 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 have the F bit set in the RP object to signify that the response
has been fragmented into multiple messages. In order to identify has been fragmented into multiple messages. In order to identify
that a series of response messages represents a single request, that a series of response messages represents a single response,
each message will use the same request ID. each message will use the same response ID.
Again, the assumption is that response messages are reliably Again, the assumption is that response messages are reliably
delivered and in sequence since PCEP relies on TCP. delivered and in sequence since PCEP relies on TCP.
3.13.3 Fragmentation Examples 3.13.3 Fragmentation Examples
The following example illustrates the PCC sending a request message 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 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 with 1200 leaves. The assumption used for this example is that one
hold up to 800 leaves. In this scenario, the original single message request message can hold up to 800 leaves. In this scenario, the
needs to be fragmented and sent using two smaller messages, which original single message needs to be fragmented and sent using two
have the Req-ID1 specified in the RP object, and with the F bit set on smaller messages, which have the Req-ID1 specified in the RP object,
the first message. and with the F bit set on the first message, and cleared on the
second message.
Common Header Common Header
RP1 with Req-ID1 and P2MP flag and F bit set RP1 with Req-ID1 and P2MP=1 and F-bit=1
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
Common Header Common Header
RP2 with Req-ID1 and P2MP flag and F bit cleared RP2 with Req-ID1 and P2MP=1 and F-bit=0
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
Figure 18: PCReq Message Fragmentation Example Figure 8: PCReq Message Fragmentation Example
To handle the scenario that the last fragmented message piece is To handle the scenario that the last fragmented message piece is
lost, the receiver side of the fragmented message may start a timer lost, the receiver side of the fragmented message may start a timer
once it receives the first piece of the fragmented message. When once it receives the first piece of the fragmented message. When
the timer expires and it has not received the last piece of the the timer expires and it has not received the last piece of the
fragmented message, it should send an error message to the sender fragmented message, it should send an error message to the sender
to signal that it has received an incomplete message. to signal that it has received an incomplete message. The relevant
error message is document in Section 3.15. (P2MP PCEP Error Objects
and Types).
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
skipping to change at page 22, line 15 skipping to change at page 21, line 18
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 9: 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 10: UNREACH-DESTINATION Object Body for IPv6
3.15. P2MP PCEP Error Objects and Types 3.15. P2MP PCEP Error Objects and Types
To indicate errors associated with the P2MP path request, a new To indicate an error associated with policy violation, a new error
Error-Type (16) and subsequent error-values are defined as follows value "P2MP Path computation not allowed" should be added to the
for inclusion in the PCEP-ERROR object: existing error code for policy violation (Error-Type=5) as defined
in [RFC5440]:
Error-Type=5; Error-Value=7: 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=7). The
corresponding P2MP path computation request MUST also be cancelled.
To indicate capability 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 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 also be cancelled. corresponding P2MP path computation request MUST also 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 also cancelled. request MUST be also cancelled.
To indicate an error associated with policy violation, a new error To indicate P2MP message fragmentation errors associated with a P2MP
value "P2MP Path computation not allowed" should be added to the path request, a new Error-Type (17) and subsequent error-values are
existing error code for policy violation (Error-Type=5) as defined defined as follows for inclusion in the PCEP-ERROR object:
in [RFC5440]:
Error-Type=5; Error-Value=6: if a PCE receives a P2MP path Error-Type=18; Error-Value=1: if a PCE has not received the last
computation request which is not compliant with administrative piece of the fragmented message, it should send an error message
privileges (i.e., "The PCE policy does not support P2MP path to the sender to signal that it has received an incomplete message
computation"), the PCE MUST send a PCErr message with a PCEP-ERROR (i.e., "Fragmented request failure"), the PCE MUST send a PCErr
Object (Error-Type=5) and an Error-Value (Error-Value=6). The message with a PCEP-ERROR Object (Error-Type=18) and an Error-Value
corresponding P2MP path computation request MUST also be cancelled. (Error-Value=1).
3.16. PCEP NO-PATH Indicator 3.16. PCEP NO-PATH Indicator
To communicate the reasons for not being able to find P2MP path To communicate the reasons 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.
One new bit is defined in the NO-PATH-VECTOR TLV carried in One new bit is defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object: the NO-PATH Object:
bit 24: when set, the PCE indicates that there is a reachability bit 24: when set, the PCE indicates that there is a reachability
skipping to change at page 23, line 51 skipping to change at page 23, line 11
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
PCEP, and most of manageability requirements mentioned in [PCE-P2MP PCEP, and most of manageability requirements mentioned in [PCE-P2MP
P2MP] are already covered there. P2MP] are already covered there.
4.1. Control of Function and Policy 4.1. Control of Function and Policy
In addition to configuration parameters listed in [RFC5440], the In addition to PCE configuration parameters listed in [RFC5440],
following parameters MAY be required. the following additional parameters might be required:
o P2MP path computations enabled or disabled. o The ability to enable to disable P2MP path computations on the
PCE.
o Advertisement of P2MP path computation capability enabled or o The PCE may be configured to enable or disable the advertizement
disabled (discovery protocol, capability exchange). of its P2MP path computation capability. A PCE can advertize its
P2MP capability via the IGP discovery mechanism discussed in
Section 3.1.1. (P2MP Computation TLV in the Existing PCE Discovery
Protocol), or during the Open Message Exchange discussed in
Section 3.1.2. (Open Message Extension).
4.2. Information and Data Models 4.2. Information and Data Models
As described in [PCE-P2MP-REQ], MIB objects MUST be supported for A number of MIB objects have been defined for general PCEP control
PCEP extensions specified in this document. and monitoring of P2P computations in [PCEP-MIB]. [PCE-P2MP-REQ]
specifies that MIB objects will be required to support the control
and monitoring of the protocol extensions defined in this document.
A new document will be required to define MIB objects for PCEP
control and monitoring of P2MP computations.
4.3. Liveness Detection and Monitoring 4.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional [RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements. requirements.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in There are no additional requirements beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional [RFC4657] for verifying the correct operation of the PCEP sessions.
requirements. It is expected that future MIB objects will facilitate verification
of correct operation and reporting of P2MP PCEP requests, responses
and errors.
4.5. Requirements on Other Protocols and Functional Components 4.5. Requirements on Other Protocols and Functional Components
The method for the PCE to obtain information about a PCE capable of The method for the PCE to obtain information about a PCE capable of
P2MP path computations via OSPF and IS-IS is discussed in Section P2MP path computations via OSPF and IS-IS is discussed in Section
3.1.1 (P2MP Computation TLV in the Existing PCE Discovery Protocol) 3.1.1 (P2MP Computation TLV in the Existing PCE Discovery Protocol)
of this document. of this document.
The subsequent IANA requests are documented in Section 6.9 (PCE The subsequent IANA requests are documented in Section 6.9 (PCE
Capability Flag) of this document. Capability Flag) of this document.
4.6. Impact on Network Operation 4.6. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document It is expected that use of PCEP extensions specified in this document
does not have significant impact on network operations. will not significantly increase the level of operational traffic.
However, computing a P2MP tree may require more PCE state compared to
a P2P computation. In the event of a major network failure and
multiple recovery P2MP tree computation requests being sent to the
PCE, the load on the PCE may also be significantly increased.
5. Security Considerations 5. Security Considerations
As described in [PCE-P2MP-REQ], P2MP path computation requests are As described in [PCE-P2MP-REQ], P2MP path computation requests are
more CPU-intensive and also use more link bandwidth. Therefore, it more CPU-intensive and also utilize more link bandwidth. In the
may be more vulnerable to denial of service attacks. Therefore it is event of an unauthorized P2MP path computation request, or denial of
more important that implementations conform to security requirements service attack, the subsequent PCEP requests and processing may be
of [RFC5440], and the implementer utilize those security features. disruptive to the network. Consequently, it is important that
implementations conform to the relevant security requirements of
[RFC5440] that specifically help to minimize or negate unauthorized
P2MP path computation requests and denial of service attacks. These
mechanisms include:
o Securing the PCEP session requests and responses using TCP Security
Techniques (Section 10.2. [RFC5440]).
o Authenticating the PCEP requests and responses to ensure the
message is intact and sent from an authorized node (Section 10.3.
[RFC5440]).
o Providing policy control by explicitly defining which PCCs, via IP
access-lists, are allowed to send P2MP path requests to the PCE
(Section 10.6. [RFC5440]).
PCEP operates over TCP so it is also important to secure the PCE and
PCC against TCP denial of service attacks. Section 10.7.1 of
[RFC5440] outlines a number of mechanisms for minimizing the risk of
TCP based denial of service attacks against PCEs and PCCs.
PCEP implementations SHOULD consider the additional security provided
by TCP-AO [TCP-AUTH].
6. IANA Considerations 6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this considerations have been highlighted in previous sections of this
document. IANA is requested to make the following allocations. document. IANA is requested to make the following allocations.
6.1 P2MP Capability TLV 6.1 PCEP TLV Type Indicators
As described in Section 3.1.2, the newly defined 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. allows the PCE to advertize its P2MP path computation capability.
IANA is requested to make the following allocation from the "PCEP IANA is requested to make the following allocation from the "PCEP
TLV Type Indicators" sub-registry. TLV Type Indicators" sub-registry.
Value Description Reference Value Description Reference
6 P2MP capable This.I-D 6 P2MP capable This.I-D
6.2 Request Parameter Bit Flags 6.2 Request Parameter Bit Flags
As described in Section 3.3.1., three new RP Object Flags have As described in Section 3.3.1., three new RP Object Flags have
skipping to change at page 26, line 7 skipping to change at page 25, line 52
from the "PCEP METRIC Object T Field" sub-registry: from the "PCEP METRIC Object T Field" sub-registry:
Value Description Reference Value Description Reference
8 P2MP IGP metric This.I-D 8 P2MP IGP metric This.I-D
9 P2MP TE metric This.I-D 9 P2MP TE metric This.I-D
10 P2MP hop count metric This.I-D 10 P2MP hop count metric This.I-D
6.5 PCEP Objects 6.5 PCEP Objects
As discussed in Section 3.3.2 two new END-POINTS Object-Types are As discussed in Section 3.3.2., two new END-POINTS Object-Types are
defined. IANA is requested to make the following Object-Type defined. IANA is requested to make the following Object-Type
allocations: allocations from the "PCEP Objects" sub-registry:
Object-Class Value 4 Object-Class Value 4
Name END-POINTS Name END-POINTS
Object-Type 3: IPv4 Object-Type 3: IPv4
4: IPv6 4: IPv6
5-15: Unassigned 5-15: Unassigned
Reference This.I-D Reference This.I-D
As described in Section 3.2, 3.11.1 and 3.14, four PCE As described in Section 3.2., Section 3.11.1. and Section 3.14.,
Object-Classes and six Object-Types have been defined. four PCEP Object-Classes and six PCEP Object-Types have been defined.
IANA is requested to make the following allocations from the "PCEP IANA is requested to make the following allocations from the "PCEP
Objects" sub-registry: Objects" sub-registry:
Object-Class Value 28 Object-Class Value 28
Name UNREACH-DESTINATION Name UNREACH-DESTINATION
Object-Type 1: IPv4 Object-Type 1: IPv4
2: IPv6 2: IPv6
3-15: Unassigned 3-15: Unassigned
Reference This.I-D Reference This.I-D
skipping to change at page 27, line 9 skipping to change at page 26, line 54
As described in Section 3.15., a number of new PCEP-ERROR Object As described in Section 3.15., a number of new PCEP-ERROR Object
Error Types and Values have been defined. IANA is requested to Error Types and Values have been defined. IANA is requested to
make the following allocations from the "PCEP PCEP-ERROR Object make the following allocations from the "PCEP PCEP-ERROR Object
Error Type and Value" sub-registry: Error Type and Value" sub-registry:
Error Error
Type Meaning Reference Type Meaning Reference
5 Policy violation 5 Policy violation
Error-value=6: This.I-D Error-value=7: This.I-D
P2MP Path computation is not allowed P2MP Path computation is not allowed
16 P2MP Error This.I-D 16 P2MP Capability Error This.I-D
Error-Value=0: Unassigned Error-Value=0: Unassigned
Error-Value=1: This.I-D Error-Value=1: This.I-D
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to insufficient memory due to insufficient memory
Error-Value=2: This.I-D Error-Value=2: This.I-D
The PCE is not capable of P2MP computation The PCE is not capable of P2MP computation
17 P2MP Error This.I-D 17 P2MP END-POINTS Error This.I-D
Error-Value=0: Unassigned Error-Value=0: Unassigned
Error-Value=1: This.I-D Error-Value=1: This.I-D
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 2 due to no END-POINTS with leaf type 2
Error-Value=2: This.I-D Error-Value=2: This.I-D
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3 due to no END-POINTS with leaf type 3
Error-Value=3: This.I-D Error-Value=3: This.I-D
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4 due to no END-POINTS with leaf type 4
Error-Value=4: This.I-D
The PCE is not capable to satisfy the request
due to inconsistent END-POINTS
18 P2MP Fragmentation Error This.I-D
Error-Value=0: Unassigned
Error-Value=1: This.I-D
Fragmented request failure
6.7 PCEP NO-PATH Indicator 6.7 PCEP NO-PATH Indicator
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field
has been defined. IANA is requested to make the following has been defined. IANA is requested to make the following
allocation from the "PCEP NO-PATH-VECTOR TLV Flag Field" allocation from the "PCEP NO-PATH-VECTOR TLV Flag Field"
sub-registry: sub-registry:
Bit Description Reference Bit Description Reference
24 P2MP Reachability Problem This.I-D 24 P2MP Reachability Problem This.I-D
6.8 SVEC Object Flag 6.8 SVEC Object Flag
As discussed in Section 3.12, two new SVEC Object Flags are As discussed in Section 3.12, two new SVEC Object Flags are
defined. IANA is requested to make the following defined. IANA is requested to make the following
allocation from the "PCEP SVEC Object Flag Field" sub-registry: allocation from the "PCEP SVEC Object Flag Field" sub-registry:
Bit Description Reference Bit Description Reference
24 Partial Path Diverse This.I-D 19 Partial Path Diverse This.I-D
25 Link Direction Diverse This.I-D 20 Link Direction Diverse This.I-D
6.9 PCE Capability Flag 6.9 PCE Capability Flag
As discussed in Section 3.1, a new OSPF Capability Flag is defined As discussed in Section 3.1, a new OSPF Capability Flag is defined
to indicate P2MP path computation capability. IANA is requested to to indicate P2MP path computation capability. IANA is requested to
make the assignment from the "OSPF Parameters Path Computation make the assignment from the "OSPF Parameters Path Computation
Element (PCE) Capability Flags" registry: Element (PCE) Capability Flags" registry:
Bit Description Reference Bit Description Reference
10 P2MP path computation This.I-D 10 P2MP path computation This.I-D
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, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh
Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas
Manral for their valuable comments and input on this draft. Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David
Harrington and Sean Turner for their valuable comments and input
on this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol "Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009. (PCEP)", RFC 5440, March 2009.
skipping to change at page 29, line 47 skipping to change at page 29, line 52
MPLS and GMPLS Traffic Engineering (TE)" RFC 5671, MPLS and GMPLS Traffic Engineering (TE)" RFC 5671,
October 2009. October 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-05 (work in progress), draft-ietf-pce-p2mp-req-05 (work in progress),
December 2009. December 2009.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and King, D.,
J., "Policy-Enabled Path Computation Framework", "PCE communication protocol(PCEP) Management
RFC 5394, December 2008. Information Base", draft-ietf-pce-pcep-mib-01 (work in
progress), March 2010.
[RFC4657] J. Ash, J.L Le Roux et al., " Path Computation Element
(PCE) Communication Protocol Generic Requirements", RFC
4657, September 2006.
[TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11
(work in progress), March 2010.
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
 End of changes. 114 change blocks. 
225 lines changed or deleted 282 lines changed or added

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