draft-ietf-pce-pcep-p2mp-extensions-02.txt   draft-ietf-pce-pcep-p2mp-extensions-03.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 Fabien Verhaeghe Intended Status: Standards Track Daniel King
Created: March 8, 2009 Marben Products Expires: January 12, 2009 Old Dog Consulting
Expires: September 8, 2009 Daniel King July 12, 2009
Old Dog Consulting
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-02.txt draft-ietf-pce-pcep-p2mp-extensions-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 December 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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.
Contents Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Requirements Language . . . . . . . . . . . . . . . . . .
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 3. Protocol Procedures and Extensions . . . . . . . . . . . . . .
3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .
3.1.1. Extend the TLV in the Existing PCE Discovery 3.1.1. Extend the TLV in the Existing PCE Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . . Protocol . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 3.1.2. Open Message Extension . . . . . . . . . . . . . . . .
3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . .
3.3. Indication of P2MP Path Computation Request/Reply . . . . 3.3. Indication of P2MP Path Computation Request/Reply . . . .
3.3.1. The Extension of RP Object . . . . . . . . . . . . . . 3.3.1. The Extension of RP Object . . . . . . . . . . . . . .
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .
3.4. Request Message Formats . . . . . . . . . . . . . . . . . 3.4. Request Message Formats . . . . . . . . . . . . . . . . .
3.5. Reply Message Formats . . . . . . . . . . . . . . . . . . 3.5. Reply Message Formats . . . . . . . . . . . . . . . . . .
3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . .
3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.1. New Object Functions . . . . . . . . . . . . . . . . .
3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .
skipping to change at page 2, line 31 skipping to change at page 3, line 20
3.5. Reply Message Formats . . . . . . . . . . . . . . . . . . 3.5. Reply Message Formats . . . . . . . . . . . . . . . . . .
3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . .
3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.1. New Object Functions . . . . . . . . . . . . . . . . .
3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .
3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .
3.8. Non-Support by Back-Level PCE Implementations. . . . . . . 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .
3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . . 3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . .
3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . 3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . .
3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . 3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . .
3.12. Synchronization of P2MP TE Path Computation Requests . . . 3.12. Synchronization of P2MP TE Path Computation Requests . . .
3.13. Multi-Message Support . . . . . . . . . . . . . . . . . . 3.13. Request and Response Fragmentation . . . . . . . . . . . .
3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .
3.13.2 Response Fragmentation Procedure . . . . . . . . . . .
3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . .
3.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . 3.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . .
3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .
4. Manageability Considerations . . . . . . . . . . . . . . . . . 4. Manageability Considerations . . . . . . . . . . . . . . . . .
4.1. Control of Function and Policy . . . . . . . . . . . . . . 4.1. Control of Function and Policy . . . . . . . . . . . . . .
4.2. Information and Data Models . . . . . . . . . . . . . . . 4.2. Information and Data Models . . . . . . . . . . . . . . .
4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .
4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 4.4. Verifying Correct Operation . . . . . . . . . . . . . . .
4.5. Requirements on Other Protocols and Functional 4.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . Components . . . . . . . . . . . . . . . . . . . . . . . .
4.6. Impact on Network Operation . . . . . . . . . . . . . . . 4.6. Impact on Network Operation . . . . . . . . . . . . . . .
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
6.1 New Object Functions . . . . . . . . . . . . . . . . . . .
6.2 New Metric Object Types . . . . . . . . . . . . . . . . .
5.3 UNREACH_DESTINATION objects . . . . . . . . . . . . . . .
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . .
8.2. Informative References . . . . . . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . .
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . .
10. Intellectual Property Consideration. . . . . . . . . . . . . . 10. Intellectual Property Consideration. . . . . . . . . . . . . .
11. Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 11. Disclaimer of Validity . . . . . . . . . . . . . . . . . . . .
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
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
skipping to change at page 4, line 8 skipping to change at page 5, line 25
minimization), or the synchronized computation of a set of paths minimization), or the synchronized computation of a set of paths
(e.g. aggregate bandwidth consumption minimization, etc.). (e.g. aggregate bandwidth consumption minimization, etc.).
P2MP: Point-to-Multipoint. P2MP: Point-to-Multipoint.
P2P: Point-to-Point. P2P: Point-to-Point.
This document also uses the terminology defined in [RFC4655], This document also uses the terminology defined in [RFC4655],
[RFC4875], and [RFC5440]. [RFC4875], and [RFC5440].
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements 2. Requirements
This section summarizes the PCEP requirements specific to Point to This section summarizes the PCEP requirements specific to Point to
Multipoint as described in [PCE-P2MP-REQ]. Multipoint as described in [PCE-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.
skipping to change at page 6, line 20 skipping to change at page 7, line 40
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.
3.3.1. The Extension of RP Object 3.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 to 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 F bit
The M bit is added in the flag bits field of the RP object to signal The M bit is added in the flag bits field of the RP object to signal
the receiver of the message that the request/reply is for P2MP or the receiver of the message that the request/reply is for P2MP or
not. not.
The E bit is added in the flag bits field of the RP object to signal The E bit is added in the flag bits field of the RP object to signal
the receiver of the message that the route is in the compress format the receiver of the message that the route is in the compress format
or not. or not.
The extended format of the RP object body to include the M bit and The extended format of the RP object body to include the F bit, M
the E bit is as follows: bit and the E bit is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |E|M| O|B|R| Pri | | Reserved | Flags |F|E|M| |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RP Object Body Format Figure 1: RP Object Body Format
skipping to change at page 7, line 10 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.
o F ( RP fragmentation bit - 1 bit):
0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver
need to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0.
3.3.2. The New P2MP END-POINTS Object 3.3.2. The New P2MP END-POINTS Object
To represent the end points for a P2MP path efficiently, we define a To represent the end points for a P2MP path efficiently, we define a
new type of end-points object for P2MP path. new type of end-points object for 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 6 skipping to change at page 9, line 36
number of destinations. number of destinations.
Note that A P2MP path computation request can mix the different type Note that A P2MP path computation request can mix the different type
of leaves by including several END-POINTS object per RP object as of leaves by including several END-POINTS object per RP object as
shown in PCReq BNF format in next section. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
skipping to change at page 8, line 20 skipping to change at page 10, line 4
| 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Source IPv6 address (16 bytes) | | Source IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
skipping to change at page 9, line 7 skipping to change at page 10, line 34
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
3.4. Request Message Formats 3.4. Request Message Formats
As per [RFC5511] the format of the PCReq message is as follows.
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
Below is the message format for the request message: Below is the message format for the request message:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<request> <request>
where: where:
<request>::= <RP with P2MP flag and ERO-Compress bit> <request>::= <RP>
<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>][<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 4: The Message Format for the Request Message
Note we preserve compatibility with the [RFC5440] definition of
<request>. At least one instance of <endpoints> must be present
in this definition.
3.5. Reply Message Formats 3.5. Reply Message Formats
As per [RFC5511] the format of the PCRep message is as follows.
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response> <response>
<response>::=<RP with P2MP flag and ERO-Compress bit> <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 5: The Message Format for the Reply Message
The optional END-POINTS in the reply message is used to specify which The optional END-POINTS in the reply message is used to specify which
paths are removed, changed, not changed, or added for the request. paths are removed, changed, not changed, or added for the request.
The path is only needed for the end points which are added or The path is only needed for the end points which are added or
changed. changed.
If the ERO-Compress bit was set to 1 in request then the path will be If the ERO-Compress bit was set to 1 in 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.
Note we preserve compatibility with the [RFC5440] definition of
<response> and the optional <end-point-pair-list> and <path>.
3.6. P2MP Objective Functions and Metric Types 3.6. P2MP Objective Functions and Metric Types
3.6.1. New Object Functions 3.6.1. New Object Functions
Six objective functions have been defined in [PCE-OF] for P2P path Six objective functions have been defined in [RFC5541] for P2P path
computation. computation.
This document defines two additional objective functions, namely SPT This document defines two additional objective functions, namely SPT
(Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP
path computation. Hence two new objective function codes have to be path computation. Hence two new objective function codes have to be
defined. defined.
The description of the two new objective functions is as follows. The description of the two new objective functions is as follows.
Objective Function Code: 7 (suggested value, to be assigned by IANA) Objective Function Code: 7 (suggested value, to be assigned by IANA)
skipping to change at page 10, line 45 skipping to change at page 12, line 48
Objective Function Code: 8 (suggested value, to be assigned by IANA) Objective Function Code: 8 (suggested value, to be assigned by IANA)
Name: Minimum Cost Tree (MCT) Name: Minimum Cost Tree (MCT)
Description: Minimize the total cost of the tree, that is the sum of Description: Minimize the total cost of the tree, that is the sum of
the costs of tree links, with respect to a specific metric or to the the costs of tree links, with respect to a specific metric or to the
TE metric used as the default metric when the metric is not TE metric used as the default metric when the metric is not
specified.. specified..
Processing these two new objective functions is subject to the rules Processing these two new objective functions is subject to the rules
defined in [PCE-OF]. defined in [RFC5541].
3.6.2. New Metric Object Types 3.6.2. New Metric Object Types
There are three types defined for the <METRIC> object in [RFC5440], There are three types defined for the <METRIC> object in [RFC5440],
namely, the IGP metric, the TE metric and the hop count metric. This namely, the IGP metric, the TE metric and the hop count metric. This
document defines three other types for the <METRIC> object: the P2MP document defines three other types for the <METRIC> object: the P2MP
IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They
encode the sum of the metrics of all links of the tree. We propose encode the sum of the metrics of all links of the tree. We propose
the following values for these new metric types (to be assigned by the following values for these new metric types (to be assigned by
IANA): IANA):
skipping to change at page 12, line 7 skipping to change at page 14, line 7
3.9. P2MP TE Path Re-optimization Request 3.9. P2MP TE Path Re-optimization Request
The re-optimization 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> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 3
where: RRO list
OF (optional)
<request>::=<RP with P2MP flag/R bits set>
<END-POINTS for leaf type 3><RRO list>
[OF]
Figure 6: PCReq Message Example 1 for Optimization Figure 6: PCReq Message Example 1 for Optimization
In this example, we request re-optimization of path to all leaves In this example, we request re-optimization of path to all leaves
without adding or pruning leaves. That is only one END-POINT of type without adding or pruning leaves. That is only one END-POINT of type
3. The RRO list is representing the P2MP LSP before the optimization 3. The RRO list is representing the P2MP LSP before the optimization
and the modifiable path leaves are indicated in the END-POINTS and the modifiable path leaves are indicated in the END-POINTS
object. object.
Optionally it is possible to specify some leaves whose path cannot be Optionally it is possible to specify 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> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 3
where: RRO list
END-POINTS for leaf type 4
<request>::=<RP with P2MP flag/R bits set> RRO list
<END-POINTS for leaf type 3><RRO list> OF (optional)
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 7: PCReq Message Example 2 for Optimization Figure 7: PCReq Message Example 2 for Optimization
3.10. Adding/pruning Leaves 3.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.
skipping to change at page 13, line 22 skipping to change at page 15, line 15
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.
So eventually the following cases are possible when modifying an So eventually the following cases are possible when modifying an
existing P2MP LSP: existing P2MP LSP:
Case 1: Adding leaves with full reoptimization of existing paths Case 1: Adding leaves with full reoptimization of existing paths
<PCReq Message>::= <Common Header> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 3
where: RRO list
END-POINTS for leaf type 4
<request>::=<RP with P2MP flag/R bits set> RRO list
<END-POINTS for leaf type 3><RRO list> OF (optional)
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 8: Adding Leaves with Full Reoptimization Figure 8: Adding Leaves with Full Reoptimization
Case 2: Adding leaves with partial reoptimization of existing paths Case 2: Adding leaves with partial reoptimization of existing paths
<PCReq Message>::= <Common Header> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 1
where: END-POINTS for leaf type 3
RRO list
<request>::=<RP with P2MP flag/R bits set> END-POINTS for leaf type 4
<END-POINTS for leaf type 1> RRO list
<END-POINTS for leaf type 3><RRO list> OF (optional)
<END-POINTS for leaf type 4><RRO list>
[OF]
Figure 9: Adding Leaves with Partial Reoptimization Figure 9: Adding Leaves with Partial Reoptimization
Case 3: Adding leaves without reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where: Case 3: Adding leaves without reoptimization of existing paths
<request>::=<RP with P2MP flag/R bits set> Common Header
<END-POINTS for leaf type 3><RRO list> RP with P2MP flag/R bits set
<END-POINTS for leaf type 4><RRO list> END-POINTS for leaf type 3
[OF] RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 10: Adding Leaves without Reoptimization Figure 10: Adding Leaves without Reoptimization
Common Header
<PCReq Message>::= <Common Header> RP with P2MP flag/R bits set
<request> END-POINTS for leaf type 2
RRO list
where: END-POINTS for leaf type 3
RRO list
<request>::=<RP with P2MP flag/R bits set> OF (optional)
<END-POINTS for leaf type 2><RRO list>
<END-POINTS for leaf type 3><RRO list>
[OF]
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
<PCReq Message>::= <Common Header> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 2
where: RRO list
END-POINTS for leaf type 3
<request>::=<RP with P2MP flag/R bits set> RRO list
<END-POINTS for leaf type 2><RRO list> END-POINTS for leaf type 4
<END-POINTS for leaf type 3><RRO list> RRO list
<END-POINTS for leaf type 4><RRO list> OF (optional)
[OF]
Figure 12: Pruning Leaves with Partial Reoptimization Figure 12: Pruning Leaves with Partial Reoptimization
Case 6: Pruning leaves without reoptimization of existing paths
<PCReq Message>::= <Common Header>
<request>
where: Case 6: Pruning leaves without reoptimization of existing paths
<request>::=<RP with P2MP flag/R bits set> Common Header
<END-POINTS for leaf type 2><RRO list> RP with P2MP flag/R bits set
<END-POINTS for leaf type 4><RRO list> END-POINTS for leaf type 2
[OF] RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 13: Pruning Leaves without Reoptimization Figure 13: Pruning Leaves without Reoptimization
Case 7: Adding and pruning leaves full reoptimization of existing Case 7: Adding and pruning leaves full reoptimization of existing
paths paths
<PCReq Message>::= <Common Header> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 1
where: END-POINTS for leaf type 2
RRO list
<request>::=<RP with P2MP flag/R bits set> END-POINTS for leaf type 3
<END-POINTS for leaf type 1> RRO list
<END-POINTS for leaf type 2><RRO list> OF (optional)
<END-POINTS for leaf type 3><RRO list>
[OF]
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
<PCReq Message>::= <Common Header> Common Header
<request> RP with P2MP flag/R bits set
END-POINTS for leaf type 1
where: 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 (optional)
<request>::=<RP with P2MP flag/R bits set> Figure 15: Adding and Pruning Leaves with Partial
<END-POINTS for leaf type 1> Reoptimization
<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 Case 9: Adding and pruning leaves without reoptimization of existing
paths paths
<PCReq Message>::= <Common Header>
<request>
where:
<request>::=<RP with P2MP flag/R bits set> Common Header
<END-POINTS for leaf type 1> RP with P2MP flag/R bits set
<END-POINTS for leaf type 2><RRO list> END-POINTS for leaf type 1
<END-POINTS for leaf type 4><RRO list> END-POINTS for leaf type 2
[OF] RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)
Figure 16: Adding and Pruning Leaves without Reoptimization Figure 16: Adding and Pruning Leaves without Reoptimization
3.11. Branch Nodes 3.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]. [PCE-P2MP-REQ].
3.12. Synchronization of P2MP TE Path Computation Requests 3.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs' computations need to be There are cases when multiple P2MP LSPs' computations need to be
synchronized. For example, one P2MP LSP is the 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> Common Header
<SVEC for sync of LSP1 and LSP2>[OF] SVEC for sync of LSP1 and LSP2
<request-list> OF (optional)
where: END-POINTS1 for P2MP
RRO1 list
<request-list>::=<request1><request2> END-POINTS2 for P2MP
<request1>::= <RP with P2MP flag> RRO2 list
<END-POINTS1 for P2MP>
<RRO1 list>
[<BANDWIDTH1>]
<request2>::= <RP with P2MP flag>
<END-POINTS2 for P2MP>
<RRO2 list>
[<BANDWIDTH2>]
Figure 17: PCReq Message Example for Synchronization Figure 17: PCReq Message Example for Synchronization
We propose that two new flags are also added to the SVEC object for We propose that two new flags are also added to the SVEC object for
path dependent computation requests. The first new flag is to allow path dependent computation requests. The first new flag is to allow
the PCC to request that the PCE should compute a secondary P2MP path the PCC to request that the PCE should compute a secondary P2MP path
tree with partial path diversity for specific leaves or a specific tree with partial path diversity for specific leaves or a specific
S2L sub- path to the primary P2MP path tree. The second flag, would S2L sub- path to the primary P2MP path tree. The second flag, would
allow the PCC to request that partial paths should be link allow the PCC to request that partial paths should be link
direction diverse. direction diverse.
3.13. Multi-Message Support 3.13. Request and Response Fragmentation
The solution follows synchronization procedures defined in [RFC5440]. In certain scenarios the request may not fit into a single request or
response message. For example, if a tree has many hundreds or
thousands of leaves. Then the request or response may need to
be fragmented into multiple messages.
If the P2MP request (i.e. <RP><END-POINTS>) is too large to fit into The F bit has been outlined in section 3.3.1. The Extension of RP
a single message it is permitted to divide it into multiple requests Object, of this document. The F bit is used in the RP object header
that would be carried in different messages. That means that a P2MP to signal that the an intial request or response was too large to fit
request would then contain multiple requests with RP objects that into a single message and should therfore be fragmented into
have the same request IDs. multiple requests. In order to indentify the single request or
response, each message will use the same request ID.
Here is an example of such P2MP request that is divided in 2 request 3.13.1 Request Fragmentation Procedure
messages:
<PCReq Message1>::= <Common Header> If the intial request is too large to fit into a single request
<SVEC, the Req-ID1 is repeated 2 times> message the PCC will split the requst over multiple messages. Each
<request> message sent to the PCE will have the F bit set in the RP object
to signify that the request has been fragmented into multiple
messages. In order to indentify that a series of request messages
represents a single request, each message will use the same
request ID.
where: The assumption is that request messages are reliably delivered
and in sequence since PCEP relies on TCP.
<request>::=< RP with Req-ID1 > 3.13.2 Response Fragmentation Procedure
<END-POINTs for P2MP>
<RRO list>
<PCReq Message2>::= <Common Header> Once the PCE computes a path based on the intial request a
<request> response is sent back to the PCC. If the response is too large to fit
into a single response message the PCE will split the requst over
multiple messages. Each message sent to the PCE with the F bit set
in the RP object to signify that the response has been fragmented
into multiple messages. In order to indentify that a series of
response messages represents a single request, each message will
use the same request ID.
where: The assumption is that response messages are reliably delivered
and in sequence since PCEP relies on TCP.
<request>::=< RP with Req-ID1> 3.13.3 Fragmentation Examples
<END-POINTs for P2MP>
<RRO list>
Figure 18: PCReq Message Example for Message Fragmentation The following example illustrates the request message with Req-ID1,
which adds one leaf to a 1200 leaves existing tree, is sent to the
PCE. The assumption is that the one request message can hold up to
800 leaves. In these conditions, the original one message needs to be
sent over by two small messages, which have the Req-ID1 specified in
the RP object and F bit set for the first message.
Note that the SVEC object contains the same request Id repeated N Common Header
times where N is the total number of RP objects included in all RP1 with Req-ID1 and P2MP flag and F bit set
messages. This is to be able to detect that the whole P2MP request OF (optional)
has been received. Note that this assumes that the transmission of END-POINTS1 for P2MP
the messages is performed reliably and in consistent order, which is RRO1 list
not a problem since PCEP relies on TCP.
To avoid the backward compatible problem when a PCE that does not Common Header
support P2MP extensions receives an SVEC with same request Id twice, RP2 with Req-ID1 and P2MP flag and F bit cleared
such message MUST NOT be sent to a non P2MP capable PCE. Thanks to OF (optional)
the OPEN message discovery mechanism this is possible to known. END-POINTS1 for P2MP
RRO1 list
We propose to use the SVEC/synctimer mechanism also for PCRep message To handle the case that the last fragmented message piece is lost, the
(in case of too large response message). This was not defined in receiver side of the fragmented message may start a timer once it
The PCEP base draft. We propose that this feature should be defined receives the first piece of the fragmented message. When timer expires
in The future version of the PCEP draft. and it still doesn't receive the last piece of the fragmented message,
it should send an error message to the receiver to signal that it
have recieved an incomplete message.
3.14. UNREACH_DESTINATION object 3.14. UNREACH_DESTINATION object
The PCE path computation request may fail because all or a subset of The PCE path computation request may fail because all or a subset of
the destinations are unreachable. the destinations are unreachable.
In such a case, the UNREACH-DESTINATION object allows the PCE to In such a case, the UNREACH-DESTINATION object allows the PCE to
optionally specify the list of unreachable destinations. optionally specify the list of unreachable destinations.
This object can be present in PCRep messages. There can be up to one This object can be present in PCRep messages. There can be up to one
skipping to change at page 18, line 24 skipping to change at page 21, line ?
3.14. UNREACH_DESTINATION object 3.14. UNREACH_DESTINATION object
The PCE path computation request may fail because all or a subset of The PCE path computation request may fail because all or a subset of
the destinations are unreachable. the destinations are unreachable.
In such a case, the UNREACH-DESTINATION object allows the PCE to In such a case, the UNREACH-DESTINATION object allows the PCE to
optionally specify the list of unreachable destinations. optionally specify the list of unreachable destinations.
This object can be present in PCRep messages. There can be up to one This object can be present in PCRep messages. There can be up to one
such object per RP. such object per RP.
UNREACH_DESTINATION Object-Class is to be assigned by IANA. UNREACH_DESTINATION Object-Class is to be assigned by IANA.
UNREACH_DESTINATION Object-Type for IPv4 is to be assigned by IANA UNREACH_DESTINATION Object-Type for IPv4 is to be assigned by IANA
UNREACH_DESTINATION Object-Type for IPv6 is to be assigned by IANA. UNREACH_DESTINATION Object-Type for IPv6 is to be assigned by IANA.
The format of the UNREACH_DESTINATION object body for IPv4 (Object- The format of the UNREACH_DESTINATION object body for IPv4 (Object-
Type=1) is as follows: Type=1) is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: UNREACH_DESTINATION Object Body for IPv4 Figure 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 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) |
skipping to change at page 20, line 12 skipping to change at page 22, line 39
(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.
3.16. PCEP NO-PATH Indicator 3.16. PCEP NO-PATH Indicator
To communicate the reason(s) for not being able to find P2MP path To communicate the 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: The Format of the NO-PATH Object Body Figure 21: The Format of the NO-PATH Object Body
One new bit flags is defined in the NO-PATH-VECTOR TLV carried in
One new bit 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.
4. Manageability Considerations 4. Manageability Considerations
[PCE-P2MP-REQ] describes various manageability requirements in [PCE-P2MP-REQ] describes various manageability requirements in
skipping to change at page 21, line 19 skipping to change at page 24, line 8
4.3. Liveness Detection and Monitoring 4.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[RFC5440], since [PCE-P2MP-REQ] does not address any additional [RFC5440], since [PCE-P2MP-REQ] does not address any additional
requirements. requirements.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[PCEP], 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 As described in [PCE-P2MP-REQ], the PCE MUST obtain information
about the P2MP signaling and branching capabilities of each LSR in about the P2MP signaling and branching capabilities of each LSR in
the network. the network.
Protocol extensions specified in this document does not provide such Protocol extensions specified in this document does not provide such
capability. Other mechanisms MUST be present. capability. Other mechanisms MUST be present.
4.6. Impact on Network Operation 4.6. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document It is expected that use of PCEP extensions specified in this document
does not have significant impact on network operations. does not have significant impact on network operations.
5. Security Considerations 5. Security Considerations
As described in [PCE-P2MP-REQ], P2MP path computation requests are As described in [PCE-P2MP-REQ], P2MP path computation requests are
more CPU-intensive and also use more link bandwidth. Therefore, it more CPU-intensive and also use more link bandwidth. Therefore, it
may be more vulnerable to denial of service attacks. may be more vulnerable to denial of service attacks. Therefore it is
more important that implementations conform to security requirements
[PCEP] describes various mechanisms for denial of service attacks, of [RFC5440], and the implementor utilize those security features
and these tools MAY be advantageously used.
6. IANA Considerations 6. IANA Considerations
A number of IANA considerations have been highlighted in the relevant A number of IANA considerations have been highlighted in previous
sections of this document. Further clarifications of these requests sections of this document. In summary, IANA is requested to make
will be made in a future version of this document. allocations for the following PCEP parameters.
6.1 New Object Functions
Objective Function Code: 7 (suggested value)
Name: Shortest Path Tree (SPT)
Objective Function Code: 8 (suggested value)
Name: Minimum Cost Tree (MCT)
6.2 New Metric Object Types
P2MP IGP metric: T=4 (suggested value)
P2MP TE metric: T=5 (suggested value)
P2MP hop count metric: T=6 (suggested value)
6.3 UNREACH_DESTINATION objects
UNREACH_DESTINATION Object-Class
UNREACH_DESTINATION Object-Type for IPv4
UNREACH_DESTINATION Object-Type for IPv6
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable
comments on this draft. comments on this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 22, line 32 skipping to change at page 25, line 40
[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.
[PCE-P2MP-REQ] [RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax
Yasukawa, S. and A. Farrel, "PCC-PCE Communication Used to Form Encoding Rules in Various Routing Protocol
Requirements for Point to Multipoint Multiprotocol Label Specifications", RFC 5511, April 2009.
Switching Traffic Engineering (MPLS-TE)",
draft-ietf-pce-p2mp-req-01 (work in progress),
February 2008.
[PCE-OF] [RFC5541]
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
Functions in the Path Computation Element Communication Functions in the Path Computation Element Communication
Protocol (PCEP)", draft-ietf-pce-of-06 (work in progress), Protocol (PCEP)", RFC5541, December 2008.
December 2008.
8.2. Informative References 8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[PCE-P2MP-APP] [PCE-P2MP-APP]
Yasukawa, S. and A. Farrel, Yasukawa, S. and A. Farrel,
"draft-ietf-pce-p2mp-app-01.txt", "draft-ietf-pce-p2mp-app-01.txt",
draft-ietf-pce-p2mp-app-01 (work in progress), draft-ietf-pce-p2mp-app-01 (work in progress),
February 2009. February 2009.
[PCE-P2MP-REQ]
Yasukawa, S. and A. Farrel, "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)",
draft-ietf-pce-p2mp-req-01 (work in progress),
February 2008.
9. Authors' Addresses 9. Authors' Addresses
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technology Huawei Technology
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US US
Email: qzhao@huawei.com Email: qzhao@huawei.com
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK UK
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Fabien Verhaeghe Fabien Verhaeghe
Marben Products
176 avenue Jean Jaures
92800 Puteaux,
France France
Email: fabien.verhaeghe@marben-products.com Email: fabien.verhaeghe@gmail.com
Tomonori Takeda Tomonori Takeda
NTT Corporation NTT Corporation
3-9-11, Midori-Cho 3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Musashino-Shi, Tokyo 180-8585
Japan Japan
Email: takeda.tomonori@lab.ntt.co.jp Email: takeda.tomonori@lab.ntt.co.jp
Zafar Ali
Cisco systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: zali@cisco.com
Mohamad Chaitou (editor) Julien Meuric
France France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex,
julien.meuric@orange-ftgroup.com
9.1 Contributors
Email: Mohamad. mohamad.chaitou@gmail.com
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, 22307 Lannion Cedex,
France France
Email: Jeanlouis.Leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Zafar Ali Mohamad Chaitou
Cisco systems, Inc. France
2000 Innovation Drive Email: mohamad.chaitou@gmail.com
Kanata, Ontario K2K 3E8
Canada
Email: zali@cisco.com
10. Intellectual Property Consideration Appendix A. RBNF Code Fragments
The IETF Trust takes no position regarding the validity or scope of This appendix contains the full set of code fragments defined in this
any Intellectual Property Rights or other rights that might be document.
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF Copyright (c) 2009 IETF Trust and the persons identified as authors
Secretariat and any assurances of licenses to be made available, or of the code. All rights reserved.
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any Redistribution and use in source and binary forms, with or without
copyrights, patents or patent applications, or other proprietary modification, are permitted provided that the following conditions
rights that may cover technology that may be required to implement are met:
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or o Redistributions of source code must retain the above copyright
under the auspices of, the IETF. Versions of IETF Documents that are notice, this list of conditions and the following disclaimer.
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards o Redistributions in binary form must reproduce the above copyright
Process licenses each Contribution that he or she makes as part of notice, this list of conditions and the following disclaimer in the
the IETF Standards Process to the IETF Trust pursuant to the documentation and/or other materials provided with the
provisions of RFC 5378. No language to the contrary, or terms, distribution.
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
11. Disclaimer of Validity o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
All IETF Documents and the information contained therein are provided Below is the message format for the request message:
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
12. Full Copyright Statement <PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
Copyright (c) 2009 IETF Trust and the persons identified as the where:
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal <end-point-rro-pair-list>::=
Provisions Relating to IETF Documents in effect on the date of <END-POINTS>[<RRO-List>][<BANDWIDTH>]
publication of this document (http://trustee.ietf.org/license-info). [<end-point-rro-pair-list>]
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Below is the bessage format for the reply message:
Below is the message format for the reply message:
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::=(ERO)|(SERO)|<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
 End of changes. 100 change blocks. 
276 lines changed or deleted 333 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/