draft-ietf-pce-pcep-p2mp-extensions-04.txt   draft-ietf-pce-pcep-p2mp-extensions-05.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, Ed.
Expires: February 19, 2010 Old Dog Consulting Created: October 25, 2009 Old Dog Consulting
August 18, 2009 Expires: March 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-04.txt draft-ietf-pce-pcep-p2mp-extensions-05.txt
Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs.
This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs.
Status of this Memo 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 2, line 17 skipping to change at page 2, line 28
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs.
This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs.
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. P2MP Computation 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. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .
3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . .7 3.3. P2MP Path Computation Request/Reply Message Extensions . .
3.3. P2MP Path Computation Request/Reply Message Extensions . .7 3.3.1. The Extension of the RP Object . . . . . . . . . . . .
3.3.1. The Extension of RP Object . . . . . . . . . . . . . .7 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .8 3.4. Request Message Format . . . . . . . . . . . . . . . . . .
3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .
3.4. Request Message Formats . . . . . . . . . . . . . . . . .10 3.6. P2MP Objective Functions and Metric Types . . . . . . . .
3.5. Reply Message Formats . . . . . . . . . . . . . . . . . .11 3.6.1. New Object Functions . . . . . . . . . . . . . . . . .
3.6. P2MP Objective Functions and Metric Types . . . . . . . .12 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .
3.6.1. New Object Functions . . . . . . . . . . . . . . . . .12 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .
3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .13 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .
3.8. Non-Support by Back-Level PCE Implementations. . . . . . .13 3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .
3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . .13 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .
3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . .14 3.12. Synchronization of P2MP TE Path Computation Requests . . .
3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . .17 3.13. Request and Response Fragmentation . . . . . . . . . . . .
3.12. Synchronization of P2MP TE Path Computation Requests . . .17 3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .
3.13. Request and Response Fragmentation . . . . . . . . . . . .19 3.13.2 Response Fragmentation Procedure . . . . . . . . . . .
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .19 3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .
3.13.2 Response Fragmentation Procedure . . . . . . . . . . .19 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .19 3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .
3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .20 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .
3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .21 4. Manageability Considerations . . . . . . . . . . . . . . . . .
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .22 4.1. Control of Function and Policy . . . . . . . . . . . . . .
4. Manageability Considerations . . . . . . . . . . . . . . . . .22 4.2. Information and Data Models . . . . . . . . . . . . . . .
4.1. Control of Function and Policy . . . . . . . . . . . . . .23 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .
4.2. Information and Data Models . . . . . . . . . . . . . . .23 4.4. Verifying Correct Operation . . . . . . . . . . . . . . .
4.3. Liveness Detection and Monitoring . . . . . . . . . . . .23
4.4. Verifying Correct Operation . . . . . . . . . . . . . . .23
4.5. Requirements on Other Protocols and Functional 4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . .23 Components . . . . . . . . . . . . . . . . . . . . . . . .
4.6. Impact on Network Operation . . . . . . . . . . . . . . .23 4.6. Impact on Network Operation . . . . . . . . . . . . . . .
5. Security Considerations . . . . . . . . . . . . . . . . . . .23 5. Security Considerations . . . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
6.1 P2MP Capability TLV . . . . . . . . . . . . . . . . . . .24 6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .
6.2 Object Functions . . . . . . . . . . . . . . . . . . . . .24 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .
6.3 Metric Object Types . . . . . . . . . . . . . . . . . . .24 6.3. Object Function . . . . . . . . . . . . . . . . . . . . .
6.4 UNREACH_DESTINATION objects . . . . . . . . . . . . . . .24 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .
6.5 P2MP PCEP Error Objects and Types . . . . . . . . . . . .24 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .
6.6 SERO and SRO Object-Class . . . . . . . . . . . . . . . .25 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .25 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .25
8.1. Normative References . . . . . . . . . . . . . . . . . . .25
8.2. Informative References . . . . . . . . . . . . . . . . . .26
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .26
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .27
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .27
1. Introduction 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1. Normative References . . . . . . . . . . . . . . . . . . .
8.2. Informative References . . . . . . . . . . . . . . . . . .
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .
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.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 results from the PCE to determine the path of LSRs using computation results from the PCE to determine the path of
a P2MP TE LSP. 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.).
P2MP: Point-to-Multipoint. P2MP: Point-to-Multipoint.
P2P: Point-to-Point. P2P: Point-to-Point.
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 PCEP requirements specific to Point to
Multipoint as described in [PCE-P2MP-REQ].
R1: Indication of P2MP Path Computation Request.
R2: Indication of P2MP Objective Functions.
R3: Non-Support of P2MP Path Computation. This section summarizes the PCC-PCE Communication Requirements for
P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]:
R4: Non-Support by Back-Level PCE Implementations. 1. Indication of P2MP Path Computation Request
R5: Specification of Destinations. 2. Indication of P2MP Objective Functions
R6: Indication of P2MP Paths. 3. Non-Support of P2MP Path Computation.
R7: Multi-Message Requests and Responses. 4. Non-Support by Back-Level PCE Implementations.
R8: Non-Specification of Per-Destination Constraints and Parameters. 5. Specification of Destinations
R9: Path Modification and Path Diversity. 6. Indication of P2MP Paths
R10: Reoptimization of P2MP TE LSPs. 7. Multi-Message Requests and Responses
R11: Addition and Removal of Destinations from Existing Paths. 8. Non-Specification of Per-Destination Constraints and Parameters
R12: Specification of Applicable Branch Nodes. 9. Path Modification and Path Diversity
R13: Capabilities Exchange. 10. Reoptimization of P2MP TE LSPs
The following additional requirements have also been identified: 11. Addition and Removal of Destinations from Existing Paths
R14: The PCC should be able to request a PCE to compute secondary 12. Specification of Applicable Branch Nodes
P2MP path tree with partial path diversity for specific leaves or a 13. Capabilities Exchange
specific S2L sub-path.
R15: Sender of the request message can specify if the return result 14. Path-Tree Diversity
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 section describe 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 the Requirements section
(section 2). (Section 2) of this document.
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. P2MP Computation TLV in the Existing PCE Discovery Protocol
Since [RFC5088] has specified that we cannot add an additional Since [RFC5088] has specified that we cannot add an additional
sub-TLV to the PCEP TLV, we will define s new bit to go in the sub-TLV (type-length-value) to the PCEP TLV, we will define a new
existing 32 bit PCE capabilities flags to indicate the capability bit to go in the existing 32 bit PCE capabilities flags to indicate
of P2MP computation. the capability 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
P2MP-REQ], if a PCE does not advertise its P2MP capability during [PCE-P2MP-REQ], if a PCE does not advertise its P2MP capability
discovery and the PCC does not have an alternative PCE capable of during discovery, PCEP should be used to allow a PCC to discover
P2MP computation. We need to use PCEP to allow a PCC to discover which PCEs are capable of supporting P2MP path computation.
which PCEs with which it communicates support P2MP path
computation. To satisfy this requirement, we extend the OPEN
object format by including a new defined TLV for the capability of
P2MP in the optional field. The new defined capability TLV allows
the PCE to advertise its P2MP path computation capability.
The TLV type number will be assigned by IANA, the LENGTH value is 2 To satisfy this requirement, we extend the OPEN object format by
bytes. The value field is set to default value 0. including a new defined TLV for the capability of P2MP in the
optional field. The new defined capability TLV allows the PCE to
advertise its P2MP path computation capability.
The TLV type number will be assigned by IANA and is requested in the
IANA Considerations section (Section 6) of this document. The length
value is 2 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 capabilities. it SHOULD also indicate its path computation capabilities.
3.2. P2MP LSPs Efficient Presentation 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], we need to pass existing LSPs as specified in [PCE-P2MP-REQ], it may be necessary to pass
P2MP LSP route information between the PCC and PCE in the request and existing P2MP LSP route information between the PCC and PCE in the
reply message. In each of these scenarios, we need new path request and reply message. In each of these scenarios, we need new
objects for efficiently passing the existing P2MP LSP between path objects for efficiently passing the existing P2MP LSP between
the PCE and PCC. the PCE and PCC.
We specify the use of the Explicit Route Object (ERO) We specify the use of the Explicit Route Object (ERO)
to encode the explicit route of a TE LSP through the network. The to encode the explicit route of a TE LSP through the network. The
Secondary Explicit Route object (SERO) is used to specify the Secondary Explicit Route Object (SERO) is used to specify the
explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and
Secondary Reported Route Object (SERO) are used to report Secondary Reported Route Object (SERO) are used to report
the routes of existing TE LSP for which a reoptimization is the routes of existing TE LSP for which a reoptimization is
desired. desired. The format and contents of the ERO and RRO are defined in
[RFC5440]. The format and contents of the SERO and SRRO are
The format and contents of the ERO and RRO are defined in [RFC5440]. defined in [RFC4875]. A new class and type are requested for SERO
The format and contents of the SERO and SRRO are defined in and SRRO in the IANA Considerations section of this document.
[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 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 (Request Parameters) object is extended so that
receiver of the PCEP request that it is for P2P or P2MP path it can signal to the receiver of the PCEP request that it is for
computation. Also the END-POINT object is extended to improve the P2P or P2MP path computation. Also the END-POINT object is
efficiency of the message exchange between PCC and PCE in the case extended to improve the efficiency of the message exchange between
of P2MP path computation. PCC and PCE in the case of P2MP path computation.
3.3.1. The Extension of 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 parameter 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, is for a P2MP path and to specify if the across multiple messages, has been requested for a P2MP path and to
route is represented in the compressed format or not. specify if the route is represented in the compressed or uncompressed
format.
The F bit is added to the flag bits of the RP object to indicate 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 to the receiver that the request is part of a fragmented request, or
fragmented request. is not a 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
bit and the E bit is as follows: bit and the E bit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|E|M| |O|B|R| Pri | | Reserved | Flags |F|N|E| |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RP Object Body Format Figure 1: RP Object Body Format
The following flags are added in this draft: The following flags are added in this draft:
o M ( P2MP bit - 1 bit): o F ( RP fragmentation bit - 1 bit):
0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver
needs to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0.
o N ( P2MP bit - 1 bit):
0: This indicates that this is not PCReq/PCRrep for P2MP. 0: This indicates that this is not PCReq/PCRrep 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.
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.
o F ( RP fragmentation bit - 1 bit): 3.3.2. The New P2MP END-POINTS Object
0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver
need to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0.
3.3.2. The New P2MP END-POINTS Object
To represent the end points for a P2MP path efficiently, we define a To represent the end points for a P2MP path efficiently, we define a
new type of end-points object for P2MP path. new type of end-points object for the P2MP path.
With this 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 such that it 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.
There are 4 types of leaves in a P2MP request: There are 4 types of leaves in a P2MP request:
o New leaves to add; o New leaves to add;
o Old leaves to remove; o Old leaves to remove;
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.
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:
So four values are possible for the leaf type field:
1. New leaves to add; 1. New leaves to add;
2. Old leaves to remove; 2. Old leaves to remove;
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 the new END-POINTS object, the END-POINTS portion of a request
message for the multiple destinations can be roughly reduced up to message for the multiple destinations can be reduced by up to 50% for
50% for a P2MP path where a single source address has a very large a P2MP path where a single source address has a very large number of
number of destinations. destinations.
Note that A P2MP path computation request can mix the different type 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 PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in shown in PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in
next section. following Request Message Formats section (Section 3.4).
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 30 skipping to change at page 10, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. These are multiples
bytes for IPv4 and multiple of 16 bytes for IPv6. of 4 bytes for IPv4, and multiples of 16 bytes for IPv6.
3.4. Request Message Formats 3.4. Request Message Format
As per [RFC5511] the RBNF 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:
skipping to change at page 11, line 20 skipping to change at page 11, line 20
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>] <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<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 Format
As per [RFC5511] the RBNF 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>
skipping to change at page 12, line 10 skipping to change at page 12, line 5
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
Figure 5: The Message Format for the Reply Message Figure 5: The Message Format for the Reply Message
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 ERO-Compress bit was set to 1 in request then the path will be If the ERO-Compress bit was set to 1 in the request then the path
formed by an ERO followed by a list of SERO. Otherwise it is a list will be formed by an ERO followed by a list of SERO. Otherwise it
of ERO. is a list of ERO.
Note 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-pair-list> and <path>.
3.6. P2MP Objective Functions and Metric Types 3.6. P2MP Objective Functions and Metric Types
3.6.1. New Object Functions 3.6.1. New Object 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
path computation. Hence two new objective function codes have to be path computation. Hence two new objective function codes have to be
defined. defined.
The description of the two new objective functions is as follows. The description of the two new objective functions is as follows.
Objective Function Code: 7 (suggested value, to be assigned by IANA) Objective Function Code: 7 (suggested value, to be assigned by IANA)
Name: Shortest Path Tree (SPT) Name: Shortest Path Tree (SPT)
Description: Minimize the maximum source-to-leaf cost with respect to Description: Minimize the maximum source-to-leaf cost with respect to
a specific metric or to the TE metric used as the default metric when 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)
skipping to change at page 12, line 47 skipping to change at page 12, line 41
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: the following values for these new metric types:
o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA) o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA)
o P2MP TE metric: T=9 (suggested value, to be assigned by IANA) o P2MP 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 RP object, but the PCE is not capable of P2MP computation, flag in the RP object, but the PCE is not capable of P2MP
the PCE MUST send a PCErr message with a PCEP-ERROR Object and computation, the PCE MUST send a PCErr message with a PCEP-ERROR
corresponding Error-Value. The original P2MP path Object and corresponding Error-Value. The original P2MP path
computation request MUST then be cancelled. New Error-Types and computation request MUST then be cancelled. New Error-Types and
Error-Values are requested in the IANA Considerations section of Error-Values are requested in the IANA Considerations section 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 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 a PCC inadvertently sends the P2MP request to a PCE which does not If a PCC inadvertently sends a P2MP request to a PCE which does not
support the PCEP P2MP extensions, then it SHOULD reject the request support P2MP path computation and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request,
because it cannot understand the new P2MP 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 Reoptimization Request
The re-optimization request for a P2MP TE path is specified by R bit A reoptimization request for a P2MP TE path is specified by the use
in the RP object similarly to the re-optimization request for a P2P of the R bit within the RP object as defined in [RFC5440] and is
TE path. The only difference is that the user must insert the list similar to the reoptimization request for a P2P TE path. The only
of RRO and SRRO after each type of END-POINTS as described in the difference is that the user must insert the list of RROs and SRROs
PCReq message format section. after each type of END-POINTS in the PCReq message, as described in
the Request Message Format section (Section 3.4) of this document.
So the PCReq message would look like this: An example of a reoptimization request and subsequent PCReq message
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 6: PCReq Message Example 1 for Optimization
In this example, we request re-optimization of path to all leaves In this example, we request reoptimization of path to all leaves
without adding or pruning leaves. That is only one END-POINT of type without adding or pruning leaves. That is only one END-POINT of type
3. The RRO list is representing the P2MP LSP before the optimization 3. The RRO list is representing the P2MP LSP before the optimization
and the modifiable path leaves are indicated in the END-POINTS and the modifiable path leaves are indicated in the END-POINTS
object. object.
Optionally it is possible to specify some leaves whose path cannot be Optionally it is possible to specify specific leaves whose path cannot
modified. The PCReq message would then look like this: be modified. An example of the PCReq message in this scenario would
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 7: PCReq Message Example 2 for Optimization
3.10. Adding/pruning Leaves 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, one may be able to tree, by supplying a list of existing leaves, it SHOULD be possible
optimize the new P2MP tree. This section explains ways to add new to optimize the existing P2MP tree. This section explains the
leaves or remove old leaves to the existing P2MP tree. methods to add new leaves or remove old leaves to the existing
P2MP tree.
To add new leaves the user must build a P2MP request 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 provide the list of old leaves and indicate The PCC must also provide the list of old leaves and indicate if they
if they must be reoptimized or not by including END-POINTS with leaf should be reoptimized or not by including END-POINTS with leaf type 3
type 3 or 4 or both. This document also define error values when the or 4 or both. The error values when the conditions are not
condition is not satisfied (i.e., when there is no END-POINTS with satisfied (i.e., when there is no END-POINTS with leaf type 3 or
leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 4, in the presence of END-POINTS with leaf type 1 or 2), are
or 2). This are documented in the IANA Considerations section. documented in the IANA Considerations section (Section 6) of this
document.
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. 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 cases are possible when modifying an existing P2MP The following examples demonstrate full and partial reoptimization of
LSP: 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 3 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 8: Adding Leaves with Full Reoptimization 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
skipping to change at page 15, line 41 skipping to change at page 15, line 34
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 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 3 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 Figure 10: Adding Leaves without 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 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)
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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 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
skipping to change at page 17, line 36 skipping to change at page 17, line 36
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 Figure 16: Adding and Pruning Leaves without Reoptimization
3.11. 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 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 capabilities by using the mechanisms defined in PCE can discover such capabilities by using the mechanisms defined in
[PCE-P2MP-REQ]. [PCE-P2MP-REQ.
3.11.1 Branch Node Object
The PCC can specify a list of nodes that can be used as branch
nodes or a list of nodes that cannot be used as branch nodes by
using the a BRANCH NODE Capability (BNC) Object. The BNC Object has
the same format as the IRO object defined in [RFC5440] except that
it only supports IPv4 and IPv6 prefix sub-objects. Two Object-
types are also defined:
o Branch node list: List of nodes that can be used as branch
nodes.
o Non-branch node list: List of nodes that cannot be used as branch
nodes.
The object can only be carried in a PCReq message. A Path Request
may carry at most one BRANCH NODE Object.
The Object-Class and Object-types will need to allocated by IANA. The
IANA request is documented in Section 6.5.
3.12. Synchronization of P2MP TE Path Computation Requests 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 two another P2MP LSP. In this case, path diversity 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 just using the existing SVEC
functionality. functionality.
Example of synchronizing two P2MP LSPs, each has two leaves for Path An example of synchronizing two P2MP LSPs, each has two leaves for
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 17: PCReq Message Example for Synchronization
skipping to change at page 18, line 40 skipping to change at page 19, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|P|D| | Reserved | Flags |S|N|L|P|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 | | Request-ID-number #1 |
// // // //
| Request-ID-number #M | | Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SVEC Body Object Format with Additional Flags Figure 19: SVEC Body Object Format with Additional Flags
The following flags are added to the SVEC object body in this draft: The following flags are added to the SVEC object body in this draft:
o P ( Partial Path Diversity bit - 1 bit): o P ( Partial Path Diversity bit - 1 bit):
When set this would indicate a request for partial path When set this would indicate a request for partial path
diversity for a specific leave or set of leaves. diversity for a specific leave or set of 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.
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 P2MP computation request may not fit into a
response message. For example, if a tree has many hundreds or single request or response message. For example, if a tree has many
thousands of leaves. Then the request or response may need to hundreds or thousands of leaves. Then the request or response may
be fragmented into multiple messages. need to 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 the Extension of the RP Object section
Object, of this document. The F bit is used in the RP object header (Section 3.3.1) of this document. The F bit is used in the RP object
to signal that the an initial request or response was too large to header to signal that the initial request or response was too large
fit into a single message and should therefore be fragmented into to fit into a single message and will be fragmented into multiple
multiple requests. In order to indentify the single request or messages. In order to indentify the single request or response, each
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 requst over multiple messages. Each message the PCC will split the request over multiple messages. Each
message sent to the PCE will have the F bit set in the RP object messagesent to the PCE, except the last one, will have the F bit set
to signify that the request has been fragmented into multiple in the RP object to signify that the request has been fragmented
messages. In order to indentify that a series of request messages into multiple messages. In order to indentify that a series of
represents a single request, each message will use the same request messages represents a single request, each message will
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 Once the PCE computes a path based on the initial request, a response
response is sent back to the PCC. If the response is too large to fit is sent back to the PCC. If the response is too large to fit into a
into a single response message the PCE will split the request over single response message the PCE will split the request over multiple
multiple messages. Each message sent to the PCE with the F bit set messages. Each message sent to the PCE, except the last one, will
in the RP object to signify that the response has been fragmented have the F bit set in the RP object to signify that the response
into multiple messages. In order to indentify that a series of has been fragmented into multiple messages. In order to identify
response messages represents a single request, each message will that a series of response messages represents a single request,
use the same request ID. each message will 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
The following example illustrates the request message with Req-ID1, The following example illustrates the PCC sending a request message
which adds one leaf to a 1200 leaves existing tree, is sent to the with Req-ID1 to the PCE, in order to add one leaf to an existing tree
PCE. The assumption is that the one request message can hold up to with 1200 leaves. The assumption is that the one request message can
800 leaves. In these conditions, the original one message needs to be hold up to 800 leaves. In this scenario, the original one message
sent over by two small messages, which have the Req-ID1 specified in needs to be fragmented and sent over by two small messages, which
the RP object and F bit set for the first message. have the Req-ID1 specified in the RP object and F bit set for the
first message.
Common Header Common Header
RP1 with Req-ID1 and P2MP flag and F bit set RP1 with Req-ID1 and P2MP flag and F bit set
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 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 scenario that the last fragmented message piece is
receiver side of the fragmented message may start a timer once it lost, the receiver side of the fragmented message may start a timer
receives the first piece of the fragmented message. When timer expires once it receives the first piece of the fragmented message. When
and it still doesn't receive the last piece of the fragmented message, the timer expires and it has not received the last piece of the
it should send an error message to the receiver to signal that it fragmented message, it should send an error message to the sender
have received an incomplete message. to signal that it has 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.
The following UNREACH-DESTINATION objects will be required:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 48 skipping to change at page 22, line 15
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 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:
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 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 cancelled. request MUST be also 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 the
existing error code for policy violation (Error-Type=5) as defined existing error code for policy violation (Error-Type=5) as defined
in [RFC5440]: in [RFC5440]:
Error-Type=5; Error-Value=6: 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 MUST send a PCErr message with a PCEP-ERROR
(Error-Type=5) and an Error-Value (Error-Value=6). The corresponding Object (Error-Type=5) and an Error-Value (Error-Value=6). The
P2MP path computation request MUST be cancelled. corresponding P2MP path computation request MUST also 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 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.
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 22: 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 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 0x24: 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 destination or list of destinations that are
using the new UNREACH-DESTINATION object defined in section 3.6. not reachable 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 23, line 41 skipping to change at page 24, line 8
4.5. Requirements on Other Protocols and Functional Components 4.5. Requirements on Other Protocols and Functional Components
As described in [PCE-P2MP-REQ], the PCE MUST obtain information As described in [PCE-P2MP-REQ], the PCE MUST obtain information
about the P2MP signaling and branching capabilities of each LSR in about the P2MP signaling and branching capabilities of each LSR in
the network. the network.
Protocol extensions specified in this document does not provide such Protocol extensions specified in this document does not provide such
capability. Other mechanisms MUST be present. capability. Other mechanisms MUST be present.
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) is used to
advertise capabilities to PCCs. A new flag (value=10) could be
defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation
capability. Extensions for PCE discovery are out of scope of this
document.
4.6. Impact on Network Operation 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. does not have significant impact on network operations.
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 use more link bandwidth. Therefore, it
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 implementer utilize those security features
6. IANA Considerations 6. IANA Considerations
A number of IANA considerations have been highlighted in previous IANA maintains a registry of PCEP parameters. A number of IANA
sections of this document. In summary, IANA is requested to make considerations have been highlighted in previous sections of this
allocations for the following PCEP parameters. document. IANA is requested to make the following allocations.
6.1 P2MP Capability TLV 6.1 P2MP Capability TLV
The new defined P2MP capability TLV allows the PCE to advertise As described in Section 3.1.2, the newly defined P2MP capability TLV
its P2MP path computation capability. The LENGTH value is 2 allows the PCE to advertize its P2MP path computation capability.
bytes. The value field is set to default value 0. IANA is requested to make the following allocation from the "PCEP
TLV Type Indicators" sub-registry.
6.2 Object Functions Value Description Reference
6 P2MP capability This.I-D
Objective Function Code: 7 (suggested value) 6.2 Request Parameter Bit Flags
Name: Shortest Path Tree (SPT)
Objective Function Code: 8 (suggested value) As described in Section 3.3.1., three new RP Object Flags have
Name: Minimum Cost Tree (MCT) been defined. IANA is requested to make the following allocations
from the "RP Object Flag Field" Sub-Registry:
6.3 Metric Object Types Bit Description Reference
P2MP IGP metric: T=8 (suggested value) 18 Fragmentation(F-bit) This.I-D
P2MP TE metric: T=9 (suggested value) 19 P2MP (N-bit) This.I-D
P2MP hop count metric: T=10 (suggested value) 20 ERO-compression (E-bit) This.I-D
6.4 UNREACH_DESTINATION Objects 6.3 Objective Function
UNREACH_DESTINATION Object-Class As described in Section 3.6.1., two new Objective Funtions have been
UNREACH_DESTINATION Object-Type for IPv4 defined. IANA is requested to make the following allocations
UNREACH_DESTINATION Object-Type for IPv6 from the "Objective Function" sub-registry:
6.5 P2MP PCEP Error Objects and Types Code Point Name Reference
To indicate errors associated with the P2MP path request, one new 7 SPT This.I-D
Error-Type 5 Error-Value and two new Error-Types (16) and 8 MCT This.I-D
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 6.4 Metric Object Types
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 As described in Section 3.6.2., three new metric object T fields have
the request due to insufficient memory. been defined. IANA is requested to make the following allocations
from the "METRIC Object T Field" sub-reigstry:
Error-Type=16 and Error-Value=2: The PCE is not capable of P2MP Value Description Reference
computations.
Additionally a new Error-Type and corresponding values will be needed 8 P2MP IGP metric This.I-D
to report reoptimization requests that fail due to END-POINT 9 P2MP TE metric This.I-D
leaf type failures. These are: 10 P2MP hop count metric This.I-D
Error-Type=17 and Error-Value=1: The PCE is not capable to satisfy 6.5 PCEP Objects
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 As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have
the request due to no END-POINTS with leaf type 3. been defined. IANA is requested to make the following allocations
from the "PCEP Objects" sub-registry
Error-Type=17 and Error-Value=2: The PCE is not capable to satisfy Object-Class Value 25
the request due to no END-POINTS with leaf type 4. Name UNREACH-DESTINATION
Object-Type 1: IPv4
2: IPv6
3-15: Unassigned
Reference This.I-D
6.6 SERO and SRO Object-Class Object-Class Value 26
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference This.I-D
Object-Class Value 27
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference This.I-D
SERO Object-Class is 25 (suggested value) Object-Class Value 28
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference This.I-D
SERO Object-Type is 1 (suggested value). 6.6 PCEP Error Objects and Types
SSRO Object-Class is 26 (suggested value). As described in Section 3.15., a number of new PCEP-ERROR Object
Error Types and Values have been defined. IANA is requested to
make the following allocations from the "PCEP-ERROR Object Error
Type and Value" sub-registry:
SSRO Object-Type is 1 (suggested value). Error
Type Meaning Reference
5 Policy violation
Error-value=6: This.I-D
P2MP Path computation is not allowed
16 P2MP Error This.I-D
Error-Value=0: Unassigned
Error-Value=1: This.I-D
The PCE is not capable to satisfy the request
due to insufficient memory
Error-Value=2: This.I-D
The PCE is not capable of P2MP computation
17 P2MP Error This.I-D
Error-Value=0: Unassigned
Error-Value=1: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 2
Error-Value=2: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3
Error-Value=3: This.I-D
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4
6.7 PCEP NO-PATH Indicator
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field
has been defined. IANA is requested to make the following
allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry:
Bit Description Reference
24 P2MP Reachability Problem This.I-D
7. Acknowledgements 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, 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
[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 26, line 14 skipping to change at page 27, line 42
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
[RFC5541] [RFC5541]
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
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-02.txt", "draft-ietf-pce-p2mp-app-02.txt",
draft-ietf-pce-p2mp-app-02 (work in progress), draft-ietf-pce-p2mp-app-02 (work in progress),
August 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-01 (work in progress), draft-ietf-pce-p2mp-req-03 (work in progress),
February 2008. October 2009.
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
skipping to change at page 27, line 4 skipping to change at page 28, line 41
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 (editor) 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
Thales Communication France
160 Bd Valmy 92700 Colombes
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
Zafar Ali Zafar Ali
Cisco systems, Inc. Cisco systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: zali@cisco.com Email: zali@cisco.com
Julien Meuric Julien Meuric
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
skipping to change at page 28, line 18 skipping to change at page 30, line 10
o Redistributions in binary form must reproduce the above copyright o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the documentation and/or other materials provided with the
distribution. distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written products derived from this software without specific prior written
permission. permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Below is the message format for the request message: 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>
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
 End of changes. 129 change blocks. 
321 lines changed or deleted 418 lines changed or added

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