One document matched: draft-ietf-pce-inter-layer-ext-10.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC4203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml">
<!ENTITY RFC4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5150.xml">
<!ENTITY RFC5212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5212.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5339.xml">
<!ENTITY RFC5520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5520.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY RFC5623 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5623.xml">
<!ENTITY RFC5886 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5886.xml">
<!ENTITY RFC6001 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6001.xml">
<!ENTITY RFC6457 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6457.xml">
<!ENTITY RFC7420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7420.xml">
<!ENTITY RFC7926 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7926.xml">
]>
<rfc category="std" docName="draft-ietf-pce-inter-layer-ext-10" ipr="trust200902">
<front>
<title abbrev="Inter-Layer PCEP">Extensions to the Path Computation Element communication
Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering</title>
<author fullname="Eiji Oki" initials="E." surname="Oki">
<organization>University of Electro-Communications</organization>
<address>
<postal>
<street>Tokyo</street>
<country>Japan</country>
</postal>
<email>oki@ice.uec.ac.jp</email>
</address>
</author>
<author fullname="Tomonori Takeda" initials="T." surname="Takeda">
<organization>NTT</organization>
<address>
<postal>
<street>3-9-11 Midori-cho</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<country>Japan</country>
</postal>
<email>takeda.tomonori@lab.ntt.co.jp</email>
</address>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Juniper Networks</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author fullname="Fatai Zhang" initials="F." surname="Zhang">
<organization>Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>F3-5-B R&D Center, Huawei Base</street>
<city>Bantian, Longgang District</city>
<region>Shenzhen</region>
<country>P. R. China</country>
<code>518129</code>
</postal>
<phone>+86-755-28972912</phone>
<email>zhangfatai@huawei.com</email>
</address>
</author>
<date year="2016" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<keyword>Multi-layer</keyword>
<keyword>Multi-domain</keyword>
<keyword>Inter-domain</keyword>
<keyword>Traffic Engineering</keyword>
<abstract>
<t>The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.</t>
<t>MPLS and GMPLS networks may be constructed from layered service
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network layers
through a process called inter-layer traffic engineering. PCE is a
candidate solution for such requirements.</t>
<t>The PCE communication Protocol (PCEP) is designed as a communication
protocol between Path Computation Clients (PCCs) and PCEs. This
document presents PCEP extensions for inter-layer traffic engineering.</t>
</abstract>
<note title="Requirements Language">
<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>
</note>
</front>
<middle>
<!-- === Introduction === -->
<section anchor="introduction" title="Introduction">
<t>The Path Computation Element (PCE) defined in <xref target="RFC4655" />
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, and a PCE
may initiate or modify services in a network by supplying new paths
(<xref target="I-D.ietf-pce-stateful-pce" />, <xref target="I-D.ietf-pce-pce-initiated-lsp"/>).</t>
<t>A network may comprise multiple layers. These layers may represent
separations of technologies (e.g., packet switch capable (PSC), time
division multiplex (TDM), lambda switch capable (LSC)) <xref target="RFC3945" />,
separation of data plane switching granularity levels (e.g., VC4 and VC12)
<xref target="RFC5212" />, or a distinction between client and server networking
roles (e.g., commercial or administrative separation of client and server networks).
In this multi-layer network, Label Switched Paths (LSPs) in lower layers are used to
carry higher-layer LSPs. The network topology formed by lower-layer LSPs and
advertised as traffic engineering links (TE links) in the higher layer is called a
Virtual Network Topology (VNT) <xref target="RFC5212"/>. Discussion of other ways
that network layering can be support such that connectivity in a higher layer
network can be provided by LSPs in a lower layer network is provided in
<xref target="RFC7926" />.</t>
<t>It is important to optimize network resource utilization globally,
i.e., taking into account all layers, rather than optimizing resource
utilization at each layer independently. This allows better network
efficiency to be achieved. This is what we call inter-layer traffic
engineering. This includes mechanisms allowing the computation of
end-to-end paths across layers (known as inter-layer path
computation), and mechanisms for control and management of the VNT by
setting up and releasing LSPs in the lower layers <xref target="RFC5212" />.</t>
<t>PCE can provide a suitable mechanism for resolving inter-layer path
computation issues. The framework for applying the PCE-based path
computation architecture to inter-layer traffic engineering is
described in <xref target="RFC5623" />.</t>
<t>The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs and is defined in <xref target="RFC5440" />. A set of
requirements for PCEP extensions to support inter-layer traffic
engineering is described in <xref target="RFC6457" />.</t>
<t>This document presents PCEP extensions for inter-layer traffic
engineering that satisfy the requirements described in <xref target="RFC6457" />.</t>
</section>
<section anchor="overview" title="Overview of PCE-Based Inter-Layer Path Computation">
<t><xref target="RFC4206" /> defines a way to signal a higher-layer LSP which has an
explicit route that includes hops traversed by LSPs in lower layers.
The computation of end-to-end paths across layers is called Inter-
Layer Path Computation.</t>
<t>A Label Switching Router (LSR) in the higher-layer might not have
information on the lower-layer topology, particularly in an overlay
or augmented model <xref target="RFC3945" />, and hence may not be able to compute an
end-to-end path across layers.</t>
<t>PCE-based inter-layer path computation consists of using one or more
PCEs to compute an end-to-end path across layers. This could be
achieved by relying on a single PCE that has topology information
about multiple layers and can directly compute an end-to-end path
across layers considering the topology of all of the layers.
Alternatively, the inter-layer path computation could be performed
using multiple cooperating PCEs where each PCE has information about
the topology of one or more layers (but not all layers) and where the
PCEs collaborate to compute an end-to-end path.</t>
<t>As described in <xref target="RFC5339" />, a hybrid nodes may advertise a single TE
link with multiple switching capabilities. Those TE links exist at
the layer/region boarder normally. In this case, PCE needs to be
capable of specifying the server layer path information when the
server layer path information is required to be returned to the PCC.</t>
<t><xref target="RFC5623" /> describes models for inter-layer path computation in more
detail.</t>
</section>
<section anchor="protext" title="Protocol Extensions">
<t>This section describes PCEP extensions for inter-layer path
computation. Four new objects are defined: the INTER-LAYER object,
the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-
INDICATION object. Also, two new metric types are defined.</t>
<section anchor="interlayerObj" title="INTER-LAYER Object">
<t>The INTER-LAYER object is optional and can be used in PCReq and PCRep
messages, and also in PCRpt, PCUpd, and PCInitiate message.</t>
<t>In a PCReq message, the INTER-LAYER object indicates whether inter-
layer path computation is allowed, the type of path to be computed,
and whether triggered signaling (hierarchical LSPs per <xref target="RFC4206" /> or
stitched LSPs per <xref target="RFC5150" /> depending on physical network
technologies) is allowed. When the INTER-LAYER object is absent from
a PCReq message, the receiving PCE MUST process as though inter-layer
path computation had been explicitly disallowed (I-bit set to zero -
see below).</t>
<t>In a PCRep message, the INTER-LAYER object indicates whether inter-
layer path computation has been performed, the type of path that has
been computed, and whether triggered signaling is used.</t>
<t>When a PCReq message includes more than one request, an INTER-LAYER
object is used per request. When a PCRep message includes more than
one path per request that is responded to, an INTER-LAYER object is
used per path.</t>
<t>The applicability of this object to PCRpt and PCUpd messages follows
as the usage of other objects on those messages as described in
<xref target="I-D.ietf-pce-stateful-pce" />. The applicability of
this object to the PCInitiate message follows as the usage of other
objects on those messages as described in
<xref target="I-D.ietf-pce-pce-initiated-lsp" />.</t>
<t>INTER-LAYER Object-Class TBD1 to be assigned by IANA.</t>
<t>INTER-LAYER Object-Type 1 to be assigned by IANA.</t>
<t>The format of the INTER-LAYER object body is shown in
<xref target="interlayerFig" />.</t>
<figure anchor="interlayerFig" title="The INTER-LAYER Object">
<artwork>
<![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 |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>I flag (1 bit): The I flag is used by a PCC in a PCReq message to
indicate to a PCE whether an inter-layer path is allowed. When the I
flag is set (one), the PCE MAY perform inter-layer path computation
and return an inter-layer path. When the flag is clear (zero), the
path that is returned MUST NOT be an inter-layer path.</t>
<t>The I flag is used by a PCE in a PCRep message to indicate to a PCC
whether the path returned is an inter-layer path. When the I flag is
set (one), the path is an inter-layer path. When it is clear (zero),
the path is contained within a single layer either because inter-
layer path computation was not performed or because a mono-layer path
(without any virtual TE link and without any loose hop that spans the
lower-layer network) was found notwithstanding the use of inter-layer
path computation.</t>
<t>M flag (1 bit): The M flag is used by a PCC in a PCReq message to
indicate to a PCE whether mono-layer path or multi-layer path is
requested. When the M flag is set (one), multi-layer path is
requested. When it is clear (zero), mono-layer path is requested.</t>
<t>The M flag is used by a PCE in a PCRep message to indicate to a PCC
whether mono-layer path or multi-layer path is returned. When M flag
is set (one), multi-layer path is returned. When M flag is set (zero),
mono-layer path is returned.</t>
<t>If the I flag is clear (zero), the M flag has no meaning and MUST be
ignored.</t>
<t><xref target="RFC6457" /> describes two sub-options for mono-layer path.
<list style="symbols">
<t>A mono-layer path that is specified by strict hops. The path may
include virtual TE links.</t>
<t>A mono-layer path that includes loose hops that span the lower-
layer network.</t>
</list></t>
<t>The choice of this sub-option can be specified by the use of O flag
in the RP object specified in <xref target="RFC5440" />.</t>
<t>T flag (1 bit): The T flag is used by a PCC in a PCReq message to
indicate to a PCE whether triggered signaling is allowed. When the T
flag is set (one), triggered signaling is allowed. When it is clear
(zero), triggered signaling is not allowed.</t>
<t>The T flag is used by a PCE in a PCRep message to indicate to a PCC
whether triggered signaling is required to support the returned path.
When the T flag is set (one), triggered signaling is required. When
it is clear (zero), triggered signaling is not required.</t>
<t>Note that triggered signaling is used to support hierarchical
<xref target="RFC4206" /> or stitched (xref target="RFC5150" /> LSPs
according to the physical attributes of the network layers.</t>
<t>If the I flag is clear (zero), the T flag has no meaning and MUST be
ignored.</t>
<t>Note that the I flag and M flag differ in the following ways. When
the I flag is clear (zero), virtual TE links must not be used in path
computation. In addition, loose hops that span the lower-layer
network must not be specified. Only regular TE links from the same
layer may be used.
<list style="symbols">
<t>When the I flag is set (one), the M flag is clear (zero), and the T
flag is set (one), virtual TE links are allowed in path computation.
In addition, when the O flag of the RP object is set, loose hops that
span the lower-layer network may be specified. This will initiate
lower-layer LSP setup, thus inter-layer path is setup even though the
path computation result from a PCE to a PCC include hops from the
same layer only.</t>
<t>However, when the I flag is set (one), the M flag is clear (zero),
and the T flag is clear (zero), since triggered signaling is not
allowed, virtual TE links must not be used in path computation. In
addition, loose hops that span the lower-layer network must not be
specified. Therefore, this is equivalent to the I flag being clear
(zero).</t>
</list></t>
<t>Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero
and SHOULD be ignored on receipt. A PCE that forwards a path
computation request to other PCEs SHOULD preserve the settings of
reserved bits in the PCReq messages it sends and in the PCRep
messages it forwards to PCCs.</t>
</section>
<section anchor="switchlayerObj" title="SWITCH-LAYER Object">
<t>The SWITCH-LAYER object is optional on a PCReq message and specifies
switching layers in which a path MUST, or MUST NOT, be established. A
switching layer is expressed as a switching type and encoding type.</t>
<t>When a SWITCH-LAYER object is used on a PCReq it is interpreted in
the context of the INTER-LAYER object on the same message. If no
INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER
object as though inter-layer path computation had been explicitly
disallowed. In such a case, the SWITCH-LAYER object MUST NOT have
more than one LSP Encoding Type and Switching Type with the I flag
set.</t>
<t>The SWITCH-LAYER object is optional on a PCRep message, where it is
used with the NO-PATH object in the case of unsuccessful path
computation to indicate the set of constraints that could not be
satisfied.</t>
<t>The SWTCH-LAYER object may be used on a PCRpt message consistent with
how properties of existing LSPs are reported on that message
<xref target="I-D.ietf-pce-stateful-pce" />. The SWTCH-LAYER object is
not used on a PCUpd or PCInitiate message.</t>
<t>SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA.</t>
<t>SWITCH-LAYER Object-Type 1 is to be assigned by IANA.</t>
<t>The format of the SWITCH-LAYER object body is shown in
<xref target="switchlayerFig" />.</t>
<figure anchor="switchlayerFig" title="The SWITCH-LAYER Object">
<artwork>
<![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>Each row indicates a switching type and encoding type that must or
must not be used for specified layer(s) in the computed path.</t>
<t>The format is based on <xref target="RFC3471" />, and has equivalent semantics.</t>
<t>LSP Encoding Type (8 bits): see <xref target="RFC3471"/> for a description of
parameters.</t>
<t>Switching Type (8 bits): see <xref target="RFC3471" /> for a description of
parameters.</t>
<t>I flag (1 bit): the I flag indicates whether a layer with the
specified switching type and encoding type must or must not be used
by the computed path. When the I flag is set (one), the computed path
MUST traverse a layer with the specified switching type and encoding
type. When the I flag is clear (zero), the computed path MUST NOT
enter or traverse any layer with the specified switching type and
encoding type.</t>
<t>When a combination of switching type and encoding type is not
included in SWITCH-LAYER object, the computed path MAY traverse a
layer with that combination of switching type and encoding type.</t>
<t>A PCC may want to specify only a Switching Type and not an LSP
Encoding Type. In this case, the LSP Encoding Type is set to zero.</t>
</section>
<section anchor="ReqAdapCapObj" title="REQ-ADAP-CAP Object">
<t>The REQ-ADAP-CAP object is optional and is used to specify a
requested adaptation capability for both ends of the lower layer LSP.
The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE
communication, where the PCE that is responsible for computing higher
layer paths acts as a PCC to request a path computation from a PCE
that is responsible for computing lower layer paths.</t>
<t>The REQ-ADAP-CAP object is used in a PCRep message in case of
unsuccessful path computation (in this case, the PCRep message also
contains a NO-PATH object, and the REQ-ADAP-CAP object is used to
indicate the set of constraints that could not be satisfied).</t>
<t>The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-
layer network to specify a requested adaptation capability for both
ends of the LSP. In this case, it MAY be carried without INTER-LAYER
Object.</t>
<t>The applicability of this object to PCRpt and PCUpd messages follows
as the usage of other objects on those messages as described in
<xref target="I-D.ietf-pce-stateful-pce" />. The applicability of
this object to the PCInitiate message follows as the usage of other
objects on those messages as described in
<xref target="I-D.ietf-pce-pce-initiated-lsp" />.</t>
<t>REQ-ADAP-CAP Object-Class TBD3 is to be assigned by IANA.</t>
<t>REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA.</t>
<t>The format of the REQ-ADAP-CAP object body is shown in
<xref target="ReqAdapCapFig" />.</t>
<figure anchor="ReqAdapCapFig" title="The REQ-ADAP-CAP Object">
<artwork>
<![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The format is based on <xref target="RFC6001" /> and has equivalent semantics as the
IACD Upper SC and Lower SC.</t>
<t>Switching Capability (8 bits): see <xref target="RFC4203" /> for a description of
parameters.</t>
<t>Encoding (8 bits): see <xref target="RFC3471" /> for a description of parameters.</t>
<t>A PCC may want to specify a Switching Capability, but not an Encoding.
In this case, the Encoding MUST be set zero.</t>
</section>
<section anchor="newmetric" title="New Metric Types">
<t>This document defines two new metric types for use in the PCEP METRIC
object.</t>
<t>IANA has assigned the value TBD5 to indicate the metric "Number of
adaptations on a path."</t>
<t>IANA has assigned the value TBD6 to indicate the metric "Number of
layers to be involved on a path."</t>
<t>See <xref target="pcreq" /> and <xref target="pcrep" /> for a description of
how these metrics are applied.</t>
</section>
<section anchor="SvrIndObj" title="SERVER-INDICATION Object">
<t>The SERVER-INDICATION is optional and is used to indicate that path
information included in the ERO is server layer information and
specify the characteristics of the server layer, e.g., the switching
capability and encoding of the server layer path.</t>
<t>The format of the SERVER-INDICATION object body is shown in
<xref target="SvrIndFig" />.</t>
<figure anchor="SvrIndFig" title="The SERVER-INDICATION Object">
<artwork>
<![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>SERVER-INDICATION Object-Class TBD4 to be assigned by IANA.</t>
<t>SERVER-INDICATION Object-Type 1 to be assigned by IANA.</t>
<t>Switching Capability (8 bits): see <xref target="RFC4203" /> for a description of
parameters.</t>
<t>Encoding (8 bits): see <xref target="RFC3471" /> for a description of parameters.</t>
<t>Optional TLVs: Optional TLVs may be included within the object to
specify more specific server layer path information (e.g., traffic
parameters).</t>
</section>
</section>
<section anchor="procedures" title="Procedures">
<section anchor="pcreq" title="Path Computation Request">
<t>A PCC requests or allows inter-layer path computation in a PCReq
message by including the INTER-LAYER object with the I flag set. The
INTER-LAYER object indicates whether inter-layer path computation is
allowed, which path type is requested, and whether triggered
signaling is allowed.</t>
<t>The SWITCH-LAYER object, which MUST NOT be present unless the INTER-
LAYER object is also present, is optionally used to specify the
switching types and encoding types that define layers that must, or
must not, be used in the computed path. When the SWITCH-LAYER object
is used with the INTER-LAYER object I flag clear (zero), inter-layer
path computation is not allowed, but constraints specified in the
SWITCH-LAYER object apply. Example usage includes path computation in
a single layer GMPLS network.</t>
<t>The REQ-ADAP-CAP object is optionally used to specify the interface
switching capability of both ends of the lower layer LSP. The REQ-
ADAP-CAP object is used in inter-PCE communication, where the PCE
that is responsible for computing higher layer paths makes a request
as a PCC to a PCE that is responsible for computing lower layer paths.
Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM
model, where the VNTM makes a request as a PCC to a PCE that is
responsible for computing lower-layer paths.</t>
<t>The METRIC object is optionally used to specify metric types to be
optimized or bounded. When metric type 11 (TBC by IANA) is used, it
indicates that path computation MUST minimize or bound the number of
adaptations on a path. When metric type 12 (TBC by IANA) is used, it
indicates that path computation MUST minimize or bound the number of
layers to be involved on a path.</t>
<t>Furthermore, in order to allow different objective functions to be
applied within different network layers, multiple OF objects MAY be
present. In such a case, the first OF object specifies an objective
function for the higher-layer network, and subsequent OF objects
specify objection functions of the subsequent lower-layer networks.</t>
</section>
<section anchor="pcrep" title="Path Computation Reply">
<t>In the case of successful path computation, the requested PCE replies
to the requesting PCC for the inter-layer path computation result in
a PCRep message that MAY include the INTER-LAYER object. When the
INTER-LAYER object is included in a PCRep message, the I flag, M flag,
and T flag indicate semantics of the path as described in <xref target="interlayerObj" />.
Furthermore, when the C flag of the METRIC object in a PCReq is set,
the METRIC object MUST be included in the PCRep to provide the
computed metric value, as specified in <xref target="RFC5440" />.</t>
<t>PCE MAY specify the server layer path information in the ERO. In this
case, the requested PCE replies a PCRep message that includes at
least two sets of ERO information in the path-list, one is for the
client layer path information, and another one is the server layer
path information. When SERVER-INDICATION is included in a PCRep
message, it indicates that the path in the ERO is the server layer
path information. The server layer path specified in the ERO could be
loose or strict. On receiving the replied path, the PCC (e.g., NMS,
ingress node) can trigger the signaling to setup the LSPs according
to the computed paths.</t>
<t>In the case of unsuccessful path computation, the PCRep message also
contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ-
ADAP-CAP MAY be used to indicate the set of constraints that could
not be satisfied.</t>
</section>
<section anchor="stateful" title="Stateful PCE and PCE Initiated LSPs">
<t>Processing for stateful PCEs is described in
<xref target="I-D.ietf-pce-stateful-pce" />. That document defines the
PCRpt message to allow a PCC to report to a PCE an LSP that already
exists in the network and to delegate control of that LSP to the PCE.</t>
<t>When the LSP is a multi-layer LSP (or a mono-layer LSP for which
specific adaptations exist), the message objects define in this
document are used on the PCRpt to describe an LSP that is delegated
to the PCE so that the PCE may process the LSP.</t>
<t>Furthermore, <xref target="I-D.ietf-pce-stateful-pce" /> defines the
PCUpd message to allow a PCE to modify an LSP that has been delegated to
it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which
specific adaptations exist), the message objects defined in this document
are used on the PCUpd to describe the new attributes of the modified
LSP.</t>
<t>Processing for PCE initiated LSPs is described in
<xref target="I-D.ietf-pce-pce-initiated-lsp" />. That document defines
the PCInitiate message that is used by a PCE to request a PCC to set up a
new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for
which specific adaptations exist), the message objects defined in
this document are used on the PCInitiate to describe the attributes of
the new LSP.</t>
</section>
</section>
<section anchor="updates" title="Updated Format of PCEP Messages">
<t>Message formats in this section, as those in <xref target="RFC5440" /> are presented
using Backus-Naur Format as specified in <xref target="RFC5511" />.</t>
<t>The format of the PCReq message is updated as shown in <xref target="pcreqFig" /></t>
<figure anchor="pcreqFig" title="The Updated PCReq Message">
<artwork>
<![CDATA[
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
]]>
</artwork>
</figure>
<t>The format of the PCRep message is updated as shown in <xref target="pcrepFig" /></t>
<figure anchor="pcrepFig" title="The Updated PCRep Message">
<artwork>
<![CDATA[
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
]]>
</artwork>
</figure>
</section>
<section anchor="manage" title="Manageability Considerations">
<t>Implementations of this specification should provide a mechanism to
configure any optional features (such as whether a PCE supports
inter-layer computation, and which metrics are supported).</t>
<t>A Management Information Base (MIB) module for modeling PCEP is
described in <xref target="RFC7420" />. Systems that already use a MIB
module to manage their PCEP implementations might want to augment that
module to provide controls and indicators for support of inter-layer
features defined in this document, and to add counters of messages sent
and received containing the objects defined here.</t>
<t>However, the preferred mechanism for configuration is through a YANG
model. Work has started on a YANG model for PCEP
<xref target="I-D.pkd-pce-pcep-yang" />, and this could be enhanced as
described for the MIB module, above.</t>
<t>Additional policy configuration might be provided to allow a PCE to
discriminate between the computation services offered to different
PCCs.</t>
<t>A set of monitoring tools for the PCE-based architecture are provided
in <xref target="RFC5886" />. Systems implementing this specification and PCE
monitoring should consider defining extensions to the mechanisms
defined in <xref target="RFC5886" /> to help monitor inter-layer path computation
requests.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA maintains a registry called the "Path Computation Element
Protocol (PCEP) Numbers". This document requests IANA to carry out
actions on subregistries of that registry.</t>
<section anchor="ianaObjects" title="New PCEP Objects">
<t>IANA is requested to make the following assignments from the
"PCEP Objects" subregistry.</t>
<figure anchor="objectFig">
<artwork>
<![CDATA[
Object-Class Value |Name |Object-Type |Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D]
| | 2-15: Unassigned |
SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D]
| | 2-15: Unassigned |
REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D]
| | 2-15: Unassigned |
SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D]
]]>
</artwork>
</figure>
</section>
<section anchor="ianaflags" title="New Registry for INTER-LAYER Object Flags">
<t>IANA is requested to create a new subregistry to manage the Flag
field of the INTER-Layer object called the "Inter-Layer Object
Path Property Bits" registry.</t>
<t>New bit numbers may be allocated only by an "IETF Review" action
<xref target="RFC5226" />. Each bit should be tracked with the
following qualities:
<list style="symbols">
<t>Bit number (counting from bit 0 as the most significant bit up to
a maximum of bit 31)</t>
<t>Capability Description</t>
<t>Defining RFC</t>
</list></t>
<t>IANA is requested to pre-populate the registry as follows:</t>
<figure anchor="flagFig">
<artwork>
<![CDATA[
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| Unassigned |
29 | T | Triggered Signalling Required | [This.I-D]
30 | M | Multi-Layer Requested | [This.I-D]
31 | I | Inter-Layer Allowed | [This.I-D]
]]>
</artwork>
</figure>
</section>
<section anchor="ianametric" title="New Metric Types">
<t>Two new metric types are defined in this document for the METRIC
object (specified in <xref target="RFC5440" />). The IANA is
requested to make the following allocations from the "Metric Object
T Field" registry.</t>
<figure anchor="metricFig">
<artwork>
<![CDATA[
Value | Description | Reference
------+---------------------------------+------------
TBD5 | Number of adaptations on a path | [This.I-D]
TBD6 | Number of layers on a path | [This.I-D]
]]>
</artwork>
</figure>
<t>IANA is further requested to update the registry to show an
assignment action of "IETF Consensus" as already documented in
<xref target="RFC5440" />.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Inter-layer traffic engineering with PCE may raise new security
issues when PCE-PCE communication is done between different layer
networks for inter-layer path computation. Security issues may also
exist when a single PCE is granted full visibility of TE information
that applies to multiple layers.</t>
<t>Path-Key-based mechanism defined in <xref target="RFC5520" /> MAY be applied to
address the topology confidentiality between different layers.</t>
</section>
<section anchor="acks" title="Acknowledgments">
<t>The authors would like to thank Cyril Margaria for his valuable
comments.</t>
</section>
<section anchor="contributors" title="Contributors">
<figure>
<artwork>
<![CDATA[
Jean-Louis Le Roux
France Telecom R&D
Av Pierre Marzin
Lannion
France
22300
Email: jeanlouis.leroux@orange.com
]]>
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3471;
&RFC3945;
&RFC4203;
&RFC4206;
&RFC5226;
&RFC5520;
&RFC5440;
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
</references>
<references title="Informative References">
&RFC4655;
&RFC5150;
&RFC5212;
&RFC5339;
&RFC5511;
&RFC5623;
&RFC5886;
&RFC6001;
&RFC6457;
&RFC7420;
&RFC7926;
<?rfc include="reference.I-D.pkd-pce-pcep-yang"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:19:55 |