draft-ietf-pce-pcep-p2mp-extensions-00.txt   draft-ietf-pce-pcep-p2mp-extensions-01.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: Informational M. Chaitou, Ed. Intended status: Informational M. Chaitou, Ed.
Expires: March 13, 2009 France Telecom Expires: May 3, 2009 France Telecom
September 9, 2008 October 30, 2008
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 (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
Paths
draft-ietf-pce-pcep-p2mp-extensions-00.txt draft-ietf-pce-pcep-p2mp-extensions-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 39 skipping to change at page 1, line 38
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 March 13, 2009. This Internet-Draft will expire on May 3, 2009.
Abstract Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
be determined. The Path Computation Element (PCE) has been be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs. paths of P2MP TE LSPs.
This document describes extensions to the PCE Communication Protocol This document describes extensions to the PCE communication Protocol
PCEP) to handle requests and responses for the computation of paths (PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs. for P2MP TE LSPs.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6 4. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6
4.1. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 6 4.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 6
4.2. Indication of P2MP Path Computation Request/Reply . . . . 6 4.1.1. Extend the TLV in the Existing PCE Discovery
4.2.1. The Extension of RP Object . . . . . . . . . . . . . . 6 Protocol . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 7 4.1.2. Open Message Extension . . . . . . . . . . . . . . . . 6
4.3. Request Message Formats . . . . . . . . . . . . . . . . . 10 4.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 7
4.4. Reply Message Formats . . . . . . . . . . . . . . . . . . 11 4.3. Indication of P2MP Path Computation Request/Reply . . . . 7
5. P2MP Objective Functions and Metric Types . . . . . . . . . . 12 4.3.1. The Extension of RP Object . . . . . . . . . . . . . . 7
5.1. New Object Functions . . . . . . . . . . . . . . . . . . . 12 4.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 8
5.2. New Metric Object Types . . . . . . . . . . . . . . . . . 13 4.4. Request Message Formats . . . . . . . . . . . . . . . . . 10
6. Non-Support of P2MP Path Computation. . . . . . . . . . . . . 13 4.5. Reply Message Formats . . . . . . . . . . . . . . . . . . 11
7. Non-Support by Back-Level PCE Implementations. . . . . . . . . 14 4.6. P2MP Objective Functions and Metric Types . . . . . . . . 12
8. P2MP TE Path Re-optimization Request . . . . . . . . . . . . . 14 4.6.1. New Object Functions . . . . . . . . . . . . . . . . . 12
9. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . . . 15 4.6.2. New Metric Object Types . . . . . . . . . . . . . . . 13
10. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 13
11. Synchronization of P2MP TE Path Computation Requests . . . . . 15 4.8. Non-Support by Back-Level PCE Implementations. . . . . . . 14
12. P2MP Capability Advertisement . . . . . . . . . . . . . . . . 16 4.9. P2MP TE Path Re-optimization Request . . . . . . . . . . . 14
12.1. Extend the TLV in the Existing PCE Discovery Protocol . . 16 4.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . 15
12.2. Open Message Extension . . . . . . . . . . . . . . . . . . 16 4.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . 19
13. Multi-Message Support . . . . . . . . . . . . . . . . . . . . 17 4.12. Synchronization of P2MP TE Path Computation Requests . . . 19
14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . . . 18 4.13. Multi-Message Support . . . . . . . . . . . . . . . . . . 20
15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . . . 19 4.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . 21
16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 4.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 23
17. Manageability Considerations . . . . . . . . . . . . . . . . . 20 4.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 23
17.1. Control of Function and Policy . . . . . . . . . . . . . . 21 5. Manageability Considerations . . . . . . . . . . . . . . . . . 24
17.2. Information and Data Models . . . . . . . . . . . . . . . 21 5.1. Control of Function and Policy . . . . . . . . . . . . . . 24
17.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 5.2. Information and Data Models . . . . . . . . . . . . . . . 24
17.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25
17.5. Requirements on Other Protocols and Functional 5.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25
Components . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Requirements on Other Protocols and Functional
17.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 Components . . . . . . . . . . . . . . . . . . . . . . . . 25
18. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5.6. Impact on Network Operation . . . . . . . . . . . . . . . 25
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
20. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
21.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
21.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Terminology 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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE is identified as a suitable application for the computation The PCE is identified as a suitable application for the computation
of paths for P2MP TE LSPs [PCEP-P2MP]. of paths for P2MP TE LSPs [PCEP-P2MP-APP].
The PCE communication protocol (PCEP) is designed as a communication The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [PCEP]. However, that specification computations and is defined in [PCEP]. However, that specification
does not provide a mechanism to request path computation of P2MP TE does not provide a mechanism to request path computation of P2MP TE
LSPs. LSPs.
This document presents extensions to PCEP to support P2MP path This document presents extensions to PCEP to support P2MP path
computation satisfying the set of requirements described in [PCEP- computation satisfying the set of requirements described in [PCEP-
P2MP]. P2MP-REQ].
This document relies on the semantics of PCEP for requesting path This document relies on the semantics of PCEP for requesting path
computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple
source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between
ingress and egress LSRs and are appropriately combined by the branch ingress and egress LSRs and are appropriately combined by the branch
LSRs using computation result from PCE to result in a P2MP TE LSP. LSRs using computation result from PCE to result in 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.
2.1. Requirements Language 2.1. 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].
3. Requirement 3. Requirements
This section summarizes the PCEP requirements specific to Point to This section summarizes the PCEP requirements specific to Point to
Multi point as described in [PCEP-P2MP]. Multi point as described in [PCEP-P2MP-REQ].
R1: Indication of P2MP Path Computation Request. R1: Indication of P2MP Path Computation Request.
R2: Indication of P2MP Objective Functions. R2: Indication of P2MP Objective Functions.
R3: Non-Support of P2MP Path Computation. R3: Non-Support of P2MP Path Computation.
R4: Non-Support by Back-Level PCE Implementations. R4: Non-Support by Back-Level PCE Implementations.
R5: Specification of Destinations. R5: Specification of Destinations.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
authors of the requirements draft). authors of the requirements draft).
R14: Sender of the request message can specify if the return result R14: Sender of the request message can specify if the return result
from the PCE need to be represented in the compressed format or not. from the PCE need to be represented in the compressed format or not.
4. Protocol Procedures and Extensions 4. Protocol Procedures and Extensions
The following sections describe the protocol extensions to satisfy The following sections describe the protocol extensions to satisfy
the requirements specified in the previous section. the requirements specified in the previous section.
4.1. P2MP LSPs Efficient Presentation 4.1. P2MP Capability Advertisement
4.1.1. Extend the TLV in the Existing PCE Discovery Protocol
Since the RFC 5088 has specified that we can not add additional sub-
TLV to the PCED TLV, we will define new bits to go in the existing 32
bits PCE Caps Flags to indicate the capability of P2MP for the PCC
and PCE.
4.1.2. Open Message Extension
Based on the Capabilities Exchange requirement described in [PCEP-
P2MP-REQ], if a PCE does not advertise its P2MP capability through
discovery and the capability is not configured to the PCC, we need to
use PCEP to allow a PCC to discover 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 path
computation capabilities.
The TLV type number will be assigned by IANA, 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
typically appear only in one of the two Open messages during PCE
session establishment. However, in case of PCE cooperation (e.g.,
inter-domain), when a PCE behaving as a PCC initiates a PCE session
it SHOULD also indicate its Path Computation capability.
4.2. P2MP LSPs Efficient Presentation
In the request message of the adding of leaves, optimization of P2MP In the request message of the adding of leaves, optimization of P2MP
TE LSPs as specified in [PCEP-P2MP-REQ], and in the reply message, we TE LSPs as specified in [PCEP-P2MP-REQ], and in the reply message, we
need to pass an existing P2MP LSP between the PCC and PCE. In these need to pass an existing P2MP LSP between the PCC and PCE. In these
cases, we need new path objects for efficiently passing the existing cases, we need new path objects for efficiently passing the existing
P2MP LSP between PCE to PCC. P2MP LSP between PCE to PCC.
We suggest to using the ERO/SERO and RRO/SRRO to represent each We suggest to using the ERO/SERO and RRO/SRRO to represent each
individual S2L sub-LSP. The ERO/RRO are same as defined in the individual S2L sub-LSP. The contents of ERO/RRO are same as defined
[PCEP] and SERO and SRRO are same as defined in RFC4875 for the RSVP in the [PCEP] and the contents of SERO and SRRO are same as defined
extension of P2MP. in RFC4875 for the RSVP extension of P2MP except we need assign the
new class and type for all of them.
4.2. Indication of P2MP Path Computation Request/Reply 4.3. Indication of P2MP Path Computation Request/Reply
The existing P2P RP object is extended so that it can signal to the The existing P2P RP object is extended so that it can signal to the
receiver of the request or reply message that it is for P2P or P2MP receiver of the request or reply message that it is for P2P or P2MP
path computation. Also the END- POINT object is extended to improve path computation. Also the END- POINT object is extended to improve
the efficiency of the message exchange between PCC and PCE in the the efficiency of the message exchange between PCC and PCE in the
case of P2MP path computation. case of P2MP path computation.
4.2.1. The Extension of RP Object 4.3.1. The Extension of RP Object
The PCE path computation request/reply message adds an explicit The PCE path computation request/reply message adds an explicit
parameter to allow a receiving PCE to identify that the request/reply parameter to allow a receiving PCE to identify that the request/reply
is for a P2MP path and also specify if the route is represented in is for a P2MP path and also to specify if the route is represented in
the compress format or not. the compress format or not.
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 P2P or it the receiver of the message that the request/reply is for P2MP or
is for P2MP. 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 M bit and The extended format of the RP object body to include the M bit and
the E bit is as follows: 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 2 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 2
skipping to change at page 7, line 46 skipping to change at page 8, line 34
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.
4.2.2. The New P2MP END-POINTS Object 4.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 P2MP path.
With this new END-POINTS object, the PCE path computation request With this 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 such that it 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 8, line 33 skipping to change at page 9, line 19
So 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 request message size for the With this new END-POINTS object, the END-POINTS portions of a request
multiple destinations can be reduced up to 50% for a P2MP path where message for the multiple destinations can be roughly reduced up to
a single source address has many destinations. 50% for a P2MP path where a single source address has a very large
number of destinations.
Note that A P2MP path computation request can mix the different type
of leaves by including several END-POINTS object per RP object as
shown in PCReq BNF format in next section.
The format of the new END-POINTS object body for IPv4 (Object-Type 3) The format of the new END-POINTS object body for IPv4 (Object-Type 3)
is as follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 2: 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
skipping to change at page 10, line 18 skipping to change at page 10, line 18
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Source IPv6 address (16 bytes) | | Source IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 3: The New P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length of multiple of 4 The END-POINTS object body has a variable length of multiple of 4
bytes for IPv4 and multiple of 16 bytes for IPv6. bytes for IPv4 and multiple of 16 bytes for IPv6.
4.3. Request Message Formats 4.4. Request Message Formats
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 with P2MP flag and ERO-Compress bit> <request>::= <RP with P2MP flag and ERO-Compress bit>
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: where:
<end-point-rro-pair-list>::= <end-point-rro-pair-list>::=
<END-POINTS>[<RRO List>] <END-POINTS>[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<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
4.4. Reply Message Formats 4.5. Reply Message Formats
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 with P2MP flag and ERO-Cpmpress bit> <response>::=<RP with P2MP flag and ERO-Cpmpress bit>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
where: where:
skipping to change at page 12, line 37 skipping to change at page 12, line 37
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 request then the path will be
formed by an ERO followed by a list of SERO. Otherwise it is a list formed by an ERO followed by a list of SERO. Otherwise it is a list
of ERO. of ERO.
5. P2MP Objective Functions and Metric Types 4.6. P2MP Objective Functions and Metric Types
5.1. New Object Functions 4.6.1. New Object Functions
Six objective functions have been defined in [PCE-OF] for P2P path Six objective functions have been defined in [PCE-OF] 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 (e.g. TE or IGP metric) 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)
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. 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
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 [PCE-OF]. defined in [PCE-OF].
5.2. New Metric Object Types 4.6.2. New Metric Object Types
There are three types defined for the <METRIC> object in [PCEP], There are three types defined for the <METRIC> object in [PCEP],
namely, the IGP metric, the TE metric and the hop count metric. This namely, the IGP metric, the TE metric and the hop count metric. This
document defines three other types for the <METRIC> object: the P2MP document defines three other types for the <METRIC> object: the P2MP
IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They
encode the sum of the metrics of all links of the tree. We propose encode the sum of the metrics of all links of the tree. We propose
the following values for these new metric types (to be assigned by the following values for these new metric types (to be assigned by
IANA): IANA):
o P2MP IGP metric: T=4 o P2MP IGP metric: T=4
o P2MP TE metric: T=5 o P2MP TE metric: T=5
o P2MP hop count metric: T=6 o P2MP hop count metric: T=6
6. Non-Support of P2MP Path Computation. 4.7. Non-Support of P2MP Path Computation.
o if a PCE receives a P2MP path request and it understands the P2MP o if a PCE receives a P2MP path request and it understands the P2MP
flag in RP object, but the PCE is not capable of P2MP computation, flag in RP object, but the PCE is not capable of P2MP computation,
the PCE MUST send a PCErr message with a PCEP-ERROR Object and an the PCE MUST send a PCErr message with a PCEP-ERROR Object and an
Error-Value. The corresponding P2MP path computation request MUST Error-Value. The corresponding P2MP path computation request MUST
be cancelled. (Error-Type and Error-Value are defined in this be cancelled. (Error-Type and Error-Value are defined in this
document). 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".
7. Non-Support by Back-Level PCE Implementations. 4.8. Non-Support by Back-Level PCE Implementations.
If we accidentally send the P2MP request to the PCE which does not
support the P2MP yet, we have the following solution:
Using the same RP type with P2MP flag and the new END-POINTS type, If we accidentally send the P2MP request to a PCE which does not
the receiver will reject the request when it can not understand the support the PCEP P2MP extensions yet, then it will reject the request
new END-POINTS object. because it cannot understand the new END-POINTS object.
8. P2MP TE Path Re-optimization Request 4.9. P2MP TE Path Re-optimization Request
The reoptimization request for a P2MP TE path is specified by R bit The re-optimization request for a P2MP TE path is specified by R bit
in the RP object similarly to the re-optimization request for a P2P in the RP object similarly to the re-optimization request for a P2P
TE path. The only difference is that the user must insert the list TE path. The only difference is that the user must insert the list
of RRO after each type of END-POINTS as described in the PCReq of RRO after each type of END-POINTS as described in the PCReq
message format section. message format section.
So the PCReq message would look like this: So the PCReq message would look like this:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<request> <request>
where: where:
<request>::=<RP with P2MP flag/R bits set> <request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 3><RRO list> <END-POINTS for leaf type 3><RRO list>
[OF] [OF]
Figure 6: PCReq Message Example 1 for Optimization Figure 6: PCReq Message Example 1 for Optimization
In this example, the RRO list is representing the P2MP LSP before the In this example, we request re-optimization of path to all leaves
optimization and the modifiable paths are indicated in the END-POINTS 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
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 some leaves whose path cannot be
modified. The PCReq message would then look like this: modified. The PCReq message would then look like this:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<request> <request>
where: where:
<request>::=<RP with P2MP flag/R bits set> <request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 3><RRO list> <END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list> <END-POINTS for leaf type 4><RRO list>
[OF] [OF]
Figure 7: PCReq Message Example 2 for Optimization Figure 7: PCReq Message Example 2 for Optimization
9. Adding/pruning Leaves 4.10. Adding/pruning Leaves
When adding new leaves or removing old leaves to the existing P2MP When adding new leaves or removing old leaves to the existing P2MP
tree, by supplying a list of existing leaves, one may be able to tree, by supplying a list of existing leaves, one may be able to
optimize the new P2MP tree. This section explains ways to add new optimize the new P2MP tree. This section explains ways to add new
leaves or remove old leaves to the existing P2MP tree. leaves or remove old leaves to the existing P2MP tree.
To add new leaves the user must build a P2MP request with a nEND- To add new leaves the user must build a P2MP request with a nEND-
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-
skipping to change at page 15, line 31 skipping to change at page 15, line 42
type 3 or 4 or both. In the future version, we may want to consider type 3 or 4 or both. In the future version, we may want to consider
to define error values when the condition is not satisfied (i.e., to define error values when the condition is not satisfied (i.e.,
when there is no END-POINTS with leaf type 3 or 4, in the presence of when there is no END-POINTS with leaf type 3 or 4, in the presence of
END-POINTS with leaf type 1 or 2). END-POINTS with leaf type 1 or 2).
For old leaves the user must provide the old path as list of RROs For old leaves the user must provide the old path as list of RROs
that immediately follows each END-POINTS object. In the future that immediately follows each END-POINTS object. In the future
version, we may want to consider to define error values when the version, we may want to consider to define error values when the
condition is not satisfied. condition is not satisfied.
10. Branch Nodes So eventually the following cases are possibles when modifying an
existing P2MP LSP:
Case 1: Adding leaves with full reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 8: Adding Leaves with Full Reoptimization
Case 2: Adding leaves with partial reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 1>
<END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 9: Adding Leaves with Partial Reoptimization
Case 3: Adding leaves without reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 10: Adding Leaves without Reoptimization
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 3><RRO list>
[OF]
Figure 11: Pruning Leaves with Full Reoptimization
Case 5: Pruning leaves with partial reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 12: Pruning Leaves with Partial Reoptimization
Case 6: Pruning leaves without reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 13: Pruning Leaves without Reoptimization
Case 7: Adding and pruning leaves full reoptimization of existing
paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 1>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 3><RRO list>
[OF]
Figure 14: Adding and Pruning Leaves full Reoptimization
Case 8: Adding and pruning leaves with partial reoptimization of
existing paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 1>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 3><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 15: Adding and Pruning Leaves with Partial Reoptimization
Case 9: Adding and pruning leaves without reoptimization of existing
paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 1>
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 16: Adding and Pruning Leaves without Reoptimization
4.11. Branch Nodes
Before computing the P2MP path, a PCE must be provided means to know Before computing the P2MP path, a PCE must be provided means to know
which nodes in the network are capable of acting as branch LSRs. A which nodes in the network are capable of acting as branch LSRs. A
PCE can discover such capability by using the mechanisms defined in PCE can discover such capability by using the mechanisms defined in
[NODE-CAP]. [NODE-CAP].
11. Synchronization of P2MP TE Path Computation Requests 4.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs' computation need to be There are cases when multiple P2MP LSPs' computations need to be
synchronized. For example, one P2MP LSP is the backup of another synchronized. For example, one P2MP LSP is the backup of another
P2MP LSP. In this case, the path diversity for these two LSPs need P2MP LSP. In this case, the path diversity for these two LSPs need
to be considered during the path computation. to be considered during the path computation.
The synchronization can be done by just using the existing SVEC The synchronization can be done by just using the existing SVEC
functionality. functionality.
Example of synchronizing two P2MP LSPs, each has two leaves for Path Example of synchronizing two P2MP LSPs, each has two leaves for Path
Computation Request Messages is illustrated as below: Computation Request Messages is illustrated as below:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<SVEC for sync of LSP1 and LSP2>[OF?] <svec-list>
<request-list> <request-list>
where: where:
<svec-list> ::= <SVEC for sync of LSP1 and LSP2>
[<OF>]
<request-list>::=<request1><request2> <request-list>::=<request1><request2>
<request1>::= <RP with P2MP flag> <request1>::= <RP with P2MP flag>
<END-POINTS1 for P2MP> <END-POINTS1 for P2MP>
<RRO1 list> <RRO1 list>
[<BANDWIDTH1>] [<BANDWIDTH1>]
<request2>::= <RP with P2MP flag> <request2>::= <RP with P2MP flag>
<END-POINTS2 for P2MP> <END-POINTS2 for P2MP>
<RRO2 list> <RRO2 list>
[<BANDWIDTH2>] [<BANDWIDTH2>]
Figure 8: PCReq Message Example for Synchronization Figure 17: PCReq Message Example for Synchronization
12. P2MP Capability Advertisement
12.1. Extend the TLV in the Existing PCE Discovery Protocol
Since the RFC 5088 has specified that we can not add additional sub-
TLV to the PCED TLV, we will define new bits to go in the existing 32
bits PCE Caps Flags to indicate the capability of P2MP for the PCC
and PCE.
12.2. Open Message Extension
Based on the Capabilities Exchange requirement described in [PCEP-
P2MP-REQ], if a PCE does not advertise its P2MP capability through
discovery and the capability is not configured to the PCC, we need to
use PCEP to allow a PCC to discover 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 path
computation capabilities.
The TLV type number will be assigned by IANA, 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
typically appear only in one of the two Open messages during PCE
session establishment. However, in case of PCE cooperation (e.g.,
inter-domain), when a PCE behaving as a PCC initiates a PCE session
it SHOULD also indicate its Path Computation capability.
13. Multi-Message Support 4.13. Multi-Message Support
The solution follows synchronization procedures defined in [PCEP]. The solution follows synchronization procedures defined in [PCEP].
If the P2MP request (i.e. <RP><END-POINTS>) is too large to fit into If the P2MP request (i.e. <RP><END-POINTS>) is too large to fit into
a single message it is permitted to divide it into multiple requests a single message it is permitted to divide it into multiple requests
that would be carried in different messages. That means that a P2MP that would be carried in different messages. That means that a P2MP
request would then contain multiple requests with RP objects that request would then contain multiple requests with RP objects that
have the same request IDs. have the same request IDs.
Here is an example of such P2MP request that is divided in 2 request Here is an example of such P2MP request that is divided in 2 request
skipping to change at page 17, line 39 skipping to change at page 21, line 24
<PCReq Message2>::= <Common Header> <PCReq Message2>::= <Common Header>
<request> <request>
where: where:
<request>::=< RP with Req-ID1> <request>::=< RP with Req-ID1>
<END-POINTs for P2MP> <END-POINTs for P2MP>
<RRO list> <RRO list>
Figure 9: PCReq Message Example for Message Fragmentation Figure 18: PCReq Message Example for Message Fragmentation
Note that the SVEC object contains the same request Id repeated N Note that the SVEC object contains the same request Id repeated N
times where N is the total number of RP objects included in all times where N is the total number of RP objects included in all
messages. This is to be able to detect that the whole P2MP request messages. This is to be able to detect that the whole P2MP request
has been received. Note that this assumes that the transmission of has been received. Note that this assumes that the transmission of
the messages is performed reliably and in consistent order, which is the messages is performed reliably and in consistent order, which is
not a problem since PCEP relies on TCP. not a problem since PCEP relies on TCP.
14. UNREACH_DESTINATION object To avoid the backward compatible problem when a PCE that does not
support P2MP extensions receives an SVEC with same request Id twice,
such message MUST NOT be sent to a non P2MP capable PCE. Thanks to
the OPEN message discovery mechanism this is possible to known.
We propose to use the SVEC/synctimer mechanism also for PCRep message
(in case of too large response message). This was not defined in
PCEP base draft. We propose that this feature to be defined in the
future version of the PCEP draft.
4.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.
skipping to change at page 18, line 35 skipping to change at page 22, line 25
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: 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 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: UNREACH_DESTINATION Object Body for IPv6 Figure 20: UNREACH_DESTINATION Object Body for IPv6
15. P2MP PCEP Error Object 4.15. P2MP PCEP Error Object
To indicate errors associated with the P2MP path request, a new To indicate errors associated with the P2MP path request, a new
Error-Type (16) and subsequent error-values are defined as follows Error-Type (16) and subsequent error-values are defined as follows
for inclusion in the PCEP-ERROR object: for inclusion in the PCEP-ERROR object:
A new Error-Type (16) and subsequent error-values are defined as A new Error-Type (16) and subsequent error-values are defined as
follows: follows:
Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path
request and the PCE is not capable to satisfy the request due to request and the PCE is not capable to satisfy the request due to
skipping to change at page 20, line 9 skipping to change at page 23, line 38
existing error code for policy violation (Error-Type=5) as defined in existing error code for policy violation (Error-Type=5) as defined in
[PCEP]. [PCEP].
Error-Type=5; Error-Value=4: if a PCE receives a P2MP path Error-Type=5; Error-Value=4: if a PCE receives a P2MP path
computation request which is not compliant with administrative computation request which is not compliant with administrative
privileges (i.e., the PCE policy does not support P2MP path privileges (i.e., the PCE policy does not support P2MP path
computation), the PCE sends a PCErr message with a PCEP-ERROR Object computation), the PCE sends a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=4). The corresponding (Error-Type=5) and an Error-Value (Error-Value=4). The corresponding
P2MP path computation request MUST be cancelled. P2MP path computation request MUST be cancelled.
16. PCEP NO-PATH Indicator 4.16. PCEP NO-PATH Indicator
To communicate the reason(s) for not being able to find P2MP path To communicate the reason(s) for not being able to find P2MP path
computation, the NO-PATH object can be used in the PCRep message. computation, the NO-PATH object can be used in the PCRep message.
The format of the NO-PATH object body is as follows: The format of the NO-PATH object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Format of the NO-PATH Object Body Figure 21: The Format of the NO-PATH Object Body
One new bit flags are defined in the NO-PATH-VECTOR TLV carried in One new bit flags are defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object: the NO-PATH Object:
0x20: when set, the PCE indicates that there is a reachability 0x20: when set, the PCE indicates that there is a reachability
problem with all or a subset of the P2MP destinations. Optionally problem with all or a subset of the P2MP destinations. Optionally
the PCE can specify the list of destination(s) that are not reachable the PCE can specify the list of destination(s) that are not reachable
using the new UNREACH_DESTINATION object defined in section 3.6. using the new UNREACH_DESTINATION object defined in section 3.6.
17. Manageability Considerations 5. Manageability Considerations
[PCEP-P2MP-REQ] describes various manageability requirements in [PCEP-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 [PCEP-P2MP-REQ] describes how manageability requirements mentioned in [PCEP-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 [PCEP] describes various manageability considerations in Note that [PCEP] describes various manageability considerations in
PCEP, and most of manageability requirements mentioned in [PCEP-P2MP PCEP, and most of manageability requirements mentioned in [PCEP-P2MP
P2MP] are already covered there. P2MP] are already covered there.
17.1. Control of Function and Policy 5.1. Control of Function and Policy
In addition to configuration parameters listed in [PCEP], the In addition to configuration parameters listed in [PCEP], the
following parameters MAY be required. following parameters MAY be required.
o P2MP path computations enabled or disabled. o P2MP path computations enabled or disabled.
o Advertisement of P2MP path computation capability enabled or o Advertisement of P2MP path computation capability enabled or
disabled (discovery protocol, capability exchange). disabled (discovery protocol, capability exchange).
17.2. Information and Data Models 5.2. Information and Data Models
As described in [PCEP-P2MP-REQ], MIB objects MUST be supported for As described in [PCEP-P2MP-REQ], MIB objects MUST be supported for
PCEP extensions specified in this document. PCEP extensions specified in this document.
17.3. Liveness Detection and Monitoring 5.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[PCEP], since [PCEP-P2MP-REQ] does not address any additional [PCEP], since [PCEP-P2MP-REQ] does not address any additional
requirements. requirements.
17.4. Verifying Correct Operation 5.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[PCEP], since [PCEP-P2MP-REQ] does not address any additional [PCEP], since [PCEP-P2MP-REQ] does not address any additional
requirements. requirements.
17.5. Requirements on Other Protocols and Functional Components 5.5. Requirements on Other Protocols and Functional Components
As described in [PCEP-P2MP-REQ], the PCE MUST obtain information As described in [PCEP-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.
17.6. Impact on Network Operation 5.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.
18. Security Considerations 6. Security Considerations
As described in [PCEP-P2MP-REQ], P2MP path computation requests are As described in [PCEP-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. may be more vulnerable to denial of service attacks.
[PCEP] describes various mechanisms for denial of service attacks, [PCEP] describes various mechanisms for denial of service attacks,
and these tools MAY be advantageously used. and these tools MAY be advantageously used.
19. IANA Considerations 7. IANA Considerations
A number of IANA considerations have been highlighted in the relevent A number of IANA considerations have been highlighted in the relevent
sections of this document. Further clarifications of these requests sections of this document. Further clarifications of these requests
will be made in a future version of this document. will be made in a future version of this document.
20. Acknowledgement 8. Acknowledgement
The authors would like to thank Adrian Farrel, Young Lee, Dan The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable
comments on this draft. comments on this draft.
21. References 9. References
21.1. Normative References 9.1. Normative References
[I-D.ietf-pce-pcep] [PCEP] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
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)", draft-ietf-pce-pcep-15 (work in progress), (PCEP)", draft-ietf-pce-pcep-16 (work in progress),
September 2008. October 2008.
[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.
[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., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008. (PCE) Discovery", RFC 5089, January 2008.
[I-D.yasukawa-pce-p2mp-req] [PCE-P2MP-APP]
Yasukawa, S. and A. Farrel,
"draft-ietf-pce-p2mp-app-00.txt",
draft-ietf-pce-p2mp-app-00 (work in progress),
August 2008.
[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-yasukawa-pce-p2mp-req-05 (work in progress), draft-ietf-pce-p2mp-req-00 (work in progress),
May 2008. August 2008.
[RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node Extensions for Discovery of Traffic Engineering Node
Capabilities", RFC 5073, December 2007. Capabilities", RFC 5073, December 2007.
[I-D.ietf-pce-of] [PCE-OF]
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)", draft-ietf-pce-of-05 (work in progress), Protocol (PCEP)", draft-ietf-pce-of-05 (work in progress),
September 2008. September 2008.
[I-D.nishioka-pce-svec-list] [PCEP-SVEC-LIST]
Nishioka, I. and D. King, "The use of SVEC Nishioka, I. and D. King, "The use of SVEC
(Synchronization VECtor) list for Synchronized dependent (Synchronization VECtor) list for Synchronized dependent
path computations", draft-nishioka-pce-svec-list-02 (work path computations", draft-ietf-pce-pcep-svec-list-00 (work
in progress), July 2008. in progress), September 2008.
21.2. Informative References 9.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.
Authors' Addresses 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
 End of changes. 78 change blocks. 
170 lines changed or deleted 318 lines changed or added

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