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
Abstract
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.
Status of This Memo
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 Notice
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
Palle & Dhody Expires July 29, 2014 [Page 1]
Internet-Draft STATEFUL-P2MP January 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 4
5. Architectural Overview of Protocol Extensions . . . . . . . . 5
5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 5
5.2. Capability Advertisement . . . . . . . . . . . . . . . . 5
5.3. State Synchronization . . . . . . . . . . . . . . . . . . 6
5.4. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 6
5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6
5.5.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 6
5.5.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 6
6. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 6
6.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 6
6.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 7
7. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 8
7.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 8
7.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 9
7.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 10
7.3.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 11
7.4. Report and Update Message Fragmentation . . . . . . . . . 11
7.4.1. Report Fragmentation Procedure . . . . . . . . . . . 11
7.4.2. Update Fragmentation Procedure . . . . . . . . . . . 12
8. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Manageability Considerations . . . . . . . . . . . . . . . . 12
10.1. Control of Function and Policy . . . . . . . . . . . . . 13
10.2. Information and Data Models . . . . . . . . . . . . . . 13
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 13
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 13
10.5. Requirements On Other Protocols . . . . . . . . . . . . 13
10.6. Impact On Network Operations . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11.1. Extension of LSP Object . . . . . . . . . . . . . . . . 13
11.2. Extension of PCEP-Error Object . . . . . . . . . . . . . 14
11.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 14
Palle & Dhody Expires July 29, 2014 [Page 2]
Internet-Draft STATEFUL-P2MP January 2014
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
1.1. 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 [RFC2119].
2. Terminology
Terminology used in this document is same as terminology used in
[I-D.ietf-pce-stateful-pce] and [RFC6006].
Palle & Dhody Expires July 29, 2014 [Page 3]
Internet-Draft STATEFUL-P2MP January 2014
3. Supporting P2MP TE LSP for Stateful PCE
3.1. Motivation
[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).
3.2. Objectives
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].
4. Functions to Support P2MP TE LSPs for Stateful PCEs
[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.
Capability Advertisement (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP
Stateful PCE extensions for P2MP using mechanisms defined in
[I-D.ietf-pce-stateful-pce] and [RFC6006].
LSP State Synchronization (C-E): after the session between the PCC
and a stateful PCE with P2MP capability is initialized, the PCE
must learn the state of a PCC's P2MP TE LSPs before it can perform
path computations or update LSP attributes in a PCC.
LSP Update Request (E-C): a stateful PCE with P2MP capability
requests modification of attributes on a PCC's P2MP TE LSP.
Palle & Dhody Expires July 29, 2014 [Page 4]
Internet-Draft STATEFUL-P2MP January 2014
LSP State Report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of a P2MP TE LSP changes.
LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more P2MP TE LSPs; the PCE becomes
the authoritative source of the LSP's attributes as long as the
delegation is in effect (See Section 5.5 of
[I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation
or the PCE may give up the delegation at any time.
[I-D.sivabalan-pce-disco-stateful] and [RFC6006] defines the IGP
extensions needed to support autodiscovery of stateful PCEs with P2MP
capability.
5. Architectural Overview of Protocol Extensions
5.1. Extension of PCEP Messages
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.
Path Computation State Report (PCRpt): Each P2MP TE LSP State Report
in a PCRpt message can contain actual P2MP TE LSP path attributes,
LSP status, etc. An LSP State Report carried on a PCRpt message
is also used in delegation or revocation of control of a P2MP TE
LSP to/from a PCE. The extension of PCRpt message is described in
Section 7.1.
Path Computation Update Request (PCUpd): Each P2MP TE LSP Update
Request in a PCUpd message MUST contain all LSP parameters that a
PCE wishes to set for a given P2MP TE LSP. An LSP Update Request
carried on a PCUpd message is also used to return LSP delegations
if at any point PCE no longer desires control of a P2MP TE LSP.
The PCUpd message is described in Section 7.2.
5.2. Capability Advertisement
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.
Palle & Dhody Expires July 29, 2014 [Page 5]
Internet-Draft STATEFUL-P2MP January 2014
5.3. State Synchronization
State Synchronization operations described in Section 5.4 of
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
5.4. LSP Delegation
LSP delegation operations described in Section 5.5 of
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
5.5. LSP Operations
5.5.1. Passive Stateful PCE
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.]
5.5.2. Active Stateful PCE
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.
6. PCEP Object Extensions
The PCEP TLV defined in this document is compliant with the PCEP TLV
format defined in [RFC5440].
6.1. Extension of LSP Object
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:
N (P2MP bit): If the bit is set to 1, it specifies the message is
for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a
P2MP TE LSP.
F (Fragmentation bit): If the bit is set to 1, it specifies the
message is fragmented.
Palle & Dhody Expires July 29, 2014 [Page 6]
Internet-Draft STATEFUL-P2MP January 2014
If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be
present in LSP object.
6.2. P2MP-LSP-IDENTIFIER TLV
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:
P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in
Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION
Object.
Sub-Group Originator ID: contains the 32-bit 'Sub-Group Originator
ID' identifier defined in Section 19.2.1 of [RFC4875] for the P2MP
LSP Tunnel IPv4 SENDER_TEMPLATE Object.
Palle & Dhody Expires July 29, 2014 [Page 7]
Internet-Draft STATEFUL-P2MP January 2014
Sub-Group ID: contains the 16-bit 'Sub-Group ID' identifier defined
in Section 19.2.1 of [RFC4875] for the P2MP LSP Tunnel IPv4
SENDER_TEMPLATE Object.
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:
P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV.
Sub-Group Originator ID: contains the 128-bit 'Sub-Group Originator
ID' defined in Section 19.2.2 of [RFC4875] for the P2MP LSP Tunnel
IPv6 SENDER_TEMPLATE Object.
Sub-Group ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV.
7. PCEP Message Extensions
7.1. The PCRpt Message
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:
Palle & Dhody Expires July 29, 2014 [Page 8]
Internet-Draft STATEFUL-P2MP January 2014
<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.
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>].
7.2. The PCUpd Message
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:
Palle & Dhody Expires July 29, 2014 [Page 9]
Internet-Draft STATEFUL-P2MP January 2014
<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.
Note that we preserve compatibility with the
[I-D.ietf-pce-stateful-pce] definition of <update-request>.
7.3. Example
7.3.1. P2MP TE LSP 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.
Palle & Dhody Expires July 29, 2014 [Page 10]
Internet-Draft STATEFUL-P2MP January 2014
7.3.2. P2MP TE LSP Report
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
7.4. Report and Update Message Fragmentation
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.
7.4.1. Report Fragmentation Procedure
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
Palle & Dhody Expires July 29, 2014 [Page 11]
Internet-Draft STATEFUL-P2MP January 2014
messages represents a single report, each message will use the same
PLSP-ID.
7.4.2. Update Fragmentation Procedure
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].
8. Non-Support of P2MP TE LSPs for Stateful PCE
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]
9. Security Considerations
TBD
10. Manageability Considerations
Palle & Dhody Expires July 29, 2014 [Page 12]
Internet-Draft STATEFUL-P2MP January 2014
10.1. Control of Function and Policy
TBD.
10.2. Information and Data Models
TBD.
10.3. Liveness Detection and Monitoring
TBD.
10.4. Verify Correct Operations
TBD.
10.5. Requirements On Other Protocols
TBD.
10.6. Impact On Network Operations
TBD.
11. IANA Considerations
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.
11.1. Extension of LSP Object
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:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Palle & Dhody Expires July 29, 2014 [Page 13]
Internet-Draft STATEFUL-P2MP January 2014
Bit Description Reference
24 P2MP This.I-D
23 Fragmentation This.I-D
11.2. Extension of PCEP-Error Object
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.
11.3. PCEP TLV Type Indicators
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
12. Acknowledgments
Thanks to Quintin Zhao for his comments.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
Regional Registration", RFC 4857, June 2007.
Palle & Dhody Expires July 29, 2014 [Page 14]
Internet-Draft STATEFUL-P2MP January 2014
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
[RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
Computation Element (PCE) to Point-to-Multipoint (P2MP)
MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
October 2009.
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
and J. Meuric, "Extensions to the Path Computation Element
Communication Protocol (PCEP) for Point-to-Multipoint
Traffic Engineering Label Switched Paths", RFC 6006,
September 2010.
[I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path
Computation Element (PCE)", draft-ietf-pce-stateful-pce-
app-01 (work in progress), September 2013.
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-07 (work in progress), October 2013.
[I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", draft-sivabalan-pce-disco-
stateful-02 (work in progress), July 2013.
Authors' Addresses
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
Palle & Dhody Expires July 29, 2014 [Page 15]
Internet-Draft STATEFUL-P2MP January 2014
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.ietf@gmail.com
Palle & Dhody Expires July 29, 2014 [Page 16]