One document matched: draft-palle-pce-stateful-pce-p2mp-01.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-palle-pce-stateful-pce-p2mp-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="STATEFUL-P2MP">Path Computation Element (PCE)
Protocol Extensions for Stateful PCE usage for
Point-to-Multipoint Traffic Engineering Label Switched Paths</title>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>udayasree.palle@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<date month="January" year="2014" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>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.
<xref target='I-D.ietf-pce-stateful-pce-app'></xref> presents
several use cases, demonstrating scenarios that benefit from the
deployment of a stateful PCE.
<xref target='I-D.ietf-pce-stateful-pce'></xref> 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>As per <xref target="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.</t>
<t><xref target="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 (<xref target="RFC5671"/>).</t>
<t>The PCEP is designed as a communication protocol between PCCs and PCEs
for point-to-point (P2P) path computations and is defined in
<xref target="RFC5440"/>. The extensions of PCEP to request path computation
for P2MP TE LSPs are described in <xref target="RFC6006"/>.</t>
<t>Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in
<xref target='I-D.ietf-pce-stateful-pce-app'></xref>. These scenarios apply
equally to P2P and P2MP TE LSPs. <xref target='I-D.ietf-pce-stateful-pce'></xref>
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.</t>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>Terminology used in this document is same as terminology used in
<xref target='I-D.ietf-pce-stateful-pce'></xref> and <xref target="RFC6006"/>.</t>
</section>
<section title="Supporting P2MP TE LSP for Stateful PCE" toc="default" anchor="SEC_M">
<section title="Motivation" toc="default">
<t><xref target='I-D.ietf-pce-stateful-pce-app'></xref> presents several use cases,
demonstrating scenarios that benefit from the deployment of a stateful PCE including
optimization, recovery, etc. <xref target='I-D.ietf-pce-stateful-pce'></xref> defines
the extensions to PCEP for P2P TE LSPs in applying these scenarios. But these scenarios
apply equally to P2MP TE LSPs as well.</t>
<t>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).</t>
</section>
<section title="Objectives" toc="default">
<t>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 <xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
</section>
</section>
<section title="Functions to Support P2MP TE LSPs for Stateful PCEs" toc="default">
<t><xref target='I-D.ietf-pce-stateful-pce'></xref> 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).</t>
<t>This document extends these functions to support P2MP TE LSPs.</t>
<t><list style="hanging">
<t hangText="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
<xref target='I-D.ietf-pce-stateful-pce'></xref> and <xref target="RFC6006"/>.</t>
<t hangText="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.</t>
<t hangText="LSP Update Request (E-C):">a stateful PCE with P2MP capability
requests modification of attributes on a PCC's P2MP TE LSP.</t>
<t hangText="LSP State Report (C-E):">a PCC sends an LSP state report to a PCE
whenever the state of a P2MP TE LSP changes.</t>
<t hangText="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 <xref target='I-D.ietf-pce-stateful-pce'></xref>); the PCC may
withdraw the delegation or the PCE may give up the delegation at any time.</t>
</list>
</t>
<t><xref target='I-D.sivabalan-pce-disco-stateful'></xref> and <xref target="RFC6006"/>
defines the IGP extensions needed to support autodiscovery of stateful PCEs with
P2MP capability.</t>
</section>
<section title="Architectural Overview of Protocol Extensions" toc="default">
<section title="Extension of PCEP Messages" toc="default">
<t>New PCEP messages are defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>
to support stateful PCE for P2P TE LSPs. In this document these messages
are extended to support P2MP TE LSPs.</t>
<t><list style="hanging">
<t hangText="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 <xref target="SEC_RPT"/>.</t>
<t hangText="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 <xref target="SEC_UPD"/>.</t>
</list>
</t>
</section>
<section title="Capability Advertisement" toc="default" anchor="SEC_CA">
<t>During PCEP Initialization Phase, as per Section 7.1.1 of
<xref target='I-D.ietf-pce-stateful-pce'></xref>, PCEP speakers advertises
Stateful capability via Stateful PCE Capability TLV in open message and as
per Section 3.1 of <xref target="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.</t>
</section>
<section title="State Synchronization" toc="default">
<t>State Synchronization operations described in Section 5.4 of
<xref target='I-D.ietf-pce-stateful-pce'></xref> are applicable
for P2MP TE LSPs as well.</t>
</section>
<section title="LSP Delegation" toc="default">
<t>LSP delegation operations described in Section 5.5 of
<xref target='I-D.ietf-pce-stateful-pce'></xref> are applicable
for P2MP TE LSPs as well.</t>
</section>
<section title="LSP Operations" toc="default">
<section title="Passive Stateful PCE" toc="default">
<t>LSP operations for passive stateful PCE described in Section 5.6.1 of
<xref target='I-D.ietf-pce-stateful-pce'></xref> are applicable for P2MP
TE LSPs as well. </t>
<t>The Path Computation Request and Response message format for P2MP
TE LSPs is as per Section 3.4 and Section 3.5 of
<xref target="RFC6006"/> respectively.</t>
<t>[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.]</t>
</section>
<section title="Active Stateful PCE" toc="default">
<t>LSP operations for active stateful PCE described in Section 5.6.2 of
<xref target='I-D.ietf-pce-stateful-pce'></xref> are applicable for
P2MP TE LSPs as well.</t>
</section>
</section>
</section>
<section title="PCEP Object Extensions" toc="default">
<t>The PCEP TLV defined in this document is compliant with the PCEP TLV format defined in <xref target="RFC5440"/>.</t>
<section title="Extension of LSP Object" toc="default">
<t>LSP Object is defined in Section 7.3 of
<xref target='I-D.ietf-pce-stateful-pce'></xref>.
This document adds the following flags to the LSP Object:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="F (Fragmentation bit):">If the bit is set to 1, it specifies
the message is fragmented.</t>
</list></t>
<t>If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be present in LSP object.</t>
</section>
<section title="P2MP-LSP-IDENTIFIER TLV" toc="default">
<t>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.</t>
<t>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.</t>
<t>There are two P2MP LSP Identifier TLVs, one for IPv4 and one for IPv6.</t>
<t>The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="IPV4-P2MP-LSP-IDENTIFIER TLV format" width="" anchor="SEC_FIG1">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is [TBD] and it has a fixed length of 12 octets.
The value contains the following fields:</t>
<t><list style="hanging">
<t hangText="P2MP ID:">contains the 32-bit 'P2MP ID' identifier defined
in Section 19.1.1 of <xref target="RFC4875"/> for the P2MP LSP Tunnel
IPv4 SESSION Object.</t>
<t hangText="Sub-Group Originator ID:">contains the 32-bit 'Sub-Group
Originator ID' identifier defined
in Section 19.2.1 of <xref target="RFC4875"/> for the P2MP LSP Tunnel
IPv4 SENDER_TEMPLATE Object.</t>
<t hangText="Sub-Group ID:">contains the 16-bit 'Sub-Group
ID' identifier defined
in Section 19.2.1 of <xref target="RFC4875"/> for the P2MP LSP Tunnel
IPv4 SENDER_TEMPLATE Object.</t>
</list></t>
<t>The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="IPV6-P2MP-LSP-IDENTIFIER TLV format" width="" anchor="SEC_FIG2">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is [TBD] and it has a fixed length of 24 octets.
The value contains the following fields:</t>
<t><list style="hanging">
<t hangText="P2MP ID:">As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV.</t>
<t hangText="Sub-Group Originator ID:">contains the 128-bit 'Sub-Group
Originator ID' defined in Section 19.2.2 of <xref target="RFC4875"/>
for the P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object.</t>
<t hangText="Sub-Group ID:">As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV.</t>
</list></t>
</section>
</section>
<section title="PCEP Message Extensions" toc="default">
<section title="The PCRpt Message" toc="default" anchor="SEC_RPT">
<t>As per Section 6.1 of <xref target='I-D.ietf-pce-stateful-pce'></xref>,
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.</t>
<t>The format of PCRpt message is as follows:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="" anchor="SEC_FIG3">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<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.
</artwork>
</figure>
<t>The END-POINTS object defined in <xref target="RFC6006"/> is mandatory
for specifying address of P2MP leaves.</t>
<t>Note that we preserve compatibility with the
<xref target='I-D.ietf-pce-stateful-pce'></xref> definition of <state-report>.
At least one instance of <END-POINTS> MUST be present in this message.</t>
<t>[Editor Note: suggest to add <END-POINTS> object mandatory in
<xref target='I-D.ietf-pce-stateful-pce'></xref> document for <state-report>].</t>
</section>
<section title="The PCUpd Message" toc="default" anchor="SEC_UPD">
<t>As per Section 6.2 of <xref target='I-D.ietf-pce-stateful-pce'></xref>, PCUpd
message is used to update P2P TE LSP attributes. This document extends the PCUpd
message in updating the attributes of P2MP TE LSP.</t>
<t>The format of a PCUpd message is as follows:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="" anchor="SEC_FIG4">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<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.
</artwork>
</figure>
<t>Note that we preserve compatibility with the
<xref target='I-D.ietf-pce-stateful-pce'></xref> definition of <update-request>. </t>
</section>
<section title="Example" toc="default">
<section title="P2MP TE LSP Update Request" toc="default">
<t>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:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
</artwork>
</figure>
<t>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.</t>
</section>
<section title="P2MP TE LSP Report" toc="default">
<t>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:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1
ERO list
</artwork>
</figure>
<t>An example of a
PCRpt message for P2MP TE LSP is described below to
prune leaves from an existing P2MP TE LSP:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 2
ERO list (empty)
</artwork>
</figure>
<t>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:</t>
<figure align="left" alt="" height="" suppress-title="true"
title="" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
</artwork>
</figure>
</section>
</section>
<section title="Report and Update Message Fragmentation" toc="default">
<t>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.</t>
<t>Fragmentation procedure described below for report or update message
is similar to <xref target="RFC6006"/> which describes request and response
message fragmentation.</t>
<section title="Report Fragmentation Procedure" toc="default">
<t>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.</t>
</section>
<section title="Update Fragmentation Procedure" toc="default">
<t>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.</t>
<t>[Editor Note: P2MP message fragmentation errors associated with a
P2MP path report and update will be defined in future version].</t>
</section>
</section>
</section>
<section title="Non-Support of P2MP TE LSPs for Stateful PCE" toc="default">
<t>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 <xref target="SEC_CA"/>. 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.</t>
<t>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.</t>
<t>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.</t>
<t>[Editor Note: more information on exact error value is needed]</t>
</section>
<section title="Security Considerations" toc="default">
<t>TBD</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>TBD.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>TBD.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>TBD.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>TBD.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>TBD.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>TBD.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>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.</t>
<section title="Extension of LSP Object" toc="default">
<t>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 <xref target="RFC5226"/>. Each bit should be tracked with the following
qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following values are defined in this document:</t>
<figure title="" suppress-title="true" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Description Reference
24 P2MP This.I-D
23 Fragmentation This.I-D
]]></artwork>
</figure>
</section>
<section title="Extension of PCEP-Error Object" toc="default">
<t>A new error types 6 and 19 defined in section 8.4 of
<xref target='I-D.ietf-pce-stateful-pce'></xref>. This document
extend the new Error-Values for those error types for the following
error conditions:</t>
<figure title="" suppress-title="true" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Error-Type Meaning
6 Mandatory Object missing
Error-value=12: P2MP-LSP-IDENTIFIER TLV missing
19 Invalid Operation
Error-value= TBD.
]]></artwork>
</figure>
</section>
<section title="PCEP TLV Type Indicators" toc="default">
<t>This document defines the following new PCEP TLVs:</t>
<figure title="" suppress-title="true" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value Meaning Reference
22 P2MP-IPV4-LSP-IDENTIFIERS This.I-D
23 P2MP-IPV6-LSP-IDENTIFIERS This.I-D
]]></artwork>
</figure>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>Thanks to Quintin Zhao for his comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.4857.xml" ?>
<?rfc include="reference.RFC.4875.xml" ?>
<?rfc include="reference.RFC.5226.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5671.xml" ?>
<?rfc include="reference.RFC.6006.xml" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce-app"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.sivabalan-pce-disco-stateful"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:27:51 |