One document matched: draft-zhao-pce-pcep-extension-for-pce-controller-03.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="exp"
docName="draft-zhao-pce-pcep-extension-for-pce-controller-03"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en">
<front>
<title abbrev="PCECC">PCEP Procedures and Protocol Extensions for
Using PCE as a Central Controller (PCECC) of LSPs</title>
<author initials="Q"
surname="Zhao"
fullname="Quintin Zhao">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>125 Nagog Technology Park</street>
<city>Acton</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>quintin.zhao@huawei.com</email>
</address>
</author>
<author initials="Z"
surname="Li"
fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing </city>
<region></region>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody"
initials="D"
surname="Dhody">
<organization abbrev="Huawei Technologies">Huawei
Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author initials="C"
surname="Zhou"
fullname="Chao Zhou">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>choa.zhou@cisco.com</email>
</address>
</author>
<date
year="2016" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>In certain networks deployment scenarios, service providers would
like to keep all the existing MPLS functionalities in both MPLS and
GMPLS while removing the complexity of existing signalling protocols
such as LDP and RSVP-TE. In
<xref target='I-D.zhao-pce-central-controller-user-cases'/>, we
propose to use
the PCE <xref target='RFC5440'/> as a central controller (PCECC) so that LSP can be calculated/
signalled/initiated and label forwarding entries are downloaded
through a centralized PCE server to each network devices along the
LSP path while leveraging the existing PCE technologies as much as
possible.</t>
<t>This draft specify the procedures and PCEP protocol extensions for
using the PCE as the central controller and user cases where LSPs are
calculated/setup/initiated and label forwarding entries are
downloaded through extending the existing PCE architectures and PCEP.
</t>
<t>This document also discuss the role of PCECC in Segment Routing (SR).</t>
</abstract>
</front>
<middle>
<section title="Introduction"
toc="default">
<t>In certain network deployment scenarios, service providers would like
to have the ability to dynamically adapt to a wide range of
customer's requests for the sake of flexible network service
delivery, Software Defined Networks(SDN) has provides additional
flexibility in how the network is operated compared to the
traditional network.</t>
<t>The existing networking ecosystem has become awfully complex and
highly demanding in terms of robustness, performance, scalability,
flexibility, agility, etc. By migrating to the SDN enabled network
from the existing network, service providers and network operators
must have a solution which they can evolve easily from the existing
network into the SDN enabled network while keeping the network
services remain scalable, guarantee robustness and availability etc.
</t>
<t>Taking the smooth transition between traditional network and the new
SDN enabled network into account, especially from a cost impact
assessment perspective, using the existing PCE components from the
current network to function as the central controller of the SDN
network is one choice, which not only achieves the goal of having a
centralized controller, but also leverage the existing PCE network
components.</t>
<t>The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform route
computations in response to Path Computation Clients (PCCs) requests.
PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
<xref target='I-D.ietf-pce-stateful-pce'/> describes a set of
extensions to PCEP to enable active control of MPLS-TE and GMPLS
tunnels.</t>
<t>
<xref target='I-D.ietf-pce-pce-initiated-lsp'/> describes the setup and
tear down of PCE-initiated LSPs under the active stateful PCE model,
without the need for local configuration on the PCC, thus allowing
for a dynamic MPLS network that is centrally controlled and deployed.
</t>
<t>
<xref target='I-D.ietf-pce-remote-initiated-gmpls-lsp'/> complements
<xref target='I-D.ietf-pce-pce-initiated-lsp'/> by addressing the
requirements for remote-initiated GMPLS LSPs.</t>
<t>Segment Routing (SR) technology leverage the source routing and
tunnelling paradigms. A source node can choose a path without relying
on hop-by-hop signalling protocols such as LDP or RSVP-TE. Each path
is specified as a set of "segments" advertised by link-state routing
protocols (IS-IS or OSPF).
<xref target='I-D.ietf-spring-segment-routing'/>
provides an introduction to SR technology. The corresponding IS-IS
and OSPF extensions are specified in
<xref target='I-D.ietf-isis-segment-routing-extensions'/>
and
<xref target='I-D.ietf-ospf-segment-routing-extensions'/>,
respectively.</t>
<t>A Segment Routed path (SR path) can be derived from an IGP Shortest
Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE
paths) may not follow IGP SPT. Such paths may be chosen by a
suitable network planning tool and provisioned on the source node of
the SR-TE path.</t>
<t>It is possible to use a stateful PCE for computing one or more SR-TE
paths taking into account various constraints and objective
functions. Once a path is chosen, the stateful PCE can instantiate
an SR-TE path on a PCC using PCEP extensions specified in
<xref target='I-D.ietf-pce-pce-initiated-lsp'/>
using the SR specific PCEP extensions
described in
<xref target='I-D.ietf-pce-segment-routing'/>.</t>
<t>PCECC may further use PCEP protocol for SR label distribution
instead of IGP extensions with some benefits.</t>
<t>Current MPLS label has local meaning. That is, MPLS label is always
allocated by the downstream node to the upstream node. Then the MPLS
label is only identified by the neighbouring upstream node and
downstream node. The label allocation is done locally and signalled
through the LDP/RSVP-TE/BGP protocol. To ease the label allocation
and signalling mechanism, PCE can be conveniently used as a central
controller with Label download capability. Further PCE can also be
used to manage the label range and Segment Routing Global Block (SRGB) etc.</t>
<t>The PCECC solution introduced in
<xref target='I-D.zhao-pce-central-controller-user-cases'/> allow for a
dynamic MPLS network that is eventually controlled and deployed
without the deployment of RSVP-TE protocol or extended IGP protocol
with node/adjacency segment identifiers signalling capability while
providing all the key MPLS functionalities needed by the service
providers.</t>
<t>This draft specify the procedures and PCEP protocol extensions for
using the PCE as the central controller and user cases where LSPs are
calculated/setup/initiated/downloaded through extending the existing
PCE architectures and PCEP.</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>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="IGP:">Interior Gateway Protocol. Either of the
two routing protocols, Open Shortest Path First (OSPF) or
Intermediate System to Intermediate System (IS-IS).</t>
<t hangText="PCC:">Path Computation Client: any client application
requesting a path computation to be performed by a Path
Computation Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component,
application, or network node) that is capable of computing a
network path or route based on a network graph and applying
computational constraints.</t>
<t hangText="TE:">Traffic Engineering.</t>
</list>
</t>
</section>
<section title="PCECC Modes"
toc="default"
anchor="SEC_M">
<t>The following PCECC modes are supported -
<list style="symbols">
<t>Basic PCECC.</t>
<t>PCECC SR.
<list style="symbols">
<t>PCECC SR-BE (Best Effort).</t>
<t>PCECC SR-TE (Traffic Engineered).</t>
</list>
</t>
</list>
</t>
<t>In basic PCECC mode, the forwarding is similar to RSVP-TE
signalled LSP without the RSVP-TE signalling. The PCECC allocates
and download the label entries along the LSP. The rest of processing
is similar to the existing stateful PCE mechanism.</t>
<t>In case of SR, there are two modes for SR-BE and SR-TE. For SR-BE,
the forwarding is similar to LDP LSP without LDP signalling or
IGP-SR extension. The SR Node label are allocated and distributed
in the domain centrally by the PCE via PCEP. Each node (PCC) relies
on local IGP for the nexthop calculation. For SR-TE, the forwarding
uses label stack similar to IGP based SR-TE without IGP-SR extension.
The SR node and adjacency labels are allocated and distributed in the
domain centrally by the PCE via PCEP by PCECC. Rest of the processing
is similar to existing stateful PCE with SR mechanism.</t>
</section>
<section title="PCEP Requirements"
toc="default"
anchor="SEC_R">
<t>Following key requirements associated PCECC should be considered when
designing the PCECC based solution:</t>
<t>
<list style="numbers">
<t>PCEP speaker supporting this draft MUST have the capability to
advertise its PCECC capability to its peers.</t>
<t>PCEP speaker not supporting this draft MUST be able to reject
PCECC related message with a reason code that indicates no support for PCECC.</t>
<t>PCEP SHOULD provide a means to identify PCECC based LSP in the PCEP messages.</t>
<t>PCEP SHOULD provide a means to update (or cleanup) the label-download or label-map entry to the PCC.</t>
<t>Path Computation Client (PCC) supporting this draft MAY support
a capability to communicate local label range or global label range
or both to PCE. (see xref target="sec_lr"/>)</t>
<t>Path Computation Element (PCE) supporting this draft MAY have
the capability to negotiate a global label range for a group of
clients and communicate the final global label range to PCC. (see xref target="sec_lr"/>)</t>
</list>
</t>
</section>
<section title="Procedures for Using the PCE as the Central Controller (PCECC)"
toc="default">
<section title="Stateful PCE Model"
toc="default">
<t>Active stateful PCE is described in <xref target='I-D.ietf-pce-stateful-pce'/>. PCE
as a central controller (PCECC) reuses existing Active stateful PCE
mechanism as much as possible to control the LSP.</t>
</section>
<section title="New LSP Functions"
toc="default">
<t>This document defines the following new PCEP messages and extends the
existing messages to support PCECC:</t>
<t>
<list style="hanging">
<t hangText="(PCRpt):">a PCEP message described in <xref target='I-D.ietf-pce-stateful-pce'/>.
PCRpt message MAYBE used to send PCECC LSP Reports.</t>
<t hangText="(PCInitiate):">a PCEP message described in <xref target='I-D.ietf-pce-pce-initiated-lsp'/>.
PCInitiate message is used to setup PCE-Initiated LSP based on PCECC mechanism. </t>
<t hangText="(PCUpd):">a PCEP message described in <xref target='I-D.ietf-pce-stateful-pce'/>.
PCUpd message is used to send PCECC LSP Update.</t>
<t hangText="Per Node Label Operations:">a PCEP mechanism to instruct label operations on each node.
An approach to this could be -
<list style="hanging">
<t hangText="(PCLabelUpd):">a new PCEP message sent by a PCE to a PCC
to download or cleanup the Label entry. The PCLabelUpd
message described in <xref target="SEC_PCLabelUpd"/>.</t>
<t hangText="(PCInitiate):">reuse an existing PCEP message described in <xref target='I-D.ietf-pce-pce-initiated-lsp'/>.
PCInitiate message.</t>
</list>
</t>
</list>
</t>
<t>The new LSP functions defined in this document are mapped onto the messages as
shown in the following table.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG1">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+----------------------------------------+--------------------------+
| Function | Message |
+----------------------------------------+--------------------------+
| PCECC Capability advertisement | Open |
| Label entry Update | PCLabelUpd/PCInitiate |
| Label entry Cleanup | PCLabelUpd/PCInitiate |
| PCECC Initiated LSP | PCInitiate |
| PCECC LSP Update | PCUpd |
| PCECC LSP State Report | PCRpt |
| PCECC LSP Delegation | PCRpt |
+----------------------------------------+--------------------------+
]]>
</artwork>
</figure>
</section>
<section title="PCECC Capability Advertisement"
toc="default">
<t>During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of PCECC extensions. A PCEP Speaker includes
the "PCECC Capability" TLV, described in <xref target="SEC_PCECC_CAP_TLV"/> of this
document, in the OPEN Object to advertise its support for PCECC extensions.</t>
<t>The presence of the PCECC Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to function as a PCECC client.</t>
<t>The presence of the PCECC Capability TLV in PCE's OPEN message
indicates that the PCE is interested in function as a PCECC server.</t>
<t>The PCEP protocol extensions for PCECC MUST NOT be used if one or
both PCEP Speakers have not included the PCECC Capability TLV in their
respective OPEN message. If the PCEP Speakers support the extensions
of this draft but did not advertise this capability then a PCErr message with
Error-Type=19(Invalid Operation) and Error-Value=[TBD] (Attempted
LSP setup/download/label-range reservation if PCECC capability was not
advertised) will be generated and the PCEP session will be terminated.</t>
<t>A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and
STATEFUL-PCE-CAPABILITY TLV (<xref target='I-D.ietf-pce-stateful-pce'/>) in OPEN Object to support the extensions defined
in this document. If PCECC-CAPABILITY TLV is advertised and STATEFUL-PCE-CAPABILITY TLV
is not advertised in OPEN Object, it SHOULD send a PCErr message with Error-Type=19
(Invalid Operation) and Error-value=[TBD](stateful PCE capability was not advertised)
and terminate the session.</t>
<t>PCECC-CAPABILITY TLV includes a S-bit to indicate support for PCECC-SR. A PCEP speaker MUST set S-bit in PCECC-CAPABILITY TLV and
include SR-PCE-CAPABILITY TLV (<xref target='I-D.ietf-pce-segment-routing'/>) in OPEN Object to support the PCECC SR-TE extensions defined
in this document. If S-bit is set in PCECC-CAPABILITY TLV and SR-PCE-CAPABILITY TLV
is not advertised in OPEN Object, PCEP speaker SHOULD send a PCErr message with Error-Type=19
(Invalid Operation) and Error-value=[TBD](SR capability was not advertised)
and terminate the session.</t>
</section>
<section title="PCEP session IP address and TEDB Router ID"
toc="default" anchor="sec_ses">
<t>PCE may construct its TEDB by participating in the
IGP (<xref target="RFC3630"/> and <xref target="RFC5305"/> for MPLS-TE; <xref target="RFC4203"/> and <xref target="RFC5307"/>
for GMPLS). An alternative is offered by BGP-LS <xref target="I-D.ietf-idr-ls-distribution"/> and <xref target="I-D.dhodylee-pce-pcep-ls"/>.</t>
<t>PCEP <xref target="RFC5440"/> speaker MAY use any IP address while creating a TCP session. It is important to link the session IP address with the
Router ID in TEDB for successful PCECC operations.</t>
<t>During PCEP Initialization Phase, PCC
SHOULD advertise the TE mapping information. Thus a PCC includes
the "Node Attributes TLV" <xref target="I-D.dhodylee-pce-pcep-ls"/> with
"IPv4/IPv6 Router-ID of Local Node",
in the OPEN Object for this purpose. <xref target="I-D.ietf-idr-ls-distribution"/>
describes the usage as auxiliary Router-IDs that the IGP might be using, e.g., for TE
purposes. If
there are more than one auxiliary Router-ID of a given type, then
multiple TLVs are used to encode them.</t>
<t>If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP address is directly used for the mapping purpose.</t>
</section>
<section title="LSP Operations"
toc="default">
<t> The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE
TLV <xref target='I-D.ietf-pce-lsp-setup-type'/> in the SRP object
to clearly identify the PCECC LSP is intended.</t>
<section title="Basic PCECC Mode"
toc="default"
anchor="SEC_BASIC">
<section title="PCECC LSP Setup"
toc="default"
anchor="SEC_BASIC_SETUP">
<t>In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate the LSP by
sending a PCRpt message with Path Setup Type set for basic PCECC (see <xref target="SEC_PATH"/>) and D (Delegate)
flag (see <xref target='I-D.ietf-pce-stateful-pce'/>) set in the LSP object.</t>
<t>LSP-IDENTIFIER TLV MAY be included for PCECC LSP, the LSP-ID SHOULD be generated by
the PCE for PCECC LSP. In the first PCRpt message of PCECC LSP, LSP ID of LSP-IDENTIFIER
TLV is set to zero.</t>
<t>When a PCE receives PCRpt message with P and D flags set, it MAY generates
LSP ID; calculates the path and assigns labels along the path; and setups
the path by sending PCLabelUpd or PCInitiate message to each node
along the path of the LSP.</t>
<t>In response to the delegate PCRpt message, the PCE SHOULD send the PCUpd message with the same PLSP-ID to the
Ingress PCC.</t>
<t>The PCECC LSPs MUST be delegated to a PCE at all times.
</t>
<t>LSP deletion operation for PCECC LSP
is same as defined in <xref target='I-D.ietf-pce-stateful-pce'/>. If the PCE receives
PCRpt message for LSP deletion then it does Label cleanup operation as
described in <xref target="SEC_CLEANUP"/> for the corresponding LSP.</t>
<t>The Basic PCECC LSP setup sequence is as shown below using a new
message PCLabelUpd.</t>
<figure align="left"
alt=""
height=""
suppress-title="false"
title="Using PCLabelUpd For Label Operations"
width=""
anchor="SEC_FIG3">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP
|PCC +--------+ | (LSP ID=0) |(LSPID=1)
|Egress | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd,PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1) | download
| | | |
| |<----- PCLabelUpd,PLSP-ID=1 ----------- | Label
| | | (LSP ID=1) | download
| | | |
| | |<--- PCLabelUpd,PLSP-ID=1 ------- | Label
| | | (LSP ID=1) | download
| | | |
| | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP
| | | (LSP ID=1) | Update
| | | |
]]>
</artwork>
</figure>
<figure align="left"
alt=""
height=""
suppress-title="false"
title="Using PCInitiate For Label Operations"
width=""
anchor="SEC_FIG3_1">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP
|PCC +--------+ | (LSP ID=0) |(LSPID=1)
|Egress | | | |
+--------+ | | |
| | | |
|<------ PCInitiate,PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1) | download
|------- PCRpt ---------------------------------->|
| | | |
| |<----- PCInitiate,PLSP-ID=1 ----------- | Label
| | | (LSP ID=1) | download
| |----- -PCRpt---------------------------->|
| | | |
| | |<--- PCInitiate,PLSP-ID=1 ------- | Label
| | | (LSP ID=1) | download
| | |-----PCRpt------------------------>|
| | | |
| | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP
| | | (LSP ID=1) | Update
| | | |
Some open issue -
* PCC send PCRpt messages for each PCInitiate message?
* Should one use PCInitiate at Ingress too? How to link this
with existing tunnel at the PCC?
]]>
</artwork>
</figure>
<t>The PCECC LSP are considered to be 'up' by default.
The Ingress MAY further choose to deploy a data plane check
mechanism and report the status back to the PCE via PCRpt message.</t>
</section>
<section title="Label Operations"
toc="default">
<section title="Via a new PCLabelUpd Message"
toc="default">
<t>The new label operations in PCEP can be done via a new message and by
defining new PCEP Objects for Label operations and FEC. </t>
<section title="Label Download"
toc="default">
<t>In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd message
to each node of the LSP to download the Label entry as described in <xref target="SEC_BASIC_SETUP"/>.</t>
<t>The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV.</t>
<t>If a node (PCC) receives a PCLabelUpd message but failed to download the Label entry,
it MUST send a PCErr message with Error-type=[TBD] (label download failed)
and Error-value=[TBD].</t>
<t>Two new PCEP objects for LABEL and FEC are defined in
<xref target='SEC_LABEL'/> and <xref target='SEC_FEC'/> to
encode the Label operations and its associated FEC.</t>
</section>
<section title="Label Cleanup"
toc="default"
anchor="SEC_CLEANUP">
<t>In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd
message to each node along the path of the LSP to cleanup the Label entry.</t>
<t>If the PCC receives a PCLabelUpd message but does not recognize the label,
the PCC MUST generate a PCErr
message with Error-Type 19(Invalid operation) and Error-Value=3, "Unknown Label".
</t>
<t>The R flag in SRP object defined in <xref target='I-D.ietf-pce-pce-initiated-lsp'/> specifies
the deletion of Label Entry in the new PCLabelUpd message.</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">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| PCECC LSP
|PCC +--------+ | (LSP ID=1) | remove
|Egress | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
]]>
</artwork>
</figure>
</section>
</section>
<section title="Via an existing PCInitiate Message"
toc="default">
<t>The new label operations in PCEP can be done via existing PCInitiate
message and by reusing PCEP Objects (and subobjects) to encode
Label operations and FEC. A TE LSP can be envisioned as a series of
"cross-connects" and ERO in the PCInitiate message can be used to
indicate each such cross-connect along the path. The use of PCInitiate
message would also require each node to send the PCRpt message. The handling
of PLSP-ID, LSP Identifiers, Symbolic path name would need to be taken
into consideration.</t>
<t>The PATH-SETUP-TYPE TLV <xref target='I-D.ietf-pce-lsp-setup-type'/> in the SRP object
can identify the PCECC LSP.</t>
<section title="Label Download"
toc="default">
<t>In order to setup an LSP based on PCECC, the PCE sends a PCInitiate message
to each node of the LSP to download the Label entry as described in <xref target="SEC_BASIC_SETUP"/>
represented as a "cross-connect".</t>
<t>If a node (PCC) receives a PCInitiate message with setup type indicated as PCECC, it should
not try to initiate a complete tunnel. The error-handling and other processing
would remain unchanged.</t>
<t>The ERO in the PCInitiate message would indicate the cross-connect as
{input interface, input label, output interface, output label}. For
Egress only input interface/label would be present and for Ingress
only output interface/label. For Ingress either PCInitiate is used
or the same information can be put in PCUpd message as well.</t>
</section>
<section title="Label Cleanup"
toc="default">
<t>In order to delete an LSP based on PCECC, one can use existing PCInitiate
message (with R flag) to each node along the path of the LSP to cleanup the Label entry.
The R flag in SRP object defined in <xref target='I-D.ietf-pce-pce-initiated-lsp'/> is
used during cleanup.</t>
<t>The error-handling and other processing
would remain unchanged.</t>
</section>
</section>
</section>
</section>
<section title="PCE Initiated PCECC LSP"
toc="default">
<t>The LSP Instantiation operation is same as defined in <xref target='I-D.ietf-pce-pce-initiated-lsp'/>.</t>
<t>In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE
sends PCInitiate message with Path Setup Type set for basic PCECC
(see <xref target="SEC_PATH"/>) to the Ingress PCC.</t>
<t>The Ingress PCC MUST also set D (Delegate) flag (see
<xref target='I-D.ietf-pce-stateful-pce'/>) and C (Create) flag
(see <xref target='I-D.ietf-pce-pce-initiated-lsp'/>) in LSP object of
PCRpt message. The PCC responds with first PCRpt message with the status as "GOING-UP" and assigned PLSP-ID.</t>
<t>The rest of the PCECC LSP setup operations are same as those described in <xref target="SEC_BASIC_SETUP"/>.</t>
<t>The LSP deletion operation for PCE Initiated PCECC LSP is same as defined
in <xref target='I-D.ietf-pce-pce-initiated-lsp'/>. The PCE should further
perform Label entry cleanup operation as described in
<xref target="SEC_CLEANUP"/> for the corresponding LSP.</t>
<t>The PCE Initiated PCECC LSP setup sequence is shown below using
a new PCLabelUpd message.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG5">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP
|PCC +--------+ | | Initiate
|Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP
+--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2
| | | | assigned)
|<------ PCLabelUpd, PLSP-ID=2 ------------------ | Label
| | | (LSP ID=2) | download
| | | |
| |<----- PCLabelUpd, PLSP-ID=2 ----------- | Label
| | | (LSP ID=2) | download
| | | |
| | |<--- PCLabelUpd, PLSP-ID=2 ------- | Label
| | | (LSP ID=2) | download
| | | |
| | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP
| | | (LSP ID=2) | Update
| | | |
]]>
</artwork>
</figure>
<t>The PCE Initiated PCECC LSP setup sequence is shown below using
existing PCInitiate message.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG5_a">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP
|PCC +--------+ | | Initiate
|Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP
+--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2
| | | | assigned)
|<------ PCInitiate, PLSP-ID=2 ------------------ | Label
| | | (LSP ID=2) | download
|------- PCRpt ---------------------------------->|
| | | |
| |<----- PCInitiate, PLSP-ID=2 ----------- | Label
| | | (LSP ID=2) | download
| |----- -PCRpt---------------------------->|
| | | |
| | |<--- PCInitiate, PLSP-ID=2 ------- | Label
| | | (LSP ID=2) | download
| | |-----PCRpt------------------------>|
| | | |
| | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP
| | | (LSP ID=2) | Update
| | | |
Some open issue -
* PCC send PCRpt messages for each PCInitiate message?
* How to link 2 PCInitiate message at Ingress one to initiate the
full tunnel, and one to download the cross-connect (label)?
]]>
</artwork>
</figure>
</section>
<section title="PCECC LSP Update"
toc="default">
<t>Incase of a modification of PCECC LSP with a new path, a PCE sends
a PCUpd message to the
Ingress PCC.</t>
<t>When a PCC receives a PCUpd message for an existing LSP, a PCC MAY
follow the make-before-break procedure i.e. first download labels for the
updated LSP and then switch traffic, before cleaning up the old labels. On successful traffic switch over to the
new LSP, PCC sends a PCRpt message to the PCE for the deletion of old LSP.
Further the PCE does cleanup operation for the old LSP as described in <xref target="SEC_CLEANUP"/>.</t>
<t>The PCECC LSP Update and make-before-break sequence is shown below
using a new PCLabelUpd message.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG6">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | | |
|PCC +--------+ | |
|Egress | | | |
+--------+ | | |
| | | | Modify LSP
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | (LSPID=3
| | | (LSP ID=3) | assigned)
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=3) | download
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=3) | download
| | | |
| | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC
| | | (LSP ID=3) | LSP Update
| | | |
| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete
| | | (LSP ID=1) | old LSP
| | | |
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=1, R=1) | cleanup
]]>
</artwork>
</figure>
<t>The PCECC LSP Update and make-before-break sequence is shown below
using existing PCInitiate message.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG6_a">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | | |
|PCC +--------+ | |
|Egress | | | |
+--------+ | | |
| | | | Modify LSP
|<------ PCInitiate, PLSP-ID=1 ------------------ | (LSPID=3
| | | (LSP ID=3) | assigned)
|------- PCRpt ---------------------------------->|
| | | |
| |<----- PCInitiate, PLSP-ID=1 ----------- | Label
| | | (LSP ID=3) | download
| |----- -PCRpt---------------------------->|
| | | |
| | |<--- PCInitiate, PLSP-ID=1 ------- | Label
| | | (LSP ID=3) | download
| | |-----PCRpt------------------------>|
| | | |
| | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC
| | | (LSP ID=3) | LSP Update
| | | |
| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete
| | | (LSP ID=1) | old LSP
| | | |
|<------ PCInitiate, PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1, R=1) | cleanup
|------- PCRpt ---------------------------------->|
| | | |
| |<----- PCInitiate, PLSP-ID=1 ----------- | Label
| | | (LSP ID=1, R=1) | cleanup
| |----- -PCRpt---------------------------->|
| | | |
| | |<--- PCInitiate, PLSP-ID=1 ------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | |-----PCRpt------------------------>|
]]>
</artwork>
</figure>
<t>The modified PCECC LSP are considered to be 'up' by default.
The Ingress MAY further choose to deploy a data plane check
mechanism and report the status back to the PCE via PCRpt message.</t>
</section>
<section title="PCECC LSP State Report"
toc="default">
<t>As mentioned before, an Ingress PCC MAY choose to apply any OAM mechanism to check the status
of LSP in the Data plane and MAY further send its status in PCRpt message to the PCE.</t>
</section>
<section title="PCECC Segment Routing (SR)"
toc="default">
<t>Segment Routing (SR) as described in
<xref target='I-D.ietf-spring-segment-routing'/> depends
on "segments" that are advertised by Interior Gateway
Protocols (IGPs). The SR-node allocates and
advertises the SID (node, adj etc) and flood via the IGP.
This document proposes a new mechanism where
PCE allocates the SID (label) centrally and uses PCEP to
advertise the SID. In some deployments PCE (and PCEP) are
better suited than IGP because of centralized nature of
PCE and direct TCP based PCEP session to the node.</t>
<t>PCECC SR capability (S-bit) MUST be advertised in
Open message.</t>
<t>[EDITOR NOTE: Currently only the use of a new message
PCLabelUpd is discussed in this section, the editors feel
that use of existing PCInitiate message for SR node and
adjacency label would be problematic.]</t>
<section title="PCECC SR-BE"
toc="default">
<t>Each node (PCC) is allocated a node-SID (label) by the PCECC.
The PCECC sends PCLabelUpd to update the label map of each node to
all the nodes in the domain. The TE router ID is determined from the TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV <xref target="I-D.dhodylee-pce-pcep-ls"/>,
in the OPEN Object <xref target="sec_ses"/>. </t>
<t>It is RECOMMENDED that PCEP session with PCECC SR capability to use a
different session IP address during TCP session establishment than the
node Router ID in TEDB, to make sure that the PCEP session does not get
impacted by the SR-BE node label maps (<xref target="sec_ses"/>).</t>
<t>On receiving the label map, each node (PCC) uses the local information
to determine the next-hop and download the label forwarding instructions
accordingly. The PCLabelUpd message in this case MUST NOT have LSP object
but use the new FEC object.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIGA">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|3.3.3.3| +-------+
+------| | |
| PCC +-------+ |
| 2.2.2.2| | |
+------| | | |
|PCC +--------+ | |
|1.1.1.1 | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, FEC=1.1.1.1----------------- | Label Map
| | | Label=X | update
|Find | | |
|Nexthop|<----- PCLabelUpd, FEC=1.1.1.1---------- | Label Map
|locally| | Label=X | update
| | | |
| | |<--- PCLabelUpd, FEC=1.1.1.1------ | Label Map
| | | Label=X | update
| | | |
]]>
</artwork>
</figure>
<t>The forwarding behaviour and the end result is similar to IGP based
"Node-SID" in SR. Thus, from anywhere in the domain, it enforces
the ECMP-aware shortest-path forwarding of the packet towards the
related node.</t>
<t>PCE relies on the Node label cleanup using the same PCLabelUpd message.</t>
</section>
<section title="PCECC SR-TE"
toc="default">
<t>A Segment Routed Best Effort path (SR-BE path) can be derived
from an IGP Shortest Path Tree (SPT) as explained above. On the other
hand, SR-TE paths may not follow IGP SPT. Such paths may
be chosen by a PCE and provisioned on the source node of the SR-TE path.</t>
<t><xref target='I-D.ietf-pce-segment-routing'/> extends PCEP to allow
a stateful PCE to
compute and initiate SR-TE paths, as well as a PCC
to request a path subject to certain constraint(s) and optimization
criteria in SR networks.</t>
<t>For SR-TE, apart from node-SID, Adj-SID is used where each adjacency is
allocated an Adj-SID (label) by the PCECC. The PCECC sends
PCLabelUpd to update the label map of each Adj to the corresponding
nodes in the domain. Each node (PCC) download the label forwarding
instructions accordingly. Similar to SR-BE, the PCLabelUpd message
in this case MUST NOT have LSP object but use the new FEC object.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIGB">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-------+ +-------+
|PCC | | PCE |
|3.3.3.3| +-------+
+------| | |
| PCC +-------+ |
| 2.2.2.2| | |
+------| | | |
|PCC +--------+ | |
|1.1.1.1 | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, FEC=10.1.1.1 / ------------- | Label Map
| | | 10.1.1.2 | update
| | | Label=A |
| | | |
| |<----- PCLabelUpd, FEC=10.1.1.2--------- | Label Map
| | | 10.1.1.1 | update
| | | Label=B |
| | | |
]]>
</artwork>
</figure>
<t>The forwarding behavior and the end result is similar to IGP based
"Adj-SID" in SR.</t>
<t>The Path Setup Type for segment routing MUST be set for PCECC SR-TE (see <xref target="SEC_PATH"/>).
All PCEP procedures and mechanism are similar to
<xref target='I-D.ietf-pce-segment-routing'/>.</t>
<t>PCE relies on the Adj label cleanup using the same PCLabelUpd message.</t>
</section>
</section>
</section>
</section>
<section title="PCEP messages"
toc="default">
<t>As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to
be considered valid. For each PCEP message type, a set of rules is
defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object
ordering specified in this document.</t>
<t>LSP-IDENTIFIERS TLV MAY be included in the LSP object for PCECC
LSP.</t>
<section title="Label Operations"
toc="default"
anchor="SEC_LabelOp">
<section title="The PCLabelUpd message"
toc="default"
anchor="SEC_PCLabelUpd">
<t>A new Label Update Message (also referred to as PCLabelUpd) is a
PCEP message sent by a PCE to a PCC to download label or update the
label map. The same message is also used to cleanup the Label entry.
The Message-Type field of the PCEP common header for the PCLabelUpd message
is set to [TBD].</t>
<t>The format of the PCLabelUpd message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG8">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
<PCLabelUpd Message> ::= <Common Header>
<pce-label-update-list>
Where:
<pce-label-update-list> ::= <pce-label-update>
[<pce-label-update-list>]
<pce-label-update> ::= (<pce-label-download>|<pce-label-map>)
Where:
<pce-label-download> ::= <SRP>
<LSP>
<label-list>
<pce-label-map> ::= <SRP>
<LABEL>
<FEC>
<label-list > ::= <LABEL>
[<label-list>]
]]>
</artwork>
</figure>
<t>The PCLabelUpd message is used to download label along the path
of the LSP for the basic PCECC mode, as well as to update the label
map for the Node and Adjacency Label in case of SR.</t>
<t>The SRP object is defined in <xref target='I-D.ietf-pce-stateful-pce'/> and this
document extends the use of SRP object in PCLabelUpd message.
The SRP object is mandatory and MUST be included in PCLabelUpd
message. If the SRP object is missing, the receiving PCC MUST send
a PCErr message with Error-type=6 (Mandatory Object missing) and
Error-value=10 (SRP object missing).</t>
<t>The LSP object is defined in <xref target='I-D.ietf-pce-stateful-pce'/> and this
document extends the use of LSP object in PCLabelUpd message.
The LSP is an optional object and used in the basic PCECC mode in PCLabelUpd message.
LSP Identifiers TLV is defined in <xref target='I-D.ietf-pce-stateful-pce'/>,
it MAY be included in the LSP object in PCLabelUpd message.
</t>
<t>The LABEL object is defined in <xref target="SEC_LABEL"/>. The LABEL is the mandatory object
and MUST be included in PCLabelUpd message. If the LABEL object is
missing, the receiving PCC MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=[TBD] (LABEL object missing).
More than one LABEL object MAY be included in the PCLabelUpd message
for the transit LSR.</t>
<t>The FEC object is defined in <xref target="SEC_FEC"/>. The FEC is an
optional object and used in PCECC SR mode in PCLabelUpd message. The FEC
object encodes the Node and Adjacency information of the Label Map.</t>
<t>To cleanup the SRP object must set the R (remove) bit.</t>
</section>
<section title="The PCInitiate message"
toc="default"
anchor="SEC_PCInitiate">
<t>Message described in <xref target='I-D.ietf-pce-pce-initiated-lsp'/>
continue to apply.</t>
</section>
</section>
</section>
<section title="PCEP Objects"
toc="default">
<t>The PCEP objects defined in this document are compliant with the PCEP object
format defined in [RFC5440]. The P flag and the I flag of the PCEP objects
defined in this document MUST always be set to 0 on transmission and MUST
be ignored on receipt since these flags are exclusively related to
path computation requests.</t>
<section title="OPEN Object"
toc="default">
<t>This document defines a new optional TLVs for use in the OPEN Object.</t>
<section title="PCECC Capability TLV"
toc="default"
anchor="SEC_PCECC_CAP_TLV">
<t>The PCECC-CAPABILITY TLV is an optional TLV for use in the OPEN Object
for PCECC capability advertisement. Advertisement of the PCECC capability
implies support of LSPs that are setup through PCECC as per PCEP extensions
defined in this document.</t>
<t>Its format is shown in the following figure:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG9">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
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=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The type of the TLV is [TBD] and it has a fixed length of 4 octets.</t>
<t>The value comprises a single field - Flags (32 bits):</t>
<t>
<list style="hanging">
<t hangText="S (PCECC-SR-CAPABILITY - 1 bit):">If set to 1 by
a PCEP speaker, it indicates that the PCEP speaker is capable for PCECC-SR capability and
PCE would allocate node and Adj label on this session.</t>
</list>
</t>
<t>Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.</t>
</section>
</section>
<section title="PATH-SETUP-TYPE TLV"
toc="default"
anchor="SEC_PATH">
<t>The PATH-SETUP-TYPE TLV is defined in <xref target='I-D.ietf-pce-lsp-setup-type'/>;
this document defines a new PST value:
<list style="symbols">
<t>PST = 2: Path is setup via Basic PCECC mode.</t>
</list></t>
<t>PST = 1 (defined in <xref target='I-D.ietf-pce-segment-routing'/>) can be reused when Path is setup via PCECC SR-TE mode.</t>
<t>On a PCRpt/PCUpd/PCInitiate message,
the PST=2 in PATH-SETUP-TYPE TLV in SRP object indicates that
this LSP was setup via a basic PCECC
based mechanism; the PST=1 indicates that
this LSP was setup via a SR-TE
based mechanism where either the labels are allocated by PCE
via PCECC mechanism or advertised by IGP.</t>
</section>
<section title="Label Object"
toc="default"
anchor="SEC_LABEL">
<t>The LABEL Object is used to specify the Label information and
MUST be carried within PCLabelUpd message.</t>
<t>LABEL Object-Class is TBD.</t>
<t>LABEL Object-Type is 1.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG12">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The fields in the LABEL object are as follows:
<list style="hanging">
<t hangText="Flags:"> is used to carry any additional information
pertaining to the label. Currently, the following flag bit is
defined: <list style="symbols">
<t>O bit(Out-label) : If the bit is set, it specifies the label is
the OUT label and it is mandatory to encode the nexthop
information (via IPV4-ADDRESS TLV or
IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID-ADDRESS TLV in
LABEL object). If the bit is not set, it specifies the label is
the IN label and it is optional to encode the local interface
information (via IPV4-ADDRESS TLV or
IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID-ADDRESS TLV in
LABEL object).</t> </list></t>
<t hangText="Label (20-bit):">The Label information encoded such
that the 20 rightmost bits represent a label.</t>
<t hangText="Reserved (12 bit):">Set to zero while sending, ignored on receive.</t>
</list></t>
<section title="Address TLVs"
toc="default">
<t>This document defines the following TLV for the LABEL object to
associate the nexthop information incase of an outgoing label and
local interface information incase of an incoming label.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIGC">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
IPV4-ADDRESS TLV:
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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPV6-ADDRESS TLV:
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 = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UNNUMBERED-IPV4-ID-ADDRESS TLV:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The address TLVs are as follows:
<list style="hanging">
<t hangText="IPV4-ADDRESS TLV:">an IPv4 address.</t>
<t hangText="IPV6-ADDRESS TLV:">an IPv6 address.</t>
<t hangText="UNNUMBERED-IPV4-ID-ADDRESS TLV:">a pair of Node ID / Interface ID tuples.</t>
</list>
</t>
</section>
</section>
<section title="FEC Object"
toc="default"
anchor="SEC_FEC">
<t>The FEC Object is used to specify the FEC information and
MAY be carried within PCLabelUpd message.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIGD">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
FEC Object-Class is TBD.
FEC Object-Type is 1 'IPv4 Node ID'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 2 'IPv6 Node ID'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv6 Node ID (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 3 'IPv4 Adjacency'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 4 'IPv6 Adjacency'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Local IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Remote IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The FEC objects are as follows:
<list style="hanging">
<t hangText="IPv4 Node ID:"> where IPv4 Node ID is specified as an IPv4 address of the Node. FEC Object-type
is 1, and the Object-Length is 4 in this case.</t>
<t hangText="IPv6 Node ID:"> where IPv6 Node ID is specified as an IPv6 address of the Node. FEC Object-type
is 2, and the Object-Length is 16 in this case.</t>
<t hangText="IPv4 Adjacency:"> where Local and Remote IPv4 address is specified as pair of IPv4 address of the adjacency. FEC Object-type
is 3, and the Object-Length is 8 in this case.</t>
<t hangText="IPv6 Adjacency:"> where Local and Remote IPv6 address is specified as pair of IPv6 address of the adjacency. FEC Object-type
is 4, and the Object-Length is 32 in this case.</t>
<t hangText="Unnumbered Adjacency with IPv4 NodeID:"> where a pair of Node ID / Interface ID tuples is used. FEC Object-type
is 5, and the Object-Length is 16 in this case.</t>
</list> </t>
</section>
</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>TBD</t>
</section>
<section title="Acknowledgments"
toc="default">
<t>We would like to thank Robert Tao, Changjing Yan, Tieying Huang and Avantika for
their useful comments and suggestions.</t>
<t>We would like to thank Adrian Farrel for presenting followup of PCECC proposal in IETF 94. </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.dhodylee-pce-pcep-ls"?>
<?rfc include="reference.I-D.ietf-idr-ls-distribution"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3630.xml" ?>
<?rfc include="reference.RFC.4203.xml" ?>
<?rfc include="reference.RFC.5305.xml" ?>
<?rfc include="reference.RFC.5307.xml" ?>
<?rfc include="reference.I-D.li-mpls-global-label-framework"?>
<?rfc include="reference.I-D.zhao-pce-central-controller-user-cases"?>
<?rfc include="reference.I-D.ietf-pce-remote-initiated-gmpls-lsp"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing"?>
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>
<?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions"?>
<?rfc include="reference.I-D.ietf-pce-segment-routing"?>
<?rfc include="reference.I-D.ietf-pce-lsp-setup-type"?>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasree.palle@huawei.com
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: katherine.zhao@huawei.com
Boris Zhang
Telus Ltd.
Toronto
Canada
EMail: boris.zhang@telus.com
]]></artwork>
</figure>
</t>
</section>
<section title="Label Range Handling" toc="default" anchor="sec_lr">
<t>This section is created to move the Label range handling text. It would be moved to a separate
document in future.</t>
<t>New requirements for PCEP extension regarding Label Range:- </t>
<t>
<list style="symbols">
<t>Path Computation Client (PCC) supporting this draft MAY support
a capability to communicate local label range or global label range
or both to PCE.</t>
<t>Path Computation Element (PCE) supporting this draft MAY have
the capability to negotiate a global label range for a group of
clients and communicate the final global label range to PCC.</t>
</list>
</t>
<t>Two new flags are added in PCECC-CAPABILITY TLV (<xref target="SEC_PCECC_CAP_TLV"/>) to support PCECC:- </t>
<t>
<list style="hanging">
<t hangText="L (LOCAL-LABEL-RANGE-CAPABILITY - 1 bit):">If set to 1 by
a PCEP speaker, it indicates that the PCEP speaker is capable for local
label range reservation.</t>
<t hangText="G (GLOBAL-LABEL-RANGE-CAPABILITY - 1 bit):">If set to 1 by
a PCEP speaker, it indicates that the PCEP speaker capable for global
label range reservation.</t>
</list>
</t>
<t>A new PCEP messages to support PCECC:-</t>
<t>
<list style="hanging">
<t hangText="(PCLRResv):">a PCEP message sent by a PCC to a PCE to
ask for the label range reservation or a PCE to a PCC to send the
reserved label range. The PCLRResv message described in <xref target="SEC_PCLRESV"/>.</t>
</list>
</t>
<section title="Label Range Reservation"
toc="default">
<t>After PCEP initial state synchronization, the label range is reserved.</t>
<t>If L flag is advertised in OPEN Object by PCEP speakers, a PCC reserves a local
label range and is communicated using PCLRResv message to a PCE. The PCE maintains
the local label range of each node and further during LSP setup, a label is assigned
to each node from the corresponding local label range reserved.</t>
<t>If G flag is advertised in OPEN Object by PCEP speakers,a PCC reserves a global
label range and is advertised in PCLRResv message to a PCE. The PCE MAY negotiate
and reserves the global label range and also sends the negotiated global label range
in PCLRResv message to the PCC. Please refer <xref target='I-D.li-mpls-global-label-framework'/>
for MPLS global label allocation.</t>
<t>A PCC MUST send PCLRResv message immediately after the initial LSP synchronization
completion. A PCE SHOULD NOT send PCLabelUpd message to a PCC before PCLRResv
message is received. If the PCC has received PCLabelUpd message and has not initiated label
range reservation, it SHOULD send a PCErr message with Error-type=[TBD]
(label range not reserved) and Error-value=[TBD].</t>
<t>The label range reservation sequence is shown below.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG2">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--- PCLRResv, label type=1 --->|local label range reserved
| (100-500) |global label range negotiated
| label type=2 |
| (600-1000) |
| |
|<--- PCLRResv, label type=2 ---|global label range reserved
| (700-1000) |
| |
]]>
</artwork>
</figure>
<t>[Editor's Note: This section of the document would be updated with
more details about Label Block Negotiation, Reservation, Adjustment etc
in a future revision of the document.]</t>
</section>
<section title="The PCLRResv message"
toc="default"
anchor="SEC_PCLRESV">
<t>A Label Range Reservation message (also referred to as PCLRResv message)
is a PCEP message sent by a PCC to a PCE for the reservation of label range
or by PCE to PCC to send reserved label range for the network. The Message-Type
field of the PCEP common header for the PCLRResv message is set to [TBD].</t>
<t>The format of a PCLRResv message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG7">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
PCLRResv Message>::= <Common Header>
<label-range>
Where:
<label-range> ::= <SRP>
<labelrange-list>
Where
<labelrange-list>::=<LABEL-RANGE>[<labelrange-list>]
]]>
</artwork>
</figure>
<t>There are two mandatory objects that MUST be included within each
<label-range> in the PCLRResv message: the SRP Object and LABEL-RANGE object.</t>
<t>SRP object is defined in <xref target='I-D.ietf-pce-stateful-pce'/> and this document
extends the use of SRP object in PCLRResv message. If the SRP object is
missing, the receiving PCE MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=10 (SRP object missing).</t>
<t>PCC generates the value of SRP-ID-number in SRP object of PCLRResv
message send to a PCE. The PCE MUST include the same SRP-ID-number in
SRP object of PCLRResv message sent to the PCC in response to PCLRResv message.</t>
<t>LABEL-RANGE object is defined in <xref target="SEC_LABELRANGE"/>. If the LABEL-RANGE object is
missing, the receiving PCE MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=[TBD] (Label object missing).</t>
<t>[Editor's Note: This section of the document would be updated with
more details about Label Block Negotiation, Reservation, Adjustment etc
in a future revision of the document.]</t>
</section>
<section title="LABEL-RANGE Object"
toc="default"
anchor="SEC_LABELRANGE">
<t>The LABEL-RANGE object MUST be carried within PCLRResv message. The LABEL-RANGE
object is used to carry the label range information based on the label type.</t>
<t>LABEL-RANGE Object-Class is TBD.</t>
<t>LABEL-RANGE Object-Type is 1.</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG10">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label type | range size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label base | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="label type (8 bit):">The values defined for label type are
label type 1 specifies the local label. It means the label range is non negotiable.
label type 2 specifies the global label. It means the label range is negotiable.
Refer <xref target='I-D.li-mpls-global-label-framework'/> for global label.</t>
<t hangText="Range size (24 bit):">It specifies the size of label range.</t>
<t hangText="Label base (20 bit):">It specifies the minimum label of label range.</t>
<t hangText="Reserved (12 bit):">Set to zero while sending, ignored on receive.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:43:07 |