| PCE Working Group | U. Palle |
| Internet-Draft | D. Dhody |
| Intended status: Standards Track | Huawei Technologies |
| Expires: July 29, 2014 | January 25, 2014 |
Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-palle-pce-stateful-pce-p2mp-01
The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. [I-D.ietf-pce-stateful-pce-app] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE. [I-D.ietf-pce-stateful-pce] provides the fundamental PCE communication Protocol (PCEP) extensions needed to support stateful PCE functions. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in supporting point-to-multipoint (P2MP) TE LSPs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2014.
Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
As per [RFC4655], the Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]).
The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC6006].
Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the fundamental extensions needed for stateful PCE to support general functionality for P2P TE LSP. Complementarily, this document focuses on the extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs.
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 [RFC2119].
Terminology used in this document is same as terminology used in [I-D.ietf-pce-stateful-pce] and [RFC6006].
[I-D.ietf-pce-stateful-pce-app] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc. [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE LSPs in applying these scenarios. But these scenarios apply equally to P2MP TE LSPs as well.
In addition to that, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via PLSP-ID. For P2MP this is an added advantage, where the size of message is much larger. Incase of stateless PCE, a modification of P2MP tree requires encoding of all leaves along with the paths in PCReq message, but using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the modifications (the other information can be retrieved from the LSP identifier).
The objectives for the protocol extensions to support P2MP TE LSP for stateful PCE are same as the objectives described in section 3.2 of [I-D.ietf-pce-stateful-pce].
[I-D.ietf-pce-stateful-pce] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).
This document extends these functions to support P2MP TE LSPs.
[I-D.sivabalan-pce-disco-stateful] and [RFC6006] defines the IGP extensions needed to support autodiscovery of stateful PCEs with P2MP capability.
New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to support stateful PCE for P2P TE LSPs. In this document these messages are extended to support P2MP TE LSPs.
During PCEP Initialization Phase, as per Section 7.1.1 of [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful capability via Stateful PCE Capability TLV in open message and as per Section 3.1 of [RFC6006], PCE advertises P2MP capability via IGP discovery or a P2MP capable TLV in open message. These mechanism when used together indicates a stateful PCE with P2MP capability.
State Synchronization operations described in Section 5.4 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
LSP delegation operations described in Section 5.5 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
LSP operations for passive stateful PCE described in Section 5.6.1 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
The Path Computation Request and Response message format for P2MP TE LSPs is as per Section 3.4 and Section 3.5 of [RFC6006] respectively.
[Editor's Note: The Request and Response message should support LSP object, so that it is possible to refer to a LSP with a unique identifier and simplify the PCEP message exchange. for example, incase of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in PCReq message.]
LSP operations for active stateful PCE described in Section 5.6.2 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
The PCEP TLV defined in this document is compliant with the PCEP TLV format defined in [RFC5440].
LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. This document adds the following flags to the LSP Object:
If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be present in LSP object.
The P2MP LSP Identifier TLV MUST be included in the LSP object in PCRpt message for RSVP-signaled P2MP TE LSPs. If the TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and error-value TBD (12) (P2MP-LSP-IDENTIFIERS TLV missing) and close the PCEP session.
The P2MP LSP Identifier TLV MAY be included in the LSP object in PCUpd message for RSVP-signaled P2MP TE LSPs. The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID.
There are two P2MP LSP Identifier TLVs, one for IPv4 and one for IPv6.
The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPV4-P2MP-LSP-IDENTIFIER TLV format
The type of the TLV is [TBD] and it has a fixed length of 12 octets. The value contains the following fields:
The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Sub-Group Originator ID |
| |
| (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPV6-P2MP-LSP-IDENTIFIER TLV format
The type of the TLV is [TBD] and it has a fixed length of 24 octets. The value contains the following fields:
As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is used to report the current state of a P2P TE LSP. This document extends the PCRpt message in reporting the status of P2MP TE LSP.
The format of PCRpt message is as follows:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<end-point-path-pair-list>
<attribute-list>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>)
[<RRO>]
[<path>]
<attribute-list> is defined in [RFC5440] and extended
by PCEP extensions.
Figure 3
The END-POINTS object defined in [RFC6006] is mandatory for specifying address of P2MP leaves.
Note that we preserve compatibility with the [I-D.ietf-pce-stateful-pce] definition of <state-report>. At least one instance of <END-POINTS> MUST be present in this message.
[Editor Note: suggest to add <END-POINTS> object mandatory in [I-D.ietf-pce-stateful-pce] document for <state-report>].
As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is used to update P2P TE LSP attributes. This document extends the PCUpd message in updating the attributes of P2MP TE LSP.
The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<end-point-path-pair-list>
<attribute-list>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>)
[<path>]
<attribute-list> is defined in [RFC5440] and extended
by PCEP extensions.
Figure 4
Note that we preserve compatibility with the [I-D.ietf-pce-stateful-pce] definition of <update-request>.
LSP Update Request message is sent by an active stateful PCE to update the P2MP TE LSP parameters or attributes. An example of a PCUpd message for P2MP TE LSP is described below:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
In this example, a stateful PCE request updation of path taken by some of the leaves in a P2MP tree. The update request uses the END-POINT type 3 (modified/reoptimized). The ERO list represents the S2L path after modification. The update message does not need to encode the full P2MP tree in this case.
LSP State Report message is sent by a PCC to report or delegate the P2MP TE LSP. An example of a PCRpt message for P2MP TE LSP is described below to add new leaves to an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1
ERO list
An example of a PCRpt message for P2MP TE LSP is described below to prune leaves from an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 2
ERO list (empty)
An example of a PCRpt message for P2MP TE LSP is described below to report status of modified leaves in an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
The total PCEP message length, including the common header, is 16 bytes. In certain scenarios the P2MP report and update request may not fit into a single PCEP message (initial report or update). The F-bit is used in the LSP object to signal that the initial report or update was too large to fit into a single message and will be fragmented into multiple messages. In order to identify the single report or update, each message will use the same PLSP-ID.
Fragmentation procedure described below for report or update message is similar to [RFC6006] which describes request and response message fragmentation.
If the initial report is too large to fit into a single report message, the PCC will split the report over multiple messages. Each message sent to the PCE, except the last one, will have the F-bit set in the LSP object to signify that the report has been fragmented into multiple messages. In order to identify that a series of report messages represents a single report, each message will use the same PLSP-ID.
Once the PCE computes and updates a path for some or all leaves in a P2MP TE LSP, an update message is sent to the PCC. If the update is too large to fit into a single update message, the PCE will split the update over multiple messages. Each update message sent by the PCE, except the last one, will have the F-bit set in the LSP object to signify that the update has been fragmented into multiple messages. In order to identify that a series of update messages represents a single update, each message will use the same PLSP-ID and SRP-ID-number.
[Editor Note: P2MP message fragmentation errors associated with a P2MP path report and update will be defined in future version].
The PCEP protocol extensions described in this document for stateful PCEs with P2MP capability MUST NOT be used if PCE has not advertised its stateful capability with P2MP as per Section 5.2. If this is not the case and Stateful operations on P2MP TE LSPs are attempted, then a PCErr with error-type 19 (Invalid Operation) and error-value TBD needs to be generated.
If a Stateful PCE receives a P2MP TE LSP report message and it understands the P2MP flag in the LSP object, but the stateful PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with error-type 19 (Invalid Operation) and error-value TBD.
If a Stateful PCE receives a P2MP TE LSP report message and the PCE does not understand the P2MP flag in the LSP object, and therefore the PCEP extensions described in this document, then the PCE SHOULD reject the request.
[Editor Note: more information on exact error value is needed]
TBD
TBD.
TBD.
TBD.
TBD.
TBD.
TBD.
This document requests IANA actions to allocate code points for the protocol elements defined in this document. Values shown here are suggested for use by IANA.
This document requests that a registry is created to manage the Flags field of the LSP object. New values are to be assigned by Standards Action [RFC5226]. Each bit should be tracked with the following qualities:
The following values are defined in this document:
Bit Description Reference
24 P2MP This.I-D
23 Fragmentation This.I-D
A new error types 6 and 19 defined in section 8.4 of [I-D.ietf-pce-stateful-pce]. This document extend the new Error-Values for those error types for the following error conditions:
Error-Type Meaning
6 Mandatory Object missing
Error-value=12: P2MP-LSP-IDENTIFIER TLV missing
19 Invalid Operation
Error-value= TBD.
This document defines the following new PCEP TLVs:
Value Meaning Reference
22 P2MP-IPV4-LSP-IDENTIFIERS This.I-D
23 P2MP-IPV6-LSP-IDENTIFIERS This.I-D
Thanks to Quintin Zhao for his comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |