draft-ietf-pce-pcep-p2mp-extensions-09.txt   draft-ietf-pce-pcep-p2mp-extensions-10.txt 
Internet Engineering Task Force Q. Zhao, Ed. Internet Engineering Task Force Q. Zhao, Ed.
Internet-Draft Huawei Technology Internet-Draft Huawei Technology
Intended Status: Standards Track Daniel King, Ed. Intended Status: Standards Track Daniel King, Ed.
Expires: September 30, 2010 Old Dog Consulting Expires: October 30, 2010 Old Dog Consulting
March 31, 2010 April 19, 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-09.txt draft-ietf-pce-pcep-p2mp-extensions-10.txt
Abstract Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs. paths of P2MP TE LSPs.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2010. This Internet-Draft will expire on October 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 38 skipping to change at page 3, line 38
4.6. Impact on Network Operation . . . . . . . . . . . . . . .24 4.6. Impact on Network Operation . . . . . . . . . . . . . . .24
5. Security Considerations . . . . . . . . . . . . . . . . . . .24 5. Security Considerations . . . . . . . . . . . . . . . . . . .24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .25
6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .25 6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .25
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25
6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25 6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .26 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .26
6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27
7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .27 6.8 SVEC Object Flag . . . . . . . . . . . . . . . . . . . . .27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .27 6.9 OSPF PCE Capability Flag . . . . . . . . . . . . . . . .28
8.1. Normative References . . . . . . . . . . . . . . . . . . .27 7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .28
8.1. Normative References . . . . . . . . . . . . . . . . . . .28
8.2. Informative References . . . . . . . . . . . . . . . . . .29 8.2. Informative References . . . . . . . . . . . . . . . . . .29
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .29 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .30
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .29 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .30
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 6, line 15 skipping to change at page 6, line 15
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
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an an OSPF [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF
Router Information LSA defined in [RFC4970] to facilitate PCE Router Information LSA defined in [RFC4970] to facilitate PCE
discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be
added to the PCED TLV, so this document defines a new flag in the added to the PCED TLV. This document defines a new flag in the
PCE-CAP-FLAGS sub-TLV of the PCED TLV to indicate the capability of OSPF PCE Capability Flags to indicate the capability of P2MP
P2MP computation. computation.
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
Discovery using IS-IS. This document defines a new flag in the Discovery using IS-IS. This document will use the same flag
PCE-CAP-FLAGS sub-TLV of the PCED sub-TLV to indicate the capability requested for the OSPF PCE Capability Flags sub-TLV
of P2MP computation. to allow IS-IS to indicate the capability of P2MP computation.
The PCE-CAP-FLAGS sub-TLV uses a common codepoint registry for OSPF The IANA request for a shared OSPF and IS-IS P2MP capability flag
and IS-IS PCE discovery. is documented in Section 6.9 of this document.
PCEs wishing to advertise that they support P2MP path computation set PCEs wishing to advertise that they support P2MP path computation
bit 10 (TBA by IANA) in the PCE-CAP-FLAGS sub-TLV. PCCs that do not would set the bit (to be assigned by IANA) accordingly. PCCs that
understand this bit will ignore it (per [RFC5088] and [RFC5089]). do not understand this bit will ignore it (per [RFC5088] and
PCEs that do not support P2MP will leave the bit clear (per the [RFC5089]). PCEs that do not support P2MP will leave the bit clear
default behavior defined in [RFC5088] and [RFC5089]). (per the default behavior defined in [RFC5088] and [RFC5089]).
PCEs that set the bit to indicate support of P2MP path computation PCEs that set the bit to indicate support of P2MP path computation
MUST follow the procedures in Section 3.1.2 to further qualify the MUST follow the procedures in Section 3.1.2 to further qualify the
level of support 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. during the Open Message Exhange, which PCEs are capable of
supporting P2MP path computation.
To satisfy this requirement, we extend the PCEP OPEN object by To satisfy this requirement, we extend the PCEP OPEN object by
defining a new optional TLV to indicate the PCE's capability to defining a new optional TLV to indicate the PCE's capability to
perform P2MP path computations. perform P2MP path computations.
The TLV type number is TBA by IANA. The length value is 2 bytes. The TLV type number will be assigned by IANA. The length value is 2
The value field is set to default value 0. bytes. The value field is set to default value 0.
The inclusion of this TLV in an OPEN object indicates that the sender The inclusion of this TLV in an OPEN object indicates that the sender
can perform P2MP path computations. can perform P2MP path computations.
Note that the capability TLV is meaningful only for a PCE so it will 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 Reservation Protocol Traffic Engineering We specify the use of the Reservation Protocol Traffic Engineering
Extensions (RSVP-TE)Explicit Route Object (ERO) to encode the Extensions (RSVP-TE) Explicit Route Object (ERO) to encode the
explicit route of a TE LSP through the network. PCEP ERO sub-object explicit route of a TE LSP through the network. PCEP ERO sub-object
types correspond to RSVP-TE ERO sub-object types. The format and types correspond to RSVP-TE ERO sub-object types. The format and
content of the ERO object are defined in [RFC3209] and [RFC3473]. content of the ERO object are defined in [RFC3209] and [RFC3473].
The Secondary Explicit Route Object (SERO) is used to specify the The Secondary Explicit Route Object (SERO) is used to specify the
explicit route of a S2L sub-LSP. The path of each subsequent S2L explicit route of a S2L sub-LSP. The path of each subsequent S2L
sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO.
The format of the SERO is the same as an ERO defined in [RFC3209] The format of the SERO is the same as an ERO defined in [RFC3209]
and [RFC3473]. and [RFC3473].
skipping to change at page 9, line 34 skipping to change at page 9, line 34
0: This indicates that the route is not in the compressed 0: This indicates that the route is not in the compressed
format. format.
1: This indicates that the route is in the compressed format. 1: This indicates that the route is in the compressed format.
The IANA request is referenced in Section 6.2 of this document. The IANA request is referenced in Section 6.2 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 The END-POINTS object is used in a PCReq message to specify the
new type of end-points object for the P2MP path. source IP address and the destination IP address of the path for
which a path computation is requested. To represent the end points
for a P2MP path efficiently, we define two new types of end-point
objects for the P2MP path:
o Old leaves whose path can be modified/reoptimized;
o Old leaves whose path must be left unchanged.
With the new END-POINTS object, the PCE path computation request With the new END-POINTS object, the PCE path computation request
message is expanded in a way which allows a single request message is expanded in a way which allows a single request
message to list multiple destinations. message to list multiple destinations.
There are 4 types of leaves in a P2MP request: In total there are now 4 possible types of leaves in a P2MP request:
o New leaves to add; o New leaves to add;
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.
skipping to change at page 12, line 20 skipping to change at page 12, 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 3: The Message Format for the Request Message Figure 3: The Message Format for the Request Message
Note we preserve compatibility with the [RFC5440] definition of Note we preserve compatibility with the [RFC5440] definition of
<request>. At least one instance of <endpoints> must be present <request>. At least one instance of <endpoints> must be present
in this definition. in this definition.
We have requested the additional END-POINTS Object-Types in the IANA
section of this document.
3.5. Reply Message Format 3.5. Reply Message Format
The PCReq message is encoded as follows using RBNF as defined in The PCReq message is encoded as follows using RBNF as defined in
[RFC5511]. [RFC5511].
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response> <response>
<response>::=<RP> <response>::=<RP>
skipping to change at page 19, line 34 skipping to change at page 19, line 34
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
This specification also defines two new flags to the SVEC object This specification also defines two new flags to the SVEC Object Flag
for P2MP path dependent computation requests. The first new flag is Field for P2MP path dependent computation requests. The first new
to allow the PCC to request that the PCE should compute a secondary flag is to allow the PCC to request that the PCE should compute a
P2MP pathtree with partial path diversity for specific leaves or a secondary P2MP pathtree with partial path diversity for specific
specific S2L sub-path to the primary P2MP path tree. The second flag, leaves or a specific S2L sub-path to the primary P2MP path tree.
would allow the PCC to request that partial paths should be link The second flag, would allow the PCC to request that partial paths
direction diverse. should be link direction diverse.
The following flags are added to the SVEC object body in this The following flags are added to the SVEC object body in this
document: document:
o P ( Partial Path Diversity bit - 1 bit): o P ( Partial Path Diverse bit - 1 bit):
When set this would indicate a request for path diversity When set this would indicate a request for path 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. The IANA request is referenced in Section 6.8 of this document.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
The total PCEP message-length, including the common header, is 16 The total PCEP message-length, including the common header, is 16
bytes. In certain scenarios the P2MP computation request may not fit bytes. In certain scenarios the P2MP computation request may not fit
into a single request or response message. For example, if a tree has into a single request or response message. For example, if a tree has
many hundreds or thousands of leaves. Then the request or response many hundreds or thousands of leaves. Then the request or response
may need to be fragmented into multiple messages. may need to be fragmented into multiple messages.
The F bit has been outlined in the Extension of the RP Object section The F bit has been outlined in the Extension of the RP Object section
skipping to change at page 23, line 31 skipping to change at page 23, line 31
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.
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 bit 24: 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.
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]
skipping to change at page 24, line 29 skipping to change at page 24, line 29
requirements. requirements.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional [RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements. requirements.
4.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 The method for the PCE to obtain information about a PCE capable of
about the P2MP signaling and branching capabilities of each LSR in P2MP path computations via OSPF and IS-IS is discussed in Section
the network. 3.1.1 (P2MP Computation TLV in the Existing PCE Discovery Protocol)
of this document.
Protocol extensions specified in this document does not provide such
capability. Other mechanisms MUST be present.
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) can be used to The subsequent IANA requests are documented in Section 6.9 (PCE
advertise capabilities to PCCs. A new flag (value=10) could be Capability Flag) of this document.
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
skipping to change at page 25, line 19 skipping to change at page 25, line 19
document. IANA is requested to make the following allocations. document. IANA is requested to make the following allocations.
6.1 P2MP Capability TLV 6.1 P2MP Capability TLV
As described in Section 3.1.2, the newly defined P2MP capability TLV As described in Section 3.1.2, the newly defined P2MP capability TLV
allows the PCE to advertize its P2MP path computation capability. allows the PCE to advertize its P2MP path computation capability.
IANA is requested to make the following allocation from the "PCEP IANA is requested to make the following allocation from the "PCEP
TLV Type Indicators" sub-registry. TLV Type Indicators" sub-registry.
Value Description Reference Value Description Reference
6 P2MP capability This.I-D 6 P2MP capable This.I-D
6.2 Request Parameter Bit Flags 6.2 Request Parameter Bit Flags
As described in Section 3.3.1., three new RP Object Flags have As described in Section 3.3.1., three new RP Object Flags have
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 "PCEP 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 Functions 6.3 Objective Functions
As described in Section 3.6.1., two new Objective Functions 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: "PCEP 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
As described in Section 3.6.2., three new metric object T fields have As described in Section 3.6.2., three new metric object T fields have
been defined. IANA is requested to make the following allocations been defined. IANA is requested to make the following allocations
from the "METRIC Object T Field" sub-registry: from the "PCEP METRIC Object T Field" sub-registry:
Value Description Reference Value Description Reference
8 P2MP IGP metric This.I-D 8 P2MP IGP metric This.I-D
9 P2MP TE metric This.I-D 9 P2MP TE metric This.I-D
10 P2MP hop count metric This.I-D 10 P2MP hop count metric This.I-D
6.5 PCEP Objects 6.5 PCEP Objects
As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have As discussed in Section 3.3.2 two new END-POINTS Object-Types are
been defined. IANA is requested to make the following allocations defined. IANA is requested to make the following Object-Type
from the "PCEP Objects" sub-registry allocations:
Object-Class Value 25 Object-Class Value 4
Name UNREACH-DESTINATION Name END-POINTS
Object-Type 1: IPv4 Object-Type 3: IPv4
2: IPv6 4: IPv6
3-15: Unassigned 5-15: Unassigned
Reference This.I-D Reference This.I-D
Object-Class Value 26 As described in Section 3.2, 3.11.1 and 3.14, four PCE
Name SERO Object-Classes and six Object-Types have been defined.
Object-Type 1: SERO IANA is requested to make the following allocations from the "PCEP
2-15: Unassigned Objects" sub-registry:
Reference This.I-D
Object-Class Value 27 Object-Class Value 28
Name SRRO Name UNREACH-DESTINATION
Object-Type 1: SRRO Object-Type 1: IPv4
2-15: Unassigned 2: IPv6
Reference This.I-D 3-15: Unassigned
Reference This.I-D
Object-Class Value 28 Object-Class Value 29
Name Branch Node Capability Object Name SERO
Object-Type 1: Branch node list Object-Type 1: SERO
2: Non-branch node list 2-15: Unassigned
3-15: Unassigned Reference This.I-D
Reference This.I-D
Object-Class Value 30
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference This.I-D
Object-Class Value 31
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference This.I-D
6.6 PCEP Error Objects and Types 6.6 PCEP Error Objects and Types
As described in Section 3.15., a number of new PCEP-ERROR Object As described in Section 3.15., a number of new PCEP-ERROR Object
Error Types and Values have been defined. IANA is requested to Error Types and Values have been defined. IANA is requested to
make the following allocations from the "PCEP-ERROR Object Error make the following allocations from the "PCEP PCEP-ERROR Object
Type and Value" sub-registry: Error Type and Value" sub-registry:
Error Error
Type Meaning Reference Type Meaning Reference
5 Policy violation 5 Policy violation
Error-value=6: This.I-D Error-value=6: This.I-D
P2MP Path computation is not allowed P2MP Path computation is not allowed
16 P2MP Error This.I-D 16 P2MP Error This.I-D
Error-Value=0: Unassigned Error-Value=0: Unassigned
skipping to change at page 27, line 29 skipping to change at page 27, line 36
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3 due to no END-POINTS with leaf type 3
Error-Value=3: This.I-D Error-Value=3: This.I-D
The PCE is not capable to satisfy the request The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4 due to no END-POINTS with leaf type 4
6.7 PCEP NO-PATH Indicator 6.7 PCEP NO-PATH Indicator
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field
has been defined. IANA is requested to make the following has been defined. IANA is requested to make the following
allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry: allocation from the "PCEP NO-PATH-VECTOR TLV Flag Field"
sub-registry:
Bit Description Reference Bit Description Reference
24 P2MP Reachability Problem This.I-D 24 P2MP Reachability Problem This.I-D
6.8 SVEC Object Flag
As discussed in Section 3.12, two new SVEC Object Flags are
defined. IANA is requested to make the following
allocation from the "PCEP SVEC Object Flag Field" sub-registry:
Bit Description Reference
24 Partial Path Diverse This.I-D
25 Link Direction Diverse This.I-D
6.9 PCE Capability Flag
As discussed in Section 3.1, a new OSPF Capability Flag is defined
to indicate P2MP path computation capability. IANA is requested to
make the assignment from the "OSPF Parameters Path Computation
Element (PCE) Capability Flags" registry:
Bit Description Reference
10 P2MP path computation This.I-D
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh
Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas
Manral for their valuable comments and input on this draft. Manral for their valuable comments and input on this draft.
8. References 8. References
 End of changes. 35 change blocks. 
85 lines changed or deleted 127 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/