draft-ietf-pce-pcep-p2mp-extensions-06.txt   draft-ietf-pce-pcep-p2mp-extensions-07.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.
Created: December 30, 2009 Old Dog Consulting Created: February 2, 2010 Old Dog Consulting
Expires: May 1, 2010 Expires: August 2, 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-06.txt draft-ietf-pce-pcep-p2mp-extensions-07.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 2, line 7 skipping to change at page 2, line 7
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 May 1, 2010. This Internet-Draft will expire on May 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
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)
the copyright in such materials, this document may not be modified controlling the copyright in such materials, this document may not
outside the IETF Standards Process, and derivative works of it may be modified outside the IETF Standards Process, and derivative works
not be created outside the IETF Standards Process, except to format of it may not be created outside the IETF Standards Process, except
it for publication as an RFC or to translate it into languages other to format it for publication as an RFC or to translate it into
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. P2MP Computation 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. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7
3.3. P2MP Path Computation Request/Reply Message Extensions . . 3.3. P2MP Path Computation Request/Reply Message Extensions . .8
3.3.1. The Extension of the RP Object . . . . . . . . . . . . 3.3.1. The Extension of the RP Object . . . . . . . . . . . .8
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .9
3.4. Request Message Format . . . . . . . . . . . . . . . . . . 3.4. Request Message Format . . . . . . . . . . . . . . . . . .11
3.5. Reply Message Format . . . . . . . . . . . . . . . . . . . 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .12
3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . .13
3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.1. New Objective Functions . . . . . . . . . . . . . . .13
3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .14
3.8. Non-Support by Back-Level PCE Implementations. . . . . . . 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .14
3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . . 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .14
3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . . 3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .15
3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . . 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .18
3.12. Synchronization of P2MP TE Path Computation Requests . . . 3.11.1 Branch Node Object . . . . . . . . . . . . . . . . . .18
3.13. Request and Response Fragmentation . . . . . . . . . . . . 3.12. Synchronization of P2MP TE Path Computation Requests . . .19
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . . 3.13. Request and Response Fragmentation . . . . . . . . . . . .20
3.13.2 Response Fragmentation Procedure . . . . . . . . . . . 3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .20
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . . 3.13.2 Response Fragmentation Procedure . . . . . . . . . . .20
3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . . 3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .20
3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .21
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 3.15. P2MP PCEP Error Object and Types . . . . . . . . . . . . .22
4. Manageability Considerations . . . . . . . . . . . . . . . . . 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .23
4.1. Control of Function and Policy . . . . . . . . . . . . . . 4. Manageability Considerations . . . . . . . . . . . . . . . . .23
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 . . . . . . . . . . . . . . .24
4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .24
4.4. Verifying Correct Operation . . . . . . . . . . . . . . .24
4.5. Requirements on Other Protocols and Functional 4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . Components . . . . . . . . . . . . . . . . . . . . . . . .24
4.6. Impact on Network Operation . . . . . . . . . . . . . . . 4.6. Impact on Network Operation . . . . . . . . . . . . . . .24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . .24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .25
6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . . 6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .25
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25
6.3. Object Function . . . . . . . . . . . . . . . . . . . . . 6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .26
6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . . 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27
7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .27
7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . .27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . .29
8.2. Informative References . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .29
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .29
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .30
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .
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 4, line 34 skipping to change at page 4, line 26
The PCE has been identified as a suitable application for the The PCE has been identified as a suitable application for the
computation of paths for P2MP TE LSPs [RFC5671]. computation of paths for P2MP TE LSPs [RFC5671].
The PCE communication protocol (PCEP) is designed as a communication The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path specification does not provide a mechanism to request path
computation of P2MP TE LSPs. computation of P2MP TE LSPs.
This document presents extensions to PCEP to support P2MP path A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
computation satisfying the set of requirements described in [PCE- These S2L sub-LSPs are set up between ingress and egress LSRs and are
P2MP-REQ]. appropriately overlaid to construct a P2MP TE LSP. During path
computation, the P2MP TE LSP may be determined as a set of S2L sub-
This document relies on the mechanisms of PCEP for requesting path LSPs that are computed separately and combined to give the path of
computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between tree in a single computation.
ingress and egress LSRs and are appropriately combined by the branch
LSRs using computation results from the PCE to determine the path of
a P2MP TE LSP.
One request message from a PCC may signal one or more S2L sub-LSP This document relies on the mechanisms of PCEP to request path
path computation requests to the PCE for a single P2MP LSP with computation for P2MP TE LSPs. One path computation request message
certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP from a PCC may request the computation of the whole P2MP TE LSP, or
can use one path computation request message or be split across the request may be limited to a sub-set of the S2L sub-LSPs. In the
multiple path computation messages. extreme case, the PCC may request the S2L sub-LSPs to be computed
individually with it being the PCC's responsibility to decide whether
to signal individual S2L sub-LSPs or combine the computation results
to signal the entire P2MP TE LSP. Hence the PCC may use one path
computation request message or may split the request across multiple
path computation messages.
1.1 Terminology 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 Switching Router.
OF: Objective Function: A set of one or more optimization criterion OF: Objective Function: A set of one or more optimization criteria
(criteria) used for the computation of a single path (e.g. path cost used for the computation of a single path (e.g., path cost
minimization), or the synchronized computation of a set of paths minimization), or for the synchronized computation of a set of paths
(e.g. aggregate bandwidth consumption minimization, etc.). (e.g., aggregate bandwidth consumption minimization).
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 PCC-PCE Communication Requirements for This section summarizes the PCC-PCE Communication Requirements for
P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]: P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system
corresponds to the requirement numbers used in [PCE-P2MP-REQ].
1. Indication of P2MP Path Computation Request 1. Indication of P2MP Path Computation Request.
2. Indication of P2MP Objective Functions 2. Indication of P2MP Objective Functions.
3. Non-Support of P2MP Path Computation. 3. Non-Support of P2MP Path Computation.
4. Non-Support by Back-Level PCE Implementations. 4. Non-Support by Back-Level PCE Implementations.
5. Specification of Destinations 5. Specification of Destinations.
6. Indication of P2MP Paths 6. Indication of P2MP Paths.
7. Multi-Message Requests and Responses 7. Multi-Message Requests and Responses.
8. Non-Specification of Per-Destination Constraints and Parameters 8. Non-Specification of Per-Destination Constraints and Parameters.
9. Path Modification and Path Diversity 9. Path Modification and Path Diversity.
10. Reoptimization of P2MP TE LSPs 10. Reoptimization of P2MP TE LSPs.
11. Addition and Removal of Destinations from Existing Paths 11. Addition and Removal of Destinations from Existing Paths.
12. Specification of Applicable Branch Nodes.
12. Specification of Applicable Branch Nodes
13. Capabilities Exchange 13. Capabilities Exchange
14. Path-Tree Diversity 14. Path-Tree Diversity
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 the Requirements section
(Section 2) of this document. (Section 2) 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
Since [RFC5088] has specified that we cannot add an additional [RFC5088] defines a PCE Discovery (PCED) TLV carried in an an OSPF
sub-TLV (type-length-value) to the PCEP TLV, we will define a new Router Information LSA defined in [RFC4970] to facilitate PCE
bit to go in the existing 32 bit PCE capabilities flags to indicate discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be
the capability of P2MP computation. added to the PCED TLV, so this document defines a new flag in the
PCE-CAP-FLAGS sub-TLV of the PCED TLV to indicate the capability of
P2MP computation.
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
Discovery using IS-IS. This document defines a new flag in the
PCE-CAP-FLAGS sub-TLV of the PCED sub-TLV to indicate the capability
of P2MP computation.
The PCE-CAP-FLAGS sub-TLV uses a common codepoint registry for OSPF
and IS-IS PCE discovery.
PCEs wishing to advertise that they support P2MP path computation set
bit 10 (TBA by IANA) in the PCE-CAP-FLAGS sub-TLV. PCCs that do not
understand this bit will ignore it (per [RFC5088] and [RFC5089]).
PCEs that do not support P2MP will leave the bit clear (per the
default behavior defined in [RFC5088] and [RFC5089]).
PCEs that set the bit to indicate support of P2MP path computation
MUST follow the procedures in Section 3.1.2 to further qualify the
level of support
3.1.2. Open Message Extension 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
which PCEs are capable of supporting P2MP path computation. which PCEs are capable of supporting P2MP path computation.
To satisfy this requirement, we extend the OPEN object format by To satisfy this requirement, we extend the PCEP OPEN object by
including a new defined TLV for the capability of P2MP in the defining a new optional TLV to indicate the PCE's capability to
optional field. The new defined capability TLV allows the PCE to perform P2MP path computations.wait, I lie,
advertise its P2MP path computation capability. The TLV type number is TBA by IANA. The length value is 2 bytes.
The value field is set to default value 0.
The TLV type number will be assigned by IANA and is requested in the The inclusion of this TLV in an OPEN object indicates that the sender
IANA Considerations section (Section 6) of this document. The length can perform P2MP path computations.
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. 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
the PCE and PCC. the PCE and PCC.
We specify the use of the Explicit Route Object (ERO) We specify the use of the Reservation Protocol Traffic Engineering
to encode the explicit route of a TE LSP through the network. The Extensions (RSVP-TE)Explicit Route Object (ERO) to encode the
Secondary Explicit Route Object (SERO) is used to specify the explicit route of a TE LSP through the network. PCEP ERO sub-object
explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and types correspond to RSVP-TE ERO sub-object types. The format and
Secondary Reported Route Object (SERO) are used to report content of the ERO object are defined in [RFC3209] and [RFC3473].
the routes of an existing TE LSP for which a reoptimization is
desired. The format and contents of the ERO and RRO are defined in The Secondary Explicit Route Object (SERO) is used to specify the
[RFC5440]. The format and contents of the SERO and SRRO are explicit route of a S2L sub-LSP. The path of each subsequent S2L
defined in [RFC4875]. A new class and type are requested for SERO sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO.
and SRRO in the IANA Considerations section of this document. The format of the SERO is the same as an ERO defined in [RFC3209]
and [RFC3473].
The Secondary Recorded Route Object (SRRO) is used to record
the explicit route of the S2L sub-LSP. The class of the P2MP SRRO
is the same as the SRRO defined in [RFC4873].
The SERO and SRRO are used to report the route of an existing TE
LSP for which a reoptimization is desired. The format and content
of the SERO and SRRO are defined in [RFC4875].
A new PCEP object class and type are requested for SERO and SRRO.
Object-Class Value 26
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference This.I-D
Object-Class Value 27
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference This.I-D
The request is referenced in the IANA Considerations section of this
document.
Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO.
3.3. P2MP Path Computation Request/Reply Message Extensions 3.3. P2MP Path Computation Request/Reply Message Extensions
The existing P2P RP (Request Parameters) object has been extended so This document extends the existing P2P RP (Request Parameters) object
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
to improve the efficiency of the message exchange between PCC and PCE to improve the efficiency of the message exchange between PCC and PCE
in the case of P2MP path computation. in the case of P2MP path computation.
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
skipping to change at page 7, line 46 skipping to change at page 9, line 5
The N bit is added in the flag bits field of the RP object to signal 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 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 compressed 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 format or not. By default, the path returned by the PCE will use the
compressed format. compressed format.
The extended format of the RP object body to include the F bit, N This document adds the following flags to the RP Object:
bit and the E bit is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|N|E| |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RP Object Body Format
The following flags are added in this draft:
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 and the receiver
needs to wait until it receives an RP with the same RP-ID needs to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0. and with the F bit is set to 0.
skipping to change at page 8, line 44 skipping to change at page 9, line 30
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.
The IANA request is referenced in Section 6.2 of this document.
3.3.2. The New P2MP END-POINTS Object 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 the P2MP path. new type of end-points object for the P2MP path.
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.
There are 4 types of leaves in a P2MP request: There are 4 types of leaves in a P2MP request:
skipping to change at page 9, line 49 skipping to change at page 10, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The New P2MP END-POINTS Object Body Format for IPv4 Figure 1: The New P2MP END-POINTS Object Body Format for IPv4
The format of the END-POINTS object body for IPv6 (Object-Type 4) is The format of the END-POINTS object body for IPv6 (Object-Type 4) is
as follows: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 10, line 28 skipping to change at page 11, line 28
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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 multiples
of 4 bytes for IPv4, and multiples of 16 bytes for IPv6. of 4 bytes for IPv4, and multiples of 16 bytes for IPv6.
3.4. Request Message Format 3.4. Request Message Format
As per [RFC5511] the RBNF format of the PCReq message is as follows: The PCReq message is encoded as follows using RBNF as defined in
[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>
where: where:
<request>::= <RP> <request>::= <RP>
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
skipping to change at page 11, line 14 skipping to change at page 12, line 14
where: where:
<end-point-rro-pair-list>::= <end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>] <END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>] <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
Figure 4: 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 definition.
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.
3.5. Reply Message Format 3.5. Reply Message Format
As per [RFC5511] the RBNF format of the PCRep message is as follows: The PCReq message is encoded as follows using RBNF as defined in
[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>]
where: where:
<end-point-path-pair-list>::= <end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>] [<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::=(ERO)|(SERO)|<path>] <path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>] <attribute-list>::=[<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
Figure 5: The Message Format for the Reply Message Figure 4: 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 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-pair-list> and <path>.
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.
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 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
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.
skipping to change at page 15, line 57 skipping to change at page 16, line 57
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 45
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
RRO list RRO list
OF (optional) OF (optional)
skipping to change at page 19, line 5 skipping to change at page 19, line 42
Figure 17: PCReq Message Example for Synchronization Figure 17: PCReq Message Example for Synchronization
This specification also defines two new flags to the SVEC object This specification also defines two new flags to the SVEC object
for P2MP path dependent computation requests. The first new flag is for P2MP path dependent computation requests. The first new flag is
to allow the PCC to request that the PCE should compute a secondary to allow the PCC to request that the PCE should compute a secondary
P2MP pathtree with partial path diversity for specific leaves or a P2MP pathtree with partial path diversity for specific leaves or a
specific S2L sub-path to the primary P2MP path tree. The second flag, specific S2L sub-path to the primary P2MP path tree. The second flag,
would allow the PCC to request that partial paths should be link would allow the PCC to request that partial paths should be link
direction diverse. direction diverse.
The format of the SVEC object body is as follows: The following flags are added to the SVEC object body in this
document:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|P|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SVEC Body Object Format with Additional Flags
The following flags are added to the SVEC object body in this draft:
o P ( Partial Path Diversity bit - 1 bit): o P ( Partial Path Diversity bit - 1 bit):
When set this would indicate a request for path diversity When set this would indicate a request for path diversity
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.2 of this document.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
In certain scenarios the P2MP computation request may not fit into a The total PCEP message-length, including the common header, is 16
single request or response message. For example, if a tree has many bytes. In certain scenarios the P2MP computation request may not fit
hundreds or thousands of leaves. Then the request or response may into a single request or response message. For example, if a tree has
need to be fragmented into multiple messages. many hundreds or thousands of leaves. Then the request or response
may need to be fragmented into multiple messages.
The F bit has been outlined in the Extension of the RP Object section 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 indentify 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
skipping to change at page 20, line 44 skipping to change at page 21, line 17
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
Figure 18: 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.
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
skipping to change at page 21, line 30 skipping to change at page 22, line 15
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 20: UNREACH-DESTINATION Object Body for IPv4 Figure 19: 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 21: UNREACH-DESTINATION Object Body for IPv6 Figure 20: 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 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
skipping to change at page 22, line 39 skipping to change at page 23, line 27
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 MUST send a PCErr message with a PCEP-ERROR computation"), the PCE MUST send a PCErr message with a PCEP-ERROR
Object (Error-Type=5) and an Error-Value (Error-Value=6). The Object (Error-Type=5) and an Error-Value (Error-Value=6). The
corresponding P2MP path computation request MUST also 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 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.
The format of the NO-PATH object body is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: The Format of the NO-PATH Object Body
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:
0x24: 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 destination or list of destinations that are the PCE can specify the destination or list of destinations that are
not reachable using the new UNREACH-DESTINATION object defined in not reachable using the new UNREACH-DESTINATION object defined in
section 3.6. section 3.6.
skipping to change at page 25, line 11 skipping to change at page 25, line 33
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
been defined. IANA is requested to make the following allocations been defined. IANA is requested to make the following allocations
from the "RP Object Flag Field" Sub-Registry: from the "RP Object Flag Field" Sub-Registry:
Bit Description Reference Bit Description Reference
18 Fragmentation(F-bit) This.I-D 18 Fragmentation(F-bit) This.I-D
19 P2MP (N-bit) This.I-D 19 P2MP (N-bit) This.I-D
20 ERO-compression (E-bit) This.I-D 20 ERO-compression (E-bit) This.I-D
6.3 Objective Function 6.3 Objective Functions
As described in Section 3.6.1., two new Objective Funtions have been As described in Section 3.6.1., two new Objective Functions have been
defined. IANA is requested to make the following allocations from the defined. IANA is requested to make the following allocations from the
"Objective Function" sub-registry: "Objective Function" sub-registry:
Code Point Name Reference Code Point Name Reference
7 SPT This.I-D 7 SPT This.I-D
8 MCT This.I-D 8 MCT This.I-D
6.4 Metric Object Types 6.4 Metric Object Types
skipping to change at page 27, line 34 skipping to change at page 28, line 8
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Extensions for Discovery of Traffic Engineering Node and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Capabilities", RFC 5073, December 2007. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [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.
[RFC4970] Lindem A., et al.
"Extensions to OSPF for Advertising Optional Router
Capabilities', RFC 4970, July 2007
[RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node
Capabilities", RFC 5073, December 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [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. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008. 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
skipping to change at page 28, line 28 skipping to change at page 29, line 19
[RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
Computation Element (PCE) to Point-to-Multipoint (P2MP) Computation Element (PCE) to Point-to-Multipoint (P2MP)
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-04 (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, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
J., "Policy-Enabled Path Computation Framework", J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008. RFC 5394, December 2008.
9. Authors' Addresses 9. Authors' Addresses
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technology Huawei Technology
 End of changes. 55 change blocks. 
192 lines changed or deleted 229 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/