rfc8780xml2.original.xml   rfc8780.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
C.2119.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
C.3209.xml"> docName="draft-ietf-pce-wson-rwa-ext-17" number="8780" category="std"
<!ENTITY RFC3630 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
C.3630.xml"> symRefs="true" sortRefs="true" tocInclude="true" version="3">
<!ENTITY RFC5329 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5329.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC6205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6205.xml">
<!ENTITY RFC7570 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7570.xml">
<!ENTITY RFC7579 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7579.xml">
<!ENTITY RFC7581 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7581.xml">
<!ENTITY RFC7689 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7689.xml">
<!ENTITY RFC7688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7688.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC3471 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3471.xml">
<!ENTITY RFC4203 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4203.xml">
<!ENTITY RFC4204 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4204.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4655.xml">
<!ENTITY RFC5420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5420.xml">
<!ENTITY RFC5521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5521.xml">
<!ENTITY RFC6163 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6163.xml">
<!ENTITY RFC6566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6566.xml">
<!ENTITY RFC7446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7446.xml">
<!ENTITY RFC7449 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7449.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-wson-rwa-ext-17" category="st
d" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2020-02-05T20:57:21Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="PCEP Extension for WSON RWA">PCEP Extension for WSON Routi
ng and Wavelength Assignment</title>
<author initials="Y." surname="Lee" fullname="Young Lee, Editor" role="ed
itor">
<organization>Huawei Technologies</organization>
<address><postal><street>5700 Tennyson Parkway Suite 600</street>
<street>Plano, TX 75024</street>
<street>United States of America</street>
</postal>
<email>leeyoung@huawei.com</email>
</address>
</author>
<author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor <title abbrev="PCEP Extension for WSON RWA">The Path Computation Element Com
" role="editor"> munication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WS
<organization abbrev="CTTC">Carl Friedrich Gauss 7</organization> ON) Routing and Wavelength Assignment (RWA)</title>
<address><postal><street>CTTC PMT Ed B4 Av.</street> <seriesInfo name="RFC" value="8780"/>
<street>Castelldefels Barcelona 08860</street> <author initials="Y." surname="Lee" fullname="Young Lee" role="editor">
<street>Spain</street>
</postal>
<phone>(34) 936452916</phone>
<email>ramon.casellas@cttc.es</email>
</address>
</author>
<date year="2020" month="February"/> <organization>Samsung Electronics</organization>
<abstract><t> <address>
This document provides the Path Computation Element communication <postal>
<street></street>
<city></city> <region></region><code></code>
<country></country>
</postal>
<email>younglee.tx@gmail.com</email>
</address>
</author>
<author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor" r
ole="editor">
<organization>CTTC</organization>
<address>
<postal>
<extaddr>Carl Friedrich Gauss 7</extaddr>
<street>PMT Ed B4 Av.</street>
<city>Castelldefels</city><region>Barcelona</region><code>08860</code>
<country>Spain</country>
</postal>
<phone>+34 936452916</phone>
<email>ramon.casellas@cttc.es</email>
</address>
</author>
<date year="2020" month="July"/>
<abstract>
<t>
This document provides Path Computation Element Communication
Protocol (PCEP) extensions for the support of Routing and Wavelength Protocol (PCEP) extensions for the support of Routing and Wavelength
Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Assignment (RWA) in Wavelength Switched Optical Networks (WSONs).
Path provisioning in WSONs requires a routing and wavelength Path provisioning in WSONs requires an RWA process. From a path computation
assignment (RWA) process. From a path computation perspective, perspective,
wavelength assignment is the process of determining which wavelength wavelength assignment is the process of determining which wavelength
can be used on each hop of a path and forms an additional routing can be used on each hop of a path and forms an additional routing
constraint to optical path computation.</t> constraint to optical path computation.</t>
</abstract>
</front>
<middle>
</abstract> <section anchor="sect-3" numbered="true" toc="default">
</front> <name>Introduction</name>
<t>
<middle> <xref target="RFC5440" format="default"/> specifies the Path Computation Elem
<section title="Terminology" anchor="sect-1"><t> ent Communication
This document uses the terminology defined in <xref target="RFC4655"/>, and
<xref target="RFC5440"/>.</t>
</section>
<section title="Requirements Language" anchor="sect-2"><t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all
capitals, as shown here.</t>
</section>
<section title="Introduction" anchor="sect-3"><t>
<xref target="RFC5440"/> specifies the Path Computation Element (PCE) Communi
cation
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a PCE, or between two PCEs. Such interactions include (PCC) and a PCE, or between two PCEs. Such interactions include
path computation requests and path computation replies as well as Path Computation Requests (PCReqs) and Path Computation Replies (PCReps) as w ell as
notifications of specific states related to the use of a PCE in the notifications of specific states related to the use of a PCE in the
context of Multiprotocol Label Switching (MPLS) and Generalized MPLS context of Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering.</t> (GMPLS) Traffic Engineering (TE).</t>
<t>
<t>
A PCC is said to be any network component that makes such a request A PCC is said to be any network component that makes such a request
and may be, for instance, an Optical Switching Element within a and may be, for instance, an optical switching element within a
Wavelength Division Multiplexing (WDM) network. The PCE, itself, Wavelength Division Multiplexing (WDM) network. The PCE, itself,
can be located anywhere within the network, and may be within an can be located anywhere within the network and may be within an
optical switching element, a Network Management System (NMS) or optical switching element, a Network Management System (NMS), or
Operational Support System (OSS), or may be an independent network an Operational Support System (OSS), or it may be an independent network
server.</t> server.</t>
<t>
<t>
This document provides the PCEP extensions for the support of This document provides the PCEP extensions for the support of
Routing and Wavelength Assignment (RWA) in Wavelength Switched Routing and Wavelength Assignment (RWA) in Wavelength Switched
Optical Networks (WSON) based on the requirements specified in Optical Networks (WSONs) based on the requirements specified in
<xref target="RFC6163"/> and <xref target="RFC7449"/>.</t> <xref target="RFC6163" format="default"/> and <xref target="RFC7449" format="
default"/>.</t>
<t> <t>
WSON refers to WDM based optical networks in which switching is performed WSON refers to WDM-based optical networks in which switching is performed
selectively based on the wavelength of an optical signal. The devices used selectively based on the wavelength of an optical signal. The devices used
in WSONs that are able to switch signals based on signal wavelength are in WSONs that are able to switch signals based on signal wavelength are
known as Lambda Switch Capable (LSC). WSONs can be transparent or known as Lambda Switch Capable (LSC). WSONs can be transparent or
translucent. A transparent optical network is made up of optical devices translucent. A transparent optical network is made up of optical devices
that can switch but not convert from one wavelength to another, all within that can switch but not convert from one wavelength to another, all within
the optical domain. On the other hand, translucent networks include 3R the optical domain. On the other hand, translucent networks include 3R
regenerators (Re-amplification, Re-shaping, Re-timing) that are sparsely regenerators (reamplification, reshaping, and retiming) that are sparsely
placed. The main function of the 3R regenerators is to convert one optical placed. The main function of the 3R regenerators is to convert one optical
wavelength to another.</t> wavelength to another.</t>
<t>
<t> An LSC Label Switched Path (LSP) may span one
A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one
or several transparent segments, which are delimited by 3R or several transparent segments, which are delimited by 3R
regenerators typically with electronic regenerator and optional regenerators typically with electronic regenerator and optional
wavelength conversion. Each transparent segment or path in WSON is wavelength conversion. Each transparent segment or path in WSON is
referred to as an optical path. An optical path may span multiple referred to as an optical path. An optical path may span multiple
fiber links and the path should be assigned the same wavelength for fiber links, and the path should be assigned the same wavelength for
each link. In such case, the optical path is said to satisfy the each link. In a case, the optical path is said to satisfy the
wavelength-continuity constraint. <xref target="fig-1"/> illustrates the wavelength-continuity constraint. <xref target="fig-1" format="default"/> ill
relationship between a LSC LSP and transparent segments (optical ustrates the
relationship between an LSC LSP and transparent segments (optical
paths).</t> paths).</t>
<figure anchor="fig-1">
<figure title="Illustration of a LSC LSP and transparent segments" anchor <name>Illustration of an LSC LSP and Transparent Segments</name>
="fig-1"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
| |I1 | | | | | | I2| | | |I1 | | | | | | I2| |
| |o------| |-------[(3R) ]------| |--------o| | | |o------| |-------[(3R) ]------| |--------o| |
| | | | | | | | | | | | | | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
(X LSC) (LSC LSC) (LSC LSC) (LSC X) (X LSC) (LSC LSC) (LSC LSC) (LSC X)
<-------> <-------> <-----> <-------> <-------> <-------> <-----> <------->
<-----------------------><----------------------> <-----------------------><---------------------->
Transparent Segment Transparent Segment Transparent Segment Transparent Segment
<-------------------------------------------------> <------------------------------------------------->
LSC LSP LSC LSP
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Note that two transparent segments within a WSON LSP do not need to Note that two transparent segments within a WSON LSP do not need to
operate on the same wavelength (due to the wavelength conversion operate on the same wavelength (due to wavelength conversion
capabilities). Two optical channels that share a common fiber link capabilities). Two optical channels that share a common fiber link
cannot be assigned the same wavelength; Otherwise, the two signals cannot be assigned the same wavelength; otherwise, the two signals
would interfere with each other. Note that advanced additional would interfere with each other. Note that advanced additional
multiplexing techniques such as polarization based multiplexing are multiplexing techniques such as polarization-based multiplexing are
not addressed in this document since the physical layer aspects are not addressed in this document since the physical-layer aspects are
not currently standardized. Therefore, assigning the proper not currently standardized. Therefore, assigning the proper
wavelength on a path is an essential requirement in the optical path wavelength on a path is an essential requirement in the optical path
computation process.</t> computation process.</t>
<t>
<t>
When a switching node has the ability to perform wavelength When a switching node has the ability to perform wavelength
conversion, the wavelength-continuity constraint can be relaxed, and conversion, the wavelength-continuity constraint can be relaxed, and
a LSC Label Switched Path (LSP) may use different wavelengths on an LSP may use different wavelengths on
different links along its route from origin to destination. It is, different links along its route from origin to destination. It is,
however, to be noted that wavelength converters may be limited due however, to be noted that wavelength converters may be limited due
to their relatively high cost, while the number of WDM channels that to their relatively high cost, while the number of WDM channels that
can be supported in a fiber is also limited. As a WSON can be can be supported in a fiber is also limited. As a WSON can be
composed of network nodes that cannot perform wavelength conversion, composed of network nodes that cannot perform wavelength conversion,
nodes with limited wavelength conversion, and nodes with full nodes with limited wavelength conversion, and nodes with full
wavelength conversion abilities, wavelength assignment is an wavelength conversion abilities, wavelength assignment is an
additional routing constraint to be considered in all optical path additional routing constraint to be considered in all optical path
computation.</t> computation.</t>
<t>
<t> For example (see <xref target="fig-1" format="default"/>), within a transluce
For example (see <xref target="fig-1"/>), within a translucent WSON, a LSC nt WSON, an LSC
LSP may be established between interfaces I1 and I2, spanning 2 transparent LSP may be established between interfaces I1 and I2, spanning two transparent
segments (optical paths) where the wavelength continuity constraint applies segments (optical paths) where the wavelength continuity constraint applies
(i.e. the same unique wavelength must be assigned to the LSP at each TE (i.e., the same unique wavelength must be assigned to the LSP at each TE
link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE
link, the switching capabilities of the TE link would be (X X) where X link, the switching capabilities of the TE link would be (X X), where X
refers to the switching capability of I1 and I2. For example, X can be refers to the switching capability of I1 and I2. For example, X can be
Packet Switch Capable (PSC), Time Division Multiplexing (TDM), etc.</t> Packet Switch Capable (PSC), Time-Division Multiplexing (TDM), etc.</t>
<t>
<t> This document aligns with
This document aligns with GMPLS extensions for PCEP <xref <xref target="RFC8779"
target="PCEP-GMPLS"/> for generic properties such as label, label-set and format="default"/> for generic properties such as label, label set, and
label assignment noting that wavelength is a type of label. Wavelength label assignment, noting that a wavelength is a type of label. Wavelength
restrictions and constraints are also formulated in terms of labels per restrictions and constraints are also formulated in terms of labels per
<xref target="RFC7579"/>.</t> <xref target="RFC7579" format="default"/>.</t>
<t>
<t>
The optical modulation properties, which are also referred to as signal The optical modulation properties, which are also referred to as signal
compatibility, are already considered in signaling in <xref compatibility, are already considered in the signaling in <xref target="RFC75
target="RFC7581"/> and <xref target="RFC7688"/>. In order to improve the 81" format="default"/> and <xref target="RFC7688" format="default"/>. In order t
signal quality and limit some optical effects several advanced modulation o improve the
signal quality and limit some optical effects, several advanced modulation
processing capabilities are used by the mechanisms specified in this processing capabilities are used by the mechanisms specified in this
document. These modulation capabilities contribute not only to optical document.
signal quality checks but also constrain the selection of sender and
receiver, as they should have matching signal processing capabilities. This These modulation capabilities not only contribute to optical signal
document includes signal compatibility constraints as part of RWA path quality checks but also constrain the selection of sender and
receiver, as they should have matching signal processing
capabilities.
This document includes signal compatibility constraints as part of RWA path
computation. That is, the signal processing capabilities (e.g., modulation computation. That is, the signal processing capabilities (e.g., modulation
and Forward Error Correction (FEC)) indicated by means of optical interface and Forward Error Correction (FEC)) indicated by means of the Optical Interfa
class (OIC) must be compatible between the sender and the receiver of the ce
Class (OIC) must be compatible between the sender and the receiver of the
optical path across all optical elements.</t> optical path across all optical elements.</t>
<t>
<t>
This document, however, does not address optical impairments as part This document, however, does not address optical impairments as part
of RWA path computation. See <xref target="RFC6566"/> for the framework for o ptical of RWA path computation. See <xref target="RFC6566" format="default"/> for th e framework for optical
impairments.</t> impairments.</t>
</section>
</section> <section anchor="sect-1" numbered="true" toc="default">
<name>Terminology</name>
<t>
This document uses the terminology defined in <xref target="RFC4655" format="
default"/> and
<xref target="RFC5440" format="default"/>.</t>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Encoding of a RWA Path Request" anchor="sect-4"><t> <section anchor="sect-4" numbered="true" toc="default">
<xref target="fig-2"/> shows one typical PCE based implementation, which is <name>Encoding of an RWA Path Request</name>
<t>
<xref target="fig-2" format="default"/> shows one typical PCE-based implement
ation, which is
referred to as the Combined Process (R&amp;WA). With this architecture, referred to as the Combined Process (R&amp;WA). With this architecture,
the two processes of routing and wavelength assignment are accessed the two processes of routing and wavelength assignment are accessed
via a single PCE. This architecture is the base architecture via a single PCE. This architecture is the base architecture
specified in <xref target="RFC6163"/> and the PCEP extensions that are specif ied in specified in <xref target="RFC6163" format="default"/>, and the PCEP extensio ns that are specified in
this document are based on this architecture.</t> this document are based on this architecture.</t>
<figure anchor="fig-2">
<figure title="Combined Process (R&amp;WA) architecture" anchor="fig-2">< <name>Combined Process (R&amp;WA) Architecture</name>
artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------------+ +----------------------------+
+-----+ | +-------+ +--+ | +-----+ | +-------+ +--+ |
| | | |Routing| |WA| | | | | |Routing| |WA| |
| PCC |<----->| +-------+ +--+ | | PCC |<----->| +-------+ +--+ |
| | | | | | | |
+-----+ | PCE | +-----+ | PCE |
+----------------------------+ +----------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section title="Wavelength Assignment (WA) Object" anchor="sect-4.1"><t> <section anchor="sect-4.1" numbered="true" toc="default">
Wavelength allocation can be performed by the PCE by different <name>Wavelength Assignment (WA) Object</name>
means: <t>
Wavelength allocation can be performed by the PCE by
<list style="format (%c)"> means of:
<t>By means of Explicit Label Control <xref target="RFC3471"/> where the
PCE allocates which label to use for each interface/node along the path.
The allocated labels MAY appear after an interface route subobject.</t>
<t>By means of a Label Set where the PCE provides a range of potential
labels to allocate by each node along the path.</t>
</list> </t>
</t> <ol spacing="normal" type="(%c)">
<li>Explicit Label Control <xref target="RFC3471" format="default"/>
where the PCE allocates which label to use for each interface/node
along the path. The allocated labels <bcp14>MAY</bcp14> appear
after an interface route subobject.</li>
<t> <li>A Label Set where the PCE provides a range of potential
labels to be allocated by each node along the path.</li>
</ol>
<t>
Option (b) allows distributed label allocation (performed during Option (b) allows distributed label allocation (performed during
signaling) to complete wavelength assignment.</t> signaling) to complete wavelength assignment.</t>
<t> <t>
Additionally, given a range of potential labels to allocate, a PC Additionally, given a range of potential labels to allocate, a PCReq
Request SHOULD convey the heuristic / mechanism used for the <bcp14>SHOULD</bcp14> convey the heuristic or mechanism used for the
allocation.</t> allocation.</t>
<t>
<t> Per <xref target="RFC5440" format="default"/>, the format of a PCReq message
The format of a PCReq message per <xref target="RFC5440"/> after incorporatin after incorporating the
g the
Wavelength Assignment (WA) object is as follows:</t> Wavelength Assignment (WA) object is as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<PCReq Message> ::= <Common Header> <PCReq Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
]]></sourcecode>
Where: <t> Where:</t>
<sourcecode type="rbnf"><![CDATA[
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> <END-POINTS>
<WA> <WA>
[other optional objects...] [other optional objects...]
]]></artwork> ]]></sourcecode>
</figure> <t>
If the WA object is present in the request, it <bcp14>MUST</bcp14> be encoded
<t> after the
If the WA object is present in the request, it MUST be encoded after the END-POINTS object as defined in <xref target="RFC8779" format="default"/>. Th
END-POINTS object as defined in <xref target="PCEP-GMPLS"/>. The WA Object e WA object
is mandatory in this document. Orderings for the other optional objects are is mandatory in this document. Orderings for the other optional objects are
irrelevant.</t> irrelevant.</t>
<t>
<t> For the WA object, the Object-Class is 42,
WA Object-Class is (TBD1) (To be assigned by IANA).</t> and the Object-Type is 1.</t>
<t>The format of the WA object body is as follows:</t>
<t> <figure anchor="fig-3">
WA Object-Type is 1.</t> <name>WA Object</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>The format of the WA object body is as follows:</t>
<figure title="WA Object" anchor="fig-3"><artwork><![CDATA[
0 1 2 3 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 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 |M| | Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols">
<t>Reserved (16 bits): Reserved for future use and SHOULD be zeroed
and ignored on receipt.</t>
<t>Flags (16 bits)</t>
</list> <dl newline="false" spacing="normal">
</t>
<t> <dt>Reserved (16 bits):</dt><dd>Reserved for future use and <bcp14>SHO
One flag bit is allocated as follows: ULD</bcp14> be zeroed
and ignored on receipt.</dd>
<list style="hanging" hangIndent="6"> <dt>Flags field (16 bits):</dt><dd><t>One flag bit is allocated as fol lows:</t>
<t hangText="M (Mode - 1 bit):"> M bit is used to indicate the mode of <dl newline="false" spacing="normal">
wavelength assignment. When M bit is set to 1, this indicates that the <dt>M (1 bit):</dt><dd>Wavelength Allocation Mode. The M bit is used t
o indicate the mode of
wavelength assignment. When the M bit is set to 1, this indicates that the
label assigned by the PCE must be explicit. That is, the selected way to label assigned by the PCE must be explicit. That is, the selected way to
convey the allocated wavelength is by means of Explicit Label Control convey the allocated wavelength is by means of Explicit Label Control
for each hop of a computed LSP. Otherwise (M bit is set to 0), the for each hop of a computed LSP. Otherwise (M bit is set to 0), the
label assigned by the PCE need not be explicit (i.e., it can be label assigned by the PCE need not be explicit (i.e., it can be
suggested in the form of label set objects in the corresponding suggested in the form of Label Set objects in the corresponding
response, to allow distributed WA. If M is 0, the PCE MUST return a response, to allow distributed WA. If M is 0, the PCE <bcp14>MUST</bcp14>
Label Set Field as described in Section 2.6 of <xref target="RFC7579"/> return a
in the response. See Section 5 of this document for the encoding Label Set Field as described in <xref target="RFC7579" sectionFormat="of"
discussion of a Label Set Field in a PCRep message.</t> section="2.6"/>
</list> in the response. See <xref target="sect-5" /> of this document for the en
</t> coding
discussion of a Label Set Field in a PCRep message.</dd>
<t>All unused flags SHOULD be zeroed. IANA is to create a new registry to </dl>
manage the Flag field of the WA object. <t>All unused flags <bcp14>SHOULD</bcp14> be zeroed. IANA has created
a new registry to manage the Flags field of the WA object.</t>
<list style="symbols"> </dd>
<t>TLVs (variable). In the TLVs field, the following two TLVs are
defined. At least one TLV MUST be present.</t>
</list>
<list style="hanging" hangIndent="3">
<t hangText="Wavelength Selection TLV:"> A TLV of type (TBD2) with
fixed length of 32 bits indicating the wavelength selection. See <xref
target="sect-4.2"/> for details.</t>
<t hangText="Wavelength Restriction Constraint TLV:"> A TLV of type
(TBD3) with variable length indicating wavelength restrictions. See
<xref target="sect-4.3"/> for details.</t>
</list> <dt>TLVs (variable):</dt><dd><t>In the TLVs field, the following two TL
</t> Vs are
defined. At least one TLV <bcp14>MUST</bcp14> be present.</t>
</section> <dl newline="false" spacing="normal">
<dt>Wavelength Selection TLV:</dt><dd>The type of this TLV is 8,
and it has a
fixed length of 32 bits. This TLV indicates the wavelength selection.
See
<xref target="sect-4.2" format="default"/> for details.</dd>
<dt>Wavelength Restriction TLV:</dt><dd>The type of this
TLV is 9, and it has a variable length. This TLV indicates wavelength r
estrictions. See
<xref target="sect-4.3" format="default"/> for details.</dd>
</dl>
</dd>
</dl>
<section title="Wavelength Selection TLV" anchor="sect-4.2"><t> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<name>Wavelength Selection TLV</name>
<t>
The Wavelength Selection TLV is used to indicate the wavelength The Wavelength Selection TLV is used to indicate the wavelength
selection constraint in regard to the order of wavelength assignment selection constraint in regard to the order of wavelength assignment
to be returned by the PCE. This TLV is only applied when M bit is to be returned by the PCE. This TLV is only applied when the M bit is
set in the WA Object specified in <xref target="sect-4.1"/>. This TLV MUST NO set in the WA object specified in <xref target="sect-4.1" format="default"/>.
T be This TLV <bcp14>MUST NOT</bcp14> be
used when the M bit is cleared.</t> used when the M bit is cleared.</t>
<t>
<t> The encoding of this TLV is specified as the WavelengthSelection sub-TLV
The encoding of this TLV is specified as the Wavelength Selection in <xref target="RFC7689" sectionFormat="of" section="4.2.2"/>. IANA has
Sub-TLV in Section 4.2.2 of <xref target="RFC7689"/>. IANA is to allocate a n allocated a new TLV type for the Wavelength Selection TLV (Type 8).</t>
ew TLV </section>
type, Wavelength Selection TLV type (TBD2).</t> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Wavelength Restriction TLV</name>
</section> <t>
For any request that contains a wavelength assignment, the requester (PCC)
<section title="Wavelength Restriction Constraint TLV" anchor="sect-4.3"> <bcp14>MUST</bcp14> specify a restriction on the wavelengths to be
<t> used. This restriction is to be interpreted by the PCE as a constraint on
For any request that contains a wavelength assignment, the requester the tuning ability of the origination laser transmitter or on any other
(PCC) MUST specify a restriction on the wavelengths to be used. This maintenance-related constraints. Note that if the LSC LSP spans different
restriction is to be interpreted by the PCE as a constraint on the segments, the PCE must have mechanisms to know the tunability restrictions
tuning ability of the origination laser transmitter or on any other of the involved wavelength converters/regenerators, e.g., by means of the
maintenance related constraints. Note that if the LSP LSC spans Traffic Engineering Database (TED) via either IGP or NMS. Even if the PCE
different segments, the PCE must have mechanisms to know the knows the tunability of the transmitter, the PCC must be able to apply
tunability restrictions of the involved wavelength converters / additional constraints to the request.</t>
regenerators, e.g. by means of the Traffic Engineering Database <t>
(TED) either via IGP or Network Management System (NMS). Even if the The format of the Wavelength Restriction TLV is as
PCE knows the tunability of the transmitter, the PCC must be able to
apply additional constraints to the request.</t>
<t>
The format of the Wavelength Restriction Constraint TLV is as
follows:</t> follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[ <Wavelength Restriction> ::=
<Wavelength Restriction Constraint> ::=
(<Action> <Count> <Reserved> (<Action> <Count> <Reserved>
<Link Identifiers> <Wavelength Restriction>)... <Link Identifiers> <Wavelength Constraint>)...
]]></sourcecode>
Where <t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<Link Identifiers> ::= <Link Identifier> [<Link Identifiers>] <Link Identifiers> ::= <Link Identifier> [<Link Identifiers>]
]]></artwork> ]]></sourcecode>
</figure>
<t>See Section 4.3.1. for the encoding of the Link Identifiers Field.</t>
<t> These fields (i.e., &lt;Action&gt;, &lt;Link Identifiers&gt; and <t>See <xref target="sect-4.3.1"/> for the encoding of the Link
&lt;Wavelength Restriction&gt;, etc.) MAY appear together more than Identifier field.</t>
<t> These fields (i.e., &lt;Action&gt;, &lt;Link Identifiers&gt;, and
&lt;Wavelength Constraint&gt;, etc.) <bcp14>MAY</bcp14> appear together m
ore than
once to be able to specify multiple actions and their once to be able to specify multiple actions and their
restrictions.</t> restrictions.</t>
<t>
<t> IANA has allocated a new TLV type for the Wavelength Restriction
IANA is to allocate a new TLV type, Wavelength Restriction TLV (Type 9).</t>
Constraint TLV type (TBD3).</t> <t>The TLV data is defined as follows:</t>
<figure anchor="fig-4">
<t>The TLV data is defined as follows:</t> <name>Wavelength Restriction TLV Encoding</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="Wavelength Restriction Constraint TLV Encoding" anchor="fi
g-4"><artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved | | Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers Field | | Link Identifiers |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Constraint |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~ ~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved | | Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers Field | | Link Identifiers |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Constraint |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"><t>Action (8 bits): <dl newline="true" spacing="normal">
<dt>Action (8 bits):</dt><dd>
<list style="symbols"><t>0 - Inclusive List indicates that one or more <dl newline="false" spacing="normal">
<dt>0:</dt><dd>Inclusive List. Indicates that one or more
link identifiers are included in the Link Set. Each identifies a link identifiers are included in the Link Set. Each identifies a
separate link that is part of the set.</t> separate link that is part of the set.</dd>
<dt>1:</dt><dd>Inclusive Range. Indicates that the Link Set define
<t>1 - Inclusive Range indicates that the Link Set defines a s a
range of links. It contains two link identifiers. The first range of links. It contains two link identifiers. The first
identifier indicates the start of the range (inclusive). The identifier indicates the start of the range (inclusive). The
second identifier indicates the end of the range second identifier indicates the end of the range
(inclusive). All links with numeric values between the (inclusive). All links with numeric values between the
bounds are considered to be part of the set. A value of zero bounds are considered to be part of the set. A value of zero
in either position indicates that there is no bound on the in either position indicates that there is no bound on the
corresponding portion of the range.</t> corresponding portion of the range.</dd>
<dt>2-255:</dt><dd>Unassigned.</dd>
<t>2-255 - For future use</t> </dl>
<t>IANA has created a new registry to manage the Action values of the
</list> Wavelength Restriction TLV.</t>
</t>
</list>
</t>
<t>
IANA is to create a new registry to manage the Action values of the
Wavelength Restriction Constraint TLV.</t>
<t>
If PCE receives an unrecognized Action value, the PCE MUST send a
PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an
Error-value (Error-value=3). See <xref target="sect-5.2"/> for details.</t>
<t> <t>
If a PCE receives an unrecognized Action value, the PCE <bcp14>MUST</bcp14> s
end a
PCEP Error (PCErr) message with a PCEP-ERROR object with Error-Type=27 and
an Error-value=3. See <xref target="sect-5.2" format="default"/> for details.
</t>
<t>
Note that "links" are assumed to be bidirectional.</t> Note that "links" are assumed to be bidirectional.</t>
<t><list style="symbols"><t>Count (8 bits): The number of the link identi </dd>
fiers</t>
</list>
</t>
<t> <dt>Count (8 bits):</dt><dd><t>The number of the link identifiers.</t>
Note that a PCC MAY add a Wavelength restriction that applies to all <t>
Note that a PCC <bcp14>MAY</bcp14> add a Wavelength restriction that applies
to all
links by setting the Count field to zero and specifying just a set links by setting the Count field to zero and specifying just a set
of wavelengths.</t> of wavelengths.</t>
<t>
<t> Note that all link identifiers in the same list <bcp14>MUST</bcp14> be of the
Note that all link identifiers in the same list MUST be of the same same
type.</t> type.</t>
</dd>
<t><list style="hanging" hangIndent="3"> <dt>Reserved (16 bits):</dt>
<t hangText="Reserved (16 bits):"> Reserved for future use and SHOULD <dd> Reserved for future use and <bcp14>SHOULD</bcp14>
be zeroed and ignored on receipt. be zeroed and ignored on receipt.
</t> </dd>
<t hangText="Link Identifiers:"> Identifies each link ID for which <dt>Link Identifiers:</dt>
<dd> Identifies each link ID for which
restriction is applied. The length is dependent on the link format and restriction is applied. The length is dependent on the link format and
the Count field. See <xref target="sect-4.3.1"/>. for Link Identifier the Count field. See <xref target="sect-4.3.1" format="default"/> for
encoding. encoding of the Link Identifier field.
</t> </dd>
<t hangText="Wavelength Restriction:"> See Section 4.3.2. for the
Wavelength Restriction Field encoding.
</t>
</list> <dt>Wavelength Constraint:</dt>
</t> <dd> See <xref target="sect-4.3.2"/> for the encoding of the
Wavelength Constraint field.
</dd>
</dl>
<t> <t>
Various encoding errors are possible with this TLV (e.g., not Various encoding errors are possible with this TLV (e.g., not
exactly two link identifiers with the range case, unknown identifier exactly two link identifiers with the range case, unknown identifier
types, no matching link for a given identifier, etc.). To indicate types, no matching link for a given identifier, etc.).
errors associated with this encoding, a PCEP speaker MUST send a
PCErr message with Error-Type=TBD8 and Error-value=3. See <xref target="sect-
5.1"/> for the details.</t>
<section title="Link Identifier Field" anchor="sect-4.3.1"><t> To indicate
The link identifier field can be an IPv4 <xref target="RFC3630"/>, IPv6 <xref errors associated with this encoding, a PCEP speaker <bcp14>MUST</bcp14> send
target="RFC5329"/> a
or unnumbered interface ID <xref target="RFC4203"/>.</t> PCErr message with Error-Type=27 and Error-value=3. See <xref target="sect-5.
2" format="default"/> for details.</t>
<section anchor="sect-4.3.1" numbered="true" toc="default">
<name>Link Identifier Field</name>
<t>
The Link Identifier field can be an IPv4 <xref target="RFC3630"
format="default"/>, IPv6 <xref target="RFC5329" format="default"/>, or
unnumbered interface ID <xref target="RFC4203" format="default"/>.</t>
<figure><artwork><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<Link Identifier> ::= <Link Identifier> ::=
<IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID> <IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID>
]]></artwork> ]]></sourcecode>
</figure>
<t>The encoding of each case is as follows:</t>
<figure><artwork><![CDATA[
IPv4 Address Field <t>The encoding of each case is as follows.</t>
<figure anchor="fig-4.3.1-1">
<name>IPv4 Address Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 = 1 | Reserved (24 bits) | | Type = 1 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
IPv6 Address Field <figure anchor="fig-4.3.1-2">
<name>IPv6 Address Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 = 2 | Reserved (24 bits) | | Type = 2 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) | | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Unnumbered Interface ID Address Field <figure anchor="fig-4.3.1-3">
<name>Unnumbered Interface ID Address Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 = 3 | Reserved (24 bits) | | Type = 3 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Node ID (32 bits) | | TE Node ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="hanging" hangIndent="3">
<t hangText="Type (8 bits):"> It indicates the type of the link identifie
r.</t>
<t hangText="Reserved (24 bits):"> Reserved for future use and SHOULD
be zeroed and ignored on receipt.</t>
<t hangText="Link Identifier:"> When Type field is 1, 4-bytes IPv4
address is encoded; when Type field is 2, 16-bytes IPv6 address is
encoded; when Type field is 3, a tuple of 4-bytes TE node ID and
4-bytes interface ID is encoded.</t>
</list>
</t>
<t> <dl newline="false" spacing="normal" indent="3">
The Type field is extensible and matches to the IANA registry <dt>Type (8 bits):</dt>
created for Link Management Protocol (LMP) <xref target="RFC4204"/> for "TE L <dd> Indicates the type of the link identifier.</dd>
ink Object Class Type name space": <eref target="https://www.iana.org/assignment
s/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15."/> See <xref target="se
ct-8.14"/>
for the request to update the introductory text of the
aforementioned registry to note that the values have additional
usage for the Link Identifier Type field.</t>
</section> <dt>Reserved (24 bits):</dt>
<dd>Reserved for future use and <bcp14>SHOULD</bcp14>
be zeroed and ignored on receipt.</dd>
<section title="Wavelength Restriction Field" anchor="sect-4.3.2"><t> <dt>Link Identifier:</dt>
The Wavelength Restriction Field of the Wavelength Restriction <dd>When the Type field is 1, a 4-byte IPv4
Constraint TLV is encoded as a Label Set field as specified in address is encoded; when the Type field is 2, a 16-byte IPv6 address is
Section 2.6 in <xref target="RFC7579"/> with base label encoded as a 32 bit L encoded; and when the Type field is 3, a tuple of a 4-byte TE node ID and
SC a 4-byte interface ID is encoded.</dd>
label, defined in <xref target="RFC6205"/>. The Label Set format is repeated </dl>
here <t>
The Type field is extensible and matches the "TE_LINK Object Class type
name space (Value 11)" registry created for the
Link Management Protocol (LMP) <xref target="RFC4204"
format="default"/> (see <xref target="LMP-PARAM"/>). IANA has added
an introductory note before the aforementioned registry stating that the valu
es
have additional usage for the Link Identifier Type field. See <xref
target="sect-8.14" format="default"/>.</t>
</section>
<section anchor="sect-4.3.2" numbered="true" toc="default">
<name>Wavelength Constraint Field</name>
<t>
The Wavelength Constraint field of the Wavelength Restriction
TLV is encoded as a Label Set Field as specified in
<xref target="RFC7579" sectionFormat="of" section="2.6"/> with the base label
encoded as a 32-bit LSC
label, as defined in <xref target="RFC6205" format="default"/>. The Label Se
t format is repeated here
for convenience, with the base label internal structure included. for convenience, with the base label internal structure included.
See <xref target="RFC6205"/> for a description of Grid, C.S, Identifier and n See <xref target="RFC6205" format="default"/> for a description of Grid, Chan
, as nel Spacing (C.S.), Identifier, and n, and see <xref target="RFC7579" format="de
well as <xref target="RFC7579"/> for the details of each action.</t> fault"/> for the details of each action.</t>
<figure><artwork><![CDATA[ <figure anchor="fig-7.1">
<name>Wavelength Constraint Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action| Num Labels | Length | | Action| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S | Identifier | n | |Grid | C.S. | Identifier | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action | | Additional fields as necessary per action |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork> <dl newline="true" spacing="normal">
</figure>
<t> Action (4 bits):
<list>
<t>0 - Inclusive List</t>
<t>1 - Exclusive List</t>
<t>2 - Inclusive Range</t>
<t>3 - Exclusive Range</t>
<t>4 - Bitmap Set</t>
</list>
<list style="hanging" hangIndent="3">
<t hangText="Num Labels (12 bits):"> It is generally the number of <dt>Action (4 bits):</dt><dd>
labels. It has a specific meaning depending on the action value.</t>
<t hangText="Length (16 bits):"> It is the length in bytes of the entire <dl newline="false" spacing="normal">
Wavelength <dt>0:</dt><dd>Inclusive List</dd>
Restriction field.</t> <dt>1:</dt><dd>Exclusive List</dd>
<dt>2:</dt><dd>Inclusive Range</dd>
<dt>3:</dt><dd>Exclusive Range</dd>
<dt>4:</dt><dd>Bitmap Set</dd>
</dl>
</dd>
<t hangText="Identifier (9 bits):"> The Identifier is always set to <dt>Num Labels (12 bits):</dt>
0. If PCC receives the value of the identifier other than 0, it will igno <dd> It is generally the number of
re.</t> labels. It has a specific meaning depending on the action value.</dd>
</list> <dt>Length (16 bits):</dt>
</t> <dd> It is the length in bytes of the entire Wavelength
Constraint field.</dd>
<dt>Identifier (9 bits):</dt>
<dd> The Identifier is always set to
0. If PCC receives the value of the identifier other than 0, it will igno
re.</dd>
</dl>
<t> <t>
See Sections 2.6.1 - 2.6.3 of <xref target="RFC7579"/> for details on additio See Sections <xref target="RFC7579" section="2.6.1" sectionFormat="bare"/>-<x
nal ref target="RFC7579" section="2.6.3" sectionFormat="bare"/> of <xref target="RFC
7579"/> for details on additional
field discussion for each action.</t> field discussion for each action.</t>
</section>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default">
</section> <name>Signal Processing Capability Restrictions</name>
<t>
<section title="Signal Processing Capability Restrictions" anchor="sect-4 Path computation for WSON includes the checking of signal processing
.4"><t>
Path computation for WSON includes checking of signal processing
capabilities at each interface against requested capability; the PCE capabilities at each interface against requested capability; the PCE
MUST have mechanisms to know the signal processing capabilities at <bcp14>MUST</bcp14> have mechanisms to know the signal processing capabilitie
each interface, e.g. by means of the Traffic Engineering Database s at
(TED) either via IGP or Network Management System (NMS). Moreover, each interface, e.g., by means of
(TED) via either IGP or NMS. Moreover,
a PCC should be able to indicate additional restrictions to signal a PCC should be able to indicate additional restrictions to signal
processing compatibility, either on the endpoint or any given link.</t> processing compatibility, on either the endpoint or any given link.</t>
<t>
<t>
The supported signal processing capabilities considered in the RWA The supported signal processing capabilities considered in the RWA
Information Model <xref target="RFC7446"/> are: Information Model <xref target="RFC7446" format="default"/> are:
</t>
<list style="symbols"> <ul spacing="normal">
<t>Optical Interface Class List</t> <li>Optical Interface Class List</li>
<li>Bit Rate</li>
<t>Bit Rate</t> <li>Client Signal</li>
</ul>
<t>Client Signal</t> <t>
The bit rate restriction is already expressed in the BANDWIDTH object in <xre
</list> f target="RFC8779"
</t> format="default"/>.</t>
<t>
<t> In order to support the optical interface class information and the client
The Bit Rate restriction is already expressed in <xref signal information, new TLVs are introduced as endpoint restrictions in the
target="PCEP-GMPLS"/> in the BANDWIDTH object.</t> END-POINTS type Generalized Endpoint:
<t>
In order to support the Optical Interface Class information and the Client
Signal information new TLVs are introduced as endpoint-restriction in the
END-POINTS type Generalized endpoint:
<list style="symbols">
<t>Client Signal TLV</t>
<t>Optical Interface Class List TLV</t>
</list>
</t>
<t> </t>
The END-POINTS type generalized endpoint is extended as follows:</t> <ul spacing="normal">
<li>Client Signal Information TLV</li>
<li>Optical Interface Class List TLV</li>
</ul>
<t>
The END-POINTS type Generalized Endpoint is extended as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<endpoint-restriction> ::= <endpoint-restriction> ::=
<LABEL-REQUEST> <label-restriction-list> <LABEL-REQUEST> <label-restriction-list>
<label-restriction-list> ::= <label-restriction> <label-restriction-list> ::= <label-restriction>
[<label-restriction-list>] [<label-restriction-list>]
<label-restriction> ::= (<LABEL-SET>| <label-restriction> ::= (<LABEL-SET>|
[<Wavelength Restriction Constraint>] [<Wavelength Restriction>]
[<signal-compatibility-restriction>]) [<signal-compatibility-restriction>])
Where ]]></sourcecode>
<signal-compatibility-restriction> ::=
[<Optical Interface Class List>] [<Client Signal>]
]]></artwork> <t>Where:</t>
</figure>
<sourcecode type="rbnf"><![CDATA[
<signal-compatibility-restriction> ::=
[<Optical Interface Class List>] [<Client Signal Information>]
]]></sourcecode>
<t> <t>
The Wavelength Restriction Constraint TLV is defined in Section 4.3.</t> The Wavelength Restriction TLV is defined in <xref target="sect-4.3"/>.</t>
<t>
A new TLV for the Optical Interface Class List TLV (TBD5) is
defined, and the encoding of the value part of the Optical Interface
Class List TLV is described in Section 4.1 of <xref target="RFC7581"/>.</t>
<t> <t>
A new TLV for the Client Signal Information TLV (TBD6) is defined, A new Optical Interface Class List TLV (Type 11) is
and the encoding of the value part of the Client Signal Information defined; the encoding of the value part of this TLV
TLV is described in Section 4.2 of <xref target="RFC7581"/>.</t> is described in <xref target="RFC7581" sectionFormat="of" section="4.1"/>.</t
>
<t>
A new Client Signal Information TLV (Type 12) is defined;
the encoding of the value part of this
TLV is described in <xref target="RFC7581" sectionFormat="of" section="4.2"/>
.</t>
<section title="Signal Processing Exclusion" anchor="sect-4.4.1"><t> <section anchor="sect-4.4.1" numbered="true" toc="default">
<name>Signal Processing Exclusion</name>
<t>
The PCC/PCE should be able to exclude particular types of signal The PCC/PCE should be able to exclude particular types of signal
processing along the path in order to handle client restriction or processing along the path in order to handle client restriction or
multi-domain path computation. <xref target="RFC5440"/> defines how Exclude R multi-domain path computation.
oute
Object (XRO) subobject is used. In this draft, we add two new XRO
Signal Processing Exclusion Subobjects.</t>
<t>
The first XRO subobject type (TBD9) is the Optical Interface Class
List Field defined as follows:</t>
<figure title="Optical Interface Class List XRO Subobject" anchor="fig-5" <xref target="RFC5521" format="default"/> defines how the Exclude Route
><artwork><![CDATA[ Object (XRO) subobject is used. In this document, we add two new XRO
Signal Processing Exclusion subobjects.</t>
<t>
The first XRO subobject type (8) is the Optical Interface Class
List, which is defined as follows:</t>
<figure anchor="fig-5">
<name>Optical Interface Class List XRO Subobject</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBD9 | Length | Reserved | Attribute | |X| Type=8 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optical Interface Class List // // Optical Interface Class List //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Refer to <xref target="RFC5521"/> for the definition of X, Length and Attribu Refer to <xref target="RFC5521" format="default"/> for the definitions of
te.</t> X, Length, and Attribute.</t>
<dl newline="false" spacing="normal">
<t> <dt>Type (7 bits):</dt><dd>The type of the Signaling Processing Exclusion fie
Type (7 bits): The Type of the Signaling Processing Exclusion Field. ld.
The TLV Type value (TBD9) is to be assigned by the IANA for the IANA has assigned value 8 for the
Optical Interface Class List XRO Subobject Type.</t> Optical Interface Class List XRO subobject type.</dd>
<t> <dt>Reserved bits (8 bits):</dt><dd>These are for future use and <bcp14>SHOUL
Reserved bits (8 bits) are for future use and SHOULD be zeroed and D</bcp14> be zeroed and
ignored on receipt.</t> ignored on receipt.</dd>
<t> <dt>Attribute (8 bits):</dt><dd><xref target="RFC5521" format="default"/> def
The Attribute field (8 bits): <xref target="RFC5521"/> defines several Attrib ines several Attribute
ute
values; the only permitted Attribute values for this field are 0 values; the only permitted Attribute values for this field are 0
(Interface) or 1 (Node).</t> (Interface) or 1 (Node).</dd>
<t>
The Optical Interface Class List is encoded as described in Section
4.1 of <xref target="RFC7581"/>.</t>
<t> <dt>Optical Interface Class List:</dt><dd>This field is encoded as
The second XRO subobject type (TBD10) is the Client Signal described in <xref target="RFC7581" sectionFormat="of"
Information defined as follows:</t> section="4.1"/>.</dd>
</dl>
<figure title="Client Signal Information XRO Subobject" anchor="fig-6"><a <t>
rtwork><![CDATA[ The second XRO subobject type (9) is the Client Signal
Information, which is defined as follows:</t>
<figure anchor="fig-6">
<name>Client Signal Information XRO Subobject</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBD10 | Length | Reserved | Attribute | |X| Type=9 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Client Signal Information // // Client Signal Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Refer to <xref target="RFC5521"/> for the definition of X, Length and Attribu Refer to <xref target="RFC5521" format="default"/> for the definitions of
te.</t> X, Length, and Attribute.</t>
<t>Type (7 bits): The Type of the Signaling Processing Exclusion Field.
The TLV Type value (TBD10) is to be assigned by the IANA for the Client
Signal Information XRO Subobject Type.</t>
<t>Reserved bits (8 bits) are for future use and SHOULD be zeroed and
ignored on receipt.</t>
<t>The Attribute field (8 bits): [RFC5521] defines several Attribute
values; the only permitted Attribute values for this field are 0
(Interface) or 1 (Node).</t>
<t> <dl newline="false" spacing="normal">
The Client Signal Information is encoded as described in Section 4.2 <dt>Type (7 bits):</dt><dd>The type of the Signaling Processing Exclus
of <xref target="RFC7581"/>.</t> ion field.
IANA has assigned value 9 for the Client
Signal Information XRO subobject type.</dd>
<dt>Reserved bits (8 bits):</dt><dd>These are for future use and <bcp1
4>SHOULD</bcp14> be zeroed and
ignored on receipt.</dd>
<dt>Attribute (8 bits):</dt><dd><xref target="RFC5521"
format="default"/> defines several Attribute values; the only
permitted Attribute values for this field are 0 (Interface) or 1
(Node).</dd>
<t> <dt>Client Signal Information:</dt><dd>This field is encoded as described
in <xref target="RFC7581" sectionFormat="of" section="4.2"/>.</dd>
</dl>
<t>
The XRO needs to support the new Signaling Processing Exclusion XRO The XRO needs to support the new Signaling Processing Exclusion XRO
Subobject types:</t> subobject types:</t>
<ul empty="true"><li>
<figure><artwork><![CDATA[ <dl spacing="normal">
Type XRO Subobject Type
TBD9 Optical Interface Class List
TBD10 Client Signal Information
]]></artwork>
</figure>
</section> <dt>8:</dt><dd>Optical Interface Class List</dd>
<section title="Signal Processing Inclusion" anchor="sect-4.4.2"><t> <dt>9:</dt><dd>Client Signal Information</dd>
</dl>
</li></ul>
</section>
<section anchor="sect-4.4.2" numbered="true" toc="default">
<name>Signal Processing Inclusion</name>
<t>
Similar to the XRO subobject, the PCC/PCE should be able to include Similar to the XRO subobject, the PCC/PCE should be able to include
particular types of signal processing along the path in order to particular types of signal processing along the path in order to
handle client restriction or multi-domain path computation. handle client restriction or multi-domain path computation.
<xref target="RFC5440"/> defines how Include Route Object (IRO) subobject is <xref target="RFC5440" format="default"/> defines how the Include Route Objec
used. t (IRO) subobject is used.
In this draft, we add two new Signal Processing Inclusion In this document, we add two new Signal Processing Inclusion
Subobjects.</t> subobjects.</t>
<t>
<t> The IRO needs to support the new IRO subobject types (8 and
The IRO needs to support the new IRO Subobject types (TBD11 and 9) for the PCEP IRO object <xref target="RFC5440" format="default"/>:</t>
TBD12) for the PCEP IRO object <xref target="RFC5440"/>:</t> <ul empty="true"><li>
<dl>
<figure><artwork><![CDATA[
Type IRO Subobject Type
TBD11 Optical Interface Class List
TBD12 Client Signal Information <dt>8:</dt><dd>Optical Interface Class List</dd>
]]></artwork>
</figure>
<t> <dt>9:</dt><dd>Client Signal Information</dd>
</dl>
</li></ul>
<t>
The encoding of the Signal Processing Inclusion subobjects is The encoding of the Signal Processing Inclusion subobjects is
similar to <xref target="sect-4.4.1"/> where the 'X' field is replaced with ' similar to the process in <xref target="sect-4.4.1" format="default"/> where
L' the 'X' field is replaced with the 'L'
field, all the other fields remains the same. The 'L' field is field; all the other fields remain the same. The 'L' field is
described in <xref target="RFC3209"/>.</t> described in <xref target="RFC3209" format="default"/>.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Encoding of an RWA Path Reply</name>
</section> <t>
This section provides the encoding of an RWA Path Reply for a
<section title="Encoding of a RWA Path Reply" anchor="sect-5"><t> wavelength allocation request as discussed in <xref target="sect-4" format="d
This section provides the encoding of a RWA Path Reply for efault"/>.</t>
wavelength allocation request as discussed in <xref target="sect-4"/>.</t> <section anchor="sect-5.1" numbered="true" toc="default">
<name>Wavelength Allocation TLV</name>
<section title="Wavelength Allocation TLV" anchor="sect-5.1"><t> <t>
Recall that wavelength allocation can be performed by the PCE by Recall that wavelength allocation can be performed by the PCE by
different means:</t> means of:</t>
<ol spacing="normal" type="(%c)">
<t><list style="format (%c)"> <li>Explicit Label Control (ELC) where the PCE allocates
which label to use for each interface/node along the path.</li>
<t>By means of Explicit Label Control (ELC) where the PCE allocates <li>A Label Set where the PCE provides a range of potential
which label to use for each interface/node along the path.</t> labels to be allocated by each node along the path.</li>
</ol>
<t>By means of a Label Set where the PCE provides a range of potential <t>
labels to allocate by each node along the path.</t>
</list>
</t>
<t>
Option (b) allows distributed label allocation (performed during Option (b) allows distributed label allocation (performed during
signaling) to complete wavelength allocation.</t> signaling) to complete wavelength allocation.</t>
<t>
<t> The type for the Wavelength Allocation TLV is 10 (see <xref target="sect-8.4"
The Wavelength Allocation TLV type is TBD4 (See <xref target="sect-8.4"/>). N format="default"/>). Note
ote that this TLV is used for both (a) and (b) above. The TLV data is defined
that this TLV is used for both (a) and (b). The TLV data is defined
as follows:</t> as follows:</t>
<figure anchor="fig-7.2">
<figure title="Wavelength Allocation TLV Encoding" anchor="fig-7"><artwor <name>Wavelength Allocation TLV Encoding</name>
k><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | Flag |M| | Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier Field | | Link Identifier |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocated Wavelength(s) | | Allocated Wavelength(s) |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols">
<t>Reserved (16 bits): Reserved for future use.</t>
<t>Flags (16 bits)</t>
</list>
</t>
<t>
One flag bit is allocated as follows:
<list>
<t>M (Mode): 1 bit</t>
<t>0 indicates the allocation is under Explicit Label Control.</t>
<t>1 indicates the allocation is expressed in Label Sets.</t>
</list>
</t>
<t>
IANA is to create a new registry to manage the Flag field (TBD14) of
the Wavelength Allocation TLV.</t>
<t>
Note that all link identifiers in the same list must be of the same
type.
<list style="hanging" hangIndent="3"> <dl newline="false" spacing="normal">
<t hangText="Link Identifier:"> Identifies the interface to which
assignment wavelength(s) is applied. See <xref
target="sect-4.3.1"/>. for Link Identifier encoding.</t>
<t hangText="Allocated Wavelength(s):"> Indicates the allocated <dt>Reserved (16 bits):</dt><dd>Reserved for future use.</dd>
wavelength(s) to be associated with the Link Identifier. See <xref <dt>Flags field (16 bits):</dt><dd><t>One flag bit is allocated as fol
target="sect-4.3.2"/> for encoding details.</t> lows:</t>
</list> <dl newline="false" spacing="normal">
</t> <dt>M (1 bit):</dt><dd><t>Wavelength Allocation Mode.</t>
<dl newline="false" spacing="normal">
<dt>0:</dt><dd>Indicates the allocation relies on the use of Label
Sets.</dd>
<dt>1:</dt><dd>Indicates the allocation is done using Explicit Lab
el Control.</dd>
<t> </dl>
This TLV is carried in a PCRep message as an attribute TLV <xref target="RFC5 </dd></dl>
420"/> <t>IANA has created a new registry to manage the Flags field
in the Hop Attribute Subobjects <xref target="RFC7570"/> in the ERO <xref tar of the Wavelength Allocation TLV.</t>
get="RFC5440"/>.</t> </dd>
</section> <dt>Link Identifier:</dt><dd>Identifies the interface to which the
assignment wavelength(s) is applied. See <xref target="sect-4.3.1"
format="default"/> for encoding of the Link Identifier field.</dd>
<dt>Allocated Wavelength(s):</dt>
<dd> Indicates the allocated wavelength(s) to be associated with the
link identifier. See <xref target="sect-4.3.2" format="default"/>
for encoding details.</dd>
</dl>
<section title="Error Indicator" anchor="sect-5.2"><t> <t>
To indicate errors associated with the RWA request, a new Error Type This TLV is carried in a PCRep message as an Attribute TLV <xref target="RFC5
(TBD8) and subsequent error-values are defined as follows for 420" format="default"/>
inclusion in the PCEP-ERROR Object:</t> in the Hop Attribute subobjects <xref target="RFC7570" format="default"/> in
the Explicit Route Object (ERO) <xref target="RFC5440" format="default"/>.</t>
<t> </section>
A new Error-Type (TBD8) and subsequent error-values are defined as
follows:
<list style="symbols"> <section anchor="sect-5.2" numbered="true" toc="default">
<name>Error Indicator</name>
<t>
To indicate errors associated with the RWA request, a new Error-Type
27 (WSON RWA Error) and subsequent Error-values are defined as follows for
inclusion in the PCEP-ERROR object:</t>
<t>Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request and the PCE <ul spacing="normal">
is not capable of processing the request due to insufficient memory, the <li>Error-Type=27; Error-value=1: If a PCE receives an RWA request
PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and the PCE is not capable of processing the request due to
and an Error-value (Error- value=1). The PCE stops processing the insufficient memory, the PCE <bcp14>MUST</bcp14> send a PCErr
request. The corresponding RWA request MUST be cancelled at the PCC.</t> message with a PCEP-ERROR object with Error-Type=27 and
Error-value=1. The PCE stops processing the request.
The corresponding RWA request <bcp14>MUST</bcp14> be canceled at the
PCC.</li>
<t>Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request and the PCE <li>Error-Type=27; Error-value=2: If a PCE receives an RWA request and
is not capable of RWA computation, the PCE MUST send a PCErr message the PCE
with a PCEP-ERROR Object (Error-Type=TBD8) and an Error-value is not capable of RWA computation, the PCE <bcp14>MUST</bcp14> send a PCErr m
(Error-value=2). The PCE stops processing the request. The essage
corresponding RWA computation MUST be cancelled at the PCC.</t> with a PCEP-ERROR object with Error-Type=27 and
Error-value=2. The PCE stops processing the request. The
corresponding RWA computation <bcp14>MUST</bcp14> be canceled at the PCC.</li
>
<t>Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request and there <li>Error-Type=27; Error-value=3: If a PCE receives an RWA request and there
are syntactical encoding errors (e.g., not exactly two link identifiers are syntactical encoding errors (e.g., not exactly two link identifiers
with the range case, unknown identifier types, no matching link for a with the range case, unknown identifier types, no matching link for a
given identifier, unknown Action value, etc.), the PCE MUST send a PCErr given identifier, unknown Action value, etc.), the PCE <bcp14>MUST</bcp14> se
message with a PCEP- ERROR Object (Error-Type=TBD8) and an Error-value nd a PCErr
(Error- value=3).</t> message with a PCEP-ERROR object with Error-Type=27 and Error-value=3.</li>
</list> </ul>
</t> </section>
</section> <section anchor="sect-5.3" numbered="true" toc="default">
<name>NO-PATH Indicator</name>
<section title="NO-PATH Indicator" anchor="sect-5.3"><t> <t>
To communicate the reason(s) for not being able to find RWA for the To communicate the reason(s) for not being able to find RWA for the
path request, the NO-PATH object can be used in the corresponding path request, the NO-PATH object can be used in the corresponding
response. The format of the NO-PATH object body is defined in response. The format of the NO-PATH object body is defined in
<xref target="RFC5440"/>. The object may contain a NO-PATH-VECTOR TLV to pro vide <xref target="RFC5440" format="default"/>. The object may contain a NO-PATH- VECTOR TLV to provide
additional information about why a path computation has failed.</t> additional information about why a path computation has failed.</t>
<t>
This document defines a new bit flag to be carried in the Flags field in the
NO-PATH-VECTOR TLV, which is carried in the NO-PATH object:</t>
<t> <dl newline="false" spacing="normal" indent="3">
One new bit flag is defined to be carried in the Flags field in the <dt>Bit 23:</dt>
NO-PATH-VECTOR TLV carried in the NO-PATH Object.</t> <dd> When set, the PCE indicates no feasible
<t><list style="hanging" hangIndent="3">
<t hangText="Bit TBD7:"> When set, the PCE indicates no feasible
route was found that meets all the constraints (e.g., wavelength route was found that meets all the constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with RWA. restriction, signal compatibility, etc.) associated with RWA.
</t> </dd>
</dl>
</list>
</t>
</section>
</section>
<section title="Manageability Considerations" anchor="sect-6"><t>
Manageability of WSON Routing and Wavelength Assignment (RWA) with
PCE must address the following considerations:</t>
<section title="Control of Function and Policy" anchor="sect-6.1"><t> </section>
In addition to the parameters already listed in Section 8.1 of </section>
<xref target="RFC5440"/>, a PCEP implementation SHOULD allow configuration of <section anchor="sect-6" numbered="true" toc="default">
the <name>Manageability Considerations</name>
<t>
Manageability of WSON RWA with
PCE must address the considerations in the following subsections.</t>
<section anchor="sect-6.1" numbered="true" toc="default">
<name>Control of Function and Policy</name>
<t>
In addition to the parameters already listed in <xref target="RFC5440" sectio
nFormat="of" section="8.1"/>, a PCEP implementation <bcp14>SHOULD</bcp14> allow
configuration of the
following PCEP session parameters on a PCC:</t> following PCEP session parameters on a PCC:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The ability to send a WSON RWA request.</li>
<t>The ability to send a WSON RWA request.</t> </ul>
<t>
</list> In addition to the parameters already listed in <xref target="RFC5440" sectio
</t> nFormat="of" section="8.1"/>, a PCEP implementation <bcp14>SHOULD</bcp14> allow
configuration of the
<t>
In addition to the parameters already listed in Section 8.1 of
<xref target="RFC5440"/>, a PCEP implementation SHOULD allow configuration of
the
following PCEP session parameters on a PCE:</t> following PCEP session parameters on a PCE:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The support for WSON RWA.</li>
<t>The support for WSON RWA.</t> <li>A set of WSON-RWA-specific policies (authorized sender, request
rate limiter, etc).</li>
<t>A set of WSON RWA specific policies (authorized sender, request </ul>
rate limiter, etc).</t> <t>
</list>
</t>
<t>
These parameters may be configured as default parameters for any These parameters may be configured as default parameters for any
PCEP session the PCEP speaker participates in, or may apply to a PCEP session the PCEP speaker participates in, or they may apply to a
specific session with a given PCEP peer or a specific group of specific session with a given PCEP peer or a specific group of
sessions with a specific group of PCEP peers.</t> sessions with a specific group of PCEP peers.</t>
</section>
</section> <section anchor="sect-6.2" numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<section title="Liveness Detection and Monitoring" anchor="sect-6.2"><t> <t>
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements, aside from those already
listed in section 8.3 of <xref target="RFC5440"/>.</t> listed in <xref target="RFC5440" sectionFormat="of" section="8.3"/>.</t>
</section>
</section> <section anchor="sect-6.3" numbered="true" toc="default">
<name>Verifying Correct Operation</name>
<section title="Verifying Correct Operation" anchor="sect-6.3"><t> <t>
Mechanisms defined in this document do not imply any new Mechanisms defined in this document do not imply any new
verification requirements in addition to those already listed in verification requirements, aside from those already listed in
section 8.4 of <xref target="RFC5440"/></t> <xref target="RFC5440" sectionFormat="of" section="8.4"/>.</t>
</section>
</section> <section anchor="sect-6.4" numbered="true" toc="default">
<name>Requirements on Other Protocols and Functional Components</name>
<section title="Requirements on Other Protocols and Functional Components <t>
" anchor="sect-6.4"><t> The PCEP Link-State mechanism <xref target="I-D.lee-pce-pcep-ls-optical" form
The PCEP Link-State mechanism <xref target="PCEP-LS"/> may be used to adverti at="default"/> may be used to advertise
se
WSON RWA path computation capabilities to PCCs.</t> WSON RWA path computation capabilities to PCCs.</t>
</section>
</section> <section anchor="sect-6.5" numbered="true" toc="default">
<name>Impact on Network Operation</name>
<section title="Impact on Network Operation" anchor="sect-6.5"><t> <t>
Mechanisms defined in this document do not imply any new network Mechanisms defined in this document do not imply any new network
operation requirements in addition to those already listed in operation requirements, aside from those already listed in
section 8.6 of <xref target="RFC5440"/>.</t> <xref target="RFC5440" sectionFormat="of" section="8.6"/>.</t>
</section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>
<section title="Security Considerations" anchor="sect-7"><t> The security considerations discussed in <xref target="RFC5440" format="defau
The security considerations discussed in <xref target="RFC5440"/> are relevan lt"/> are relevant for
t for this document; this document does not introduce any new security
this document, this document does not introduce any new security issues. If an operator wishes to keep the information
issues. If an operator wishes to keep private the information distributed by WSON private, PCEPS (Usage of TLS to Provide a Secure Transpor
distributed by WSON, PCEPS <xref target="RFC8253"/> SHOULD be used.</t> t for PCEP) <xref target="RFC8253" format="default"/> <bcp14>SHOULD</bcp14> be u
sed.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default">
<section title="IANA Considerations" anchor="sect-8"><t> <name>IANA Considerations</name>
<t>
IANA maintains a registry of PCEP parameters. IANA has made IANA maintains a registry of PCEP parameters. IANA has made
allocations from the sub-registries as described in the following allocations from the subregistries as described in the following
sections.</t> sections.</t>
<section anchor="sect-8.1" numbered="true" toc="default">
<name>New PCEP Object: Wavelength Assignment Object</name>
<t>
As described in <xref target="sect-4.1" format="default"/>, a new PCEP
object is defined to carry wavelength-assignment-related constraints. IANA
has allocated the following in the "PCEP Objects" subregistry <xref
target="PCEP-NUMBERS"/>:</t>
<section title="New PCEP Object: Wavelength Assignment Object" anchor="se <table align="left">
ct-8.1"><t> <thead>
As described in <xref target="sect-4.1"/>, a new PCEP Object is defined to ca <tr>
rry <th>Object-Class Value</th>
wavelength assignment related constraints. IANA is to allocate the <th>Name</th>
following from "PCEP Objects" sub-registry <th>Object-Type</th>
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects"/ <th>Reference</th>
>):</t> </tr>
</thead>
<figure><artwork><![CDATA[ <tbody>
Object Class Name Object Reference <tr>
Value Type <td>42</td>
<td>WA</td>
TBD1 WA 1: Wavelength Assignment [This.I-D] <td>0: Reserved</td>
]]></artwork> <td>RFC 8780</td>
</figure> </tr>
</section> <tr>
<td></td>
<section title="WA Object Flag Field" anchor="sect-8.2"><t> <td></td>
As described in <xref target="sect-4.1"/>, IANA is to create a registry to ma <td>1: Wavelength Assignment</td>
nage <td>RFC 8780</td>
the Flag field of the WA object. New values are to be assigned by </tr>
Standards Action <xref target="RFC8126"/>. Each bit should be tracked with th </tbody>
e </table>
following qualities:</t> </section>
<section anchor="sect-8.2" numbered="true" toc="default">
<t><list style="symbols"> <name>WA Object Flag Field</name>
<t>
<t>Bit number (counting from bit 0 as the most significant bit)</t> As described in <xref target="sect-4.1" format="default"/>, IANA has
created the "WA Object Flag Field" subregistry under the "Path Computation
<t>Capability description</t> Element Protocol (PCEP) Numbers" registry <xref target="PCEP-NUMBERS"/> to
manage the Flags field of the WA object. New values are to be assigned by
<t>Defining RFC</t> Standards Action <xref target="RFC8126" format="default"/>. Each bit should
</list>
</t>
<t>
The following values are defined in this document:</t>
<t>
One bit is defined for the WA Object flag in this document:</t>
<t>
Codespace of the Flag field (WA Object)</t>
<figure><artwork><![CDATA[
Bit Description Reference
0-14 Unassigned [This.I-D]
15 Explicit Label Control [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Selection TLV" anchor="sect-8.3"
><t>
As described in <xref target="sect-4.2"/>, a new PCEP TLV is defined to indic
ate
wavelength selection constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators"/>).</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD2 Wavelength Selection [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Restriction Constraint TLV" anch
or="sect-8.4"><t>
As described in <xref target="sect-4.3"/>, a new PCEP TLV is defined to indic
ate
wavelength restriction constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry
(<eref
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat
ors"/>).
</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD3 Wavelength Restriction [This.I-D]
Constraint
]]></artwork>
</figure>
</section>
<section title="Wavelength Restriction Constraint TLV Action Values" anch
or="sect-8.5"><t>
As described in <xref target="sect-4.3"/>, IANA is to allocate a new registry
to
manage the Action values of the Action field in the Wavelength
Restriction Constraint TLV. New values are assigned by Standards
Action <xref target="RFC8126"/>. Each value should be tracked with the follow
ing
qualities: value, meaning, and defining RFC. The following values
are defined in this document:</t>
<figure><artwork><![CDATA[
Value Meaning Reference
0 Inclusive List [This.I-D]
1 Inclusive Range [This.I-D]
2-255 Reserved [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Allocation TLV" anchor="sect-8.6
"><t>
As described in <xref target="sect-5.1"/>, a new PCEP TLV is defined to indic
ate
the allocation of wavelength(s) by the PCE in response to a request
by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type Indicato
rs" subregistry
(<eref
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat
ors"/>).
</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD4 Wavelength Allocation [This.I-D]
]]></artwork>
</figure>
</section>
<section title="Wavelength Allocation TLV Flag Field" anchor="sect-8.7"><
t>
As described in <xref target="sect-5.1"/>, IANA is to allocate a registry to
manage the Flag field of the Wavelength Allocation TLV. New values
are to be assigned by Standards Action <xref target="RFC8126"/>. Each bit sh
ould
be tracked with the following qualities:</t> be tracked with the following qualities:</t>
<ul spacing="normal">
<li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li>
<li>Defining RFC</li>
</ul>
<t><list style="symbols"> <t>The initial contents of this registry are shown below. One bit has be
en
<t>Bit number (counting from bit 0 as the most significant bit)</t> allocated for the flag defined in this document:</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list> <table align="left">
</t> <thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-14</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>15</td>
<td>Wavelength Allocation Mode</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.3" numbered="true" toc="default">
<name>New PCEP TLV: Wavelength Selection TLV</name>
<t>
In <xref target="sect-4.2" format="default"/>, a new PCEP TLV is defined to
indicate wavelength selection constraints. IANA has made the following
allocation in the "PCEP TLV Type Indicators" subregistry <xref
target="PCEP-NUMBERS"/>:</t>
<t> <table align="left">
One bit is defined for the Wavelength Allocation flag in this - <thead>
document:</t> <tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>8</td>
<td>Wavelength Selection</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<t> <section anchor="sect-8.4" numbered="true" toc="default">
Codespace of the Flag field (Wavelength Allocation TLV)</t> <name>New PCEP TLV: Wavelength Restriction TLV</name>
<t>
In <xref target="sect-4.3" format="default"/>, a new PCEP TLV is defined to i
ndicate
wavelength restrictions. IANA has made the following allocation in
the "PCEP TLV Type Indicators" subregistry <xref target="PCEP-NUMBERS"/>:
</t>
<figure><artwork><![CDATA[ <table align="left">
Bit Description Reference <thead>
0-14 Unassigned [This.I-D] <tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>9</td>
<td>Wavelength Restriction</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.5" numbered="true" toc="default">
<name>Wavelength Restriction TLV Action Values</name>
<t>
As described in <xref target="sect-4.3" format="default"/>, IANA has
created the new "Wavelength Restriction TLV Action Values"
subregistry under the "Path Computation Element Protocol (PCEP) Numbers" regi
stry
<xref target="PCEP-NUMBERS"/> to
manage the Action values of the Action field of the Wavelength
Restriction TLV. New values are assigned by Standards
Action <xref target="RFC8126" format="default"/>. Each value should be tracke
d with the following
qualities: </t>
<ul spacing="normal">
<li>Value</li>
<li>Meaning</li>
<li>Defining RFC</li>
</ul>
15 Wavelength Allocation Mode [This.I-D] <t>The initial contents of this registry are shown below:</t>
]]></artwork>
</figure>
</section> <table align="left">
<thead>
<tr>
<th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Inclusive List</td>
<td>RFC 8780</td>
</tr>
<tr>
<td>1</td>
<td>Inclusive Range</td>
<td>RFC 8780</td>
</tr>
<tr>
<td>2-255</td>
<td>Unassigned</td>
<td></td>
</tr>
</tbody>
</table>
</section>
<section title="New PCEP TLV: Optical Interface Class List TLV" anchor="s <section anchor="sect-8.6" numbered="true" toc="default">
ect-8.8"><t> <name>New PCEP TLV: Wavelength Allocation TLV</name>
As described in <xref target="sect-4.4"/>, a new PCEP TLV is defined to indic <t>
ate In <xref target="sect-5.1" format="default"/>, a new PCEP TLV
the optical interface class list. IANA is to allocate this new TLV is defined to indicate the allocation of the wavelength(s) by the PCE in
from the "PCEP TLV Type Indicators" subregistry response to a request by the PCC. IANA has made the following allocation in
(<eref "PCEP TLV Type Indicators" subregistry <xref target="PCEP-NUMBERS"/>:
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat </t>
ors"/>). <table align="left">
</t> <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>10</td>
<td>Wavelength Allocation</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<figure><artwork><![CDATA[ <section anchor="sect-8.7" numbered="true" toc="default">
Value Description Reference <name>Wavelength Allocation TLV Flag Field</name>
TBD5 Optical Interface [This.I-D] <t>
Class List As described in <xref target="sect-5.1" format="default"/>, IANA has
]]></artwork> created a new "Wavelength Allocation TLV Flag Field" subregistry under the
</figure> "Path Computation Element Protocol (PCEP) Numbers" registry <xref
</section> target="PCEP-NUMBERS"/> to
manage the Flags field of the Wavelength Allocation TLV. New values
are to be assigned by Standards Action <xref target="RFC8126" format="default
"/>. Each bit should
be tracked with the following qualities:</t>
<ul spacing="normal">
<li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li>
<li>Defining RFC</li>
</ul>
<section title="New PCEP TLV: Client Signal TLV" anchor="sect-8.9"><t> <t>One bit is defined for the flag defined in this
As described in <xref target="sect-4.4"/>, a new PCEP TLV is defined to indic document. The initial contents of this registry are shown below:</t>
ate
the client signal information. IANA is to allocate this new TLV from
the "PCEP TLV Type Indicators" subregistry
(<eref
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat
ors"/>).
</t>
<figure><artwork><![CDATA[ <table align="left">
Value Description Reference <thead>
TBD6 Client Signal Information [This.I-D] <tr>
]]></artwork> <th>Bit</th>
</figure> <th>Description</th>
</section> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-14</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>15</td>
<td>Wavelength Allocation Mode</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.8" numbered="true" toc="default">
<name>New PCEP TLV: Optical Interface Class List TLV</name>
<t>
In <xref target="sect-4.4" format="default"/>, a new PCEP TLV is defined to
indicate the Optical Interface Class List. IANA has made the following
allocation in the "PCEP TLV Type Indicators" subregistry <xref
target="PCEP-NUMBERS"/>:
</t>
<table align="left">
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>11</td>
<td>Optical Interface Class List</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.9" numbered="true" toc="default">
<name>New PCEP TLV: Client Signal Information TLV</name>
<t>
In <xref target="sect-4.4" format="default"/>, a new PCEP TLV is defined to
indicate the Client Signal Information. IANA has made the following
allocation in the "PCEP TLV Type Indicators" subregistry <xref
target="PCEP-NUMBERS"/>:
</t>
<table align="left">
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>12</td>
<td>Client Signal Information</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section title="New No-Path Reasons" anchor="sect-8.10"><t> <section anchor="sect-8.10" numbered="true" toc="default">
As described in <xref target="sect-5.3"/>, a new bit flag are defined to be <name>New Bit Flag for NO-PATH-VECTOR TLV</name>
carried in the Flags field in the NO-PATH-VECTOR TLV carried in the <t>
NO-PATH Object. This flag, when set, indicates that no feasible In <xref target="sect-5.3" format="default"/>, a new bit flag is defined to b
e
carried in the Flags field in the NO-PATH-VECTOR TLV, which is carried in the
NO-PATH object. This flag, when set, indicates that no feasible
route was found that meets all the RWA constraints (e.g., wavelength route was found that meets all the RWA constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with a RWA path restriction, signal compatibility, etc.) associated with an RWA path
computation request.</t> computation request.</t>
<t>
IANA has made the following allocation for this new bit flag in the
"NO-PATH-VECTOR TLV Flag Field" subregistry <xref target="PCEP-NUMBERS"/>:
</t>
<table align="left">
<thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>23</td>
<td>No RWA constraints met</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<t> <section anchor="sect-8.11" numbered="true" toc="default">
IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR TLV Flag <name>New Error-Types and Error-Values</name>
Field" subregistry <t>
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector In <xref target="sect-5.2" format="default"/>, new PCEP error
-tlv"/>).</t> codes are defined for WSON RWA errors. IANA has made the following allocation
s
<figure><artwork><![CDATA[ in the "PCEP-ERROR Object Error Types and Values" subregistry <xref
Bit Description Reference target="PCEP-NUMBERS"/>:</t>
TBD7 No RWA constraints met [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New Error-Types and Error-Values" anchor="sect-8.11"><t>
As described in <xref target="sect-5.2"/>, new PCEP error codes are defined f
or
WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object
Error Types and Values" sub-registry (<eref target="http://www.iana.org/assig
nments/pcep/pcep.xhtml#pcep-error-object"/>).</t>
<figure><artwork><![CDATA[
Error- Meaning Error-Value Reference
Type
TBD8 WSON RWA Error 0: Unassigned [This.I-D]
1: Insufficient [This.I-D]
Memory
2: RWA computation [This.I-D]
Not supported
3: Syntactical [This.I-D]
Encoding error
4-255: Unassigned [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New Subobjects for the Exclude Route Object" anchor="sect
-8.12"><t>
As described in <xref target="sect-4.4.1"/>, the "PCEP Parameters" registry
contains a subregistry "PCEP Objects" with an entry for the Exclude
Route Object (XRO). IANA is requested to add further subobjects that
can be carried in the XRO as follows:</t>
<figure><artwork><![CDATA[
Subobject Type Reference
TBD9 Optical Interface Class List [This.I-D]
TBD10 Client Signal Information [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New Subobjects for the Include Route Object" anchor="sect
-8.13"><t>
As described in <xref target="sect-4.4.2"/>, the "PCEP Parameters" registry
contains a subregistry "PCEP Objects" with an entry for the Include
Route Object (IRO). IANA is requested to add further subobjects that
can be carried in the IRO as follows:</t>
<figure><artwork><![CDATA[
Subobject Type Reference
TBD11 Optical Interface Class List [This.I-D]
TBD12 Client Signal Information [This.I-D] <table align="left">
]]></artwork> <thead>
</figure> <tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>27</td>
<td>WSON RWA error</td>
<td>0: Unassigned</td>
<td>RFC 8780</td>
</tr>
<tr>
<td></td>
<td></td>
<td>1: Insufficient memory</td>
<td>RFC 8780</td>
</tr>
<tr>
<td></td>
<td></td>
<td>2: RWA computation not supported</td>
<td>RFC 8780</td>
</tr>
<tr>
<td></td>
<td></td>
<td>3: Syntactical encoding error</td>
<td>RFC 8780</td>
</tr>
<tr>
<td></td>
<td></td>
<td>4-255: Unassigned</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
</section> <section anchor="sect-8.12" numbered="true" toc="default">
<name>New Subobjects for the Exclude Route Object</name>
<t>The "Path Computation Element Protocol (PCEP) Numbers" registry
contains a subregistry titled "XRO Subobjects" <xref
target="PCEP-NUMBERS"/>. Per <xref target="sect-4.4.1"
format="default"/>, IANA has added the following subobjects that can
be carried in the XRO:</t>
<section title="Request for Updated Note for LMP TE Link Object Class Typ <table align="left">
e" anchor="sect-8.14"><t> <thead>
As discussed in <xref target="sect-4.3.1"/>, the registry created for Link <tr>
Management Protocol (LMP) <xref target="RFC4204"/> for "TE Link Object Class <th>Value</th>
Type name space": <eref target="https://www.iana.org/assignments/lmp-parameters/ <th>Description</th>
lmp-parameters.xhtml#lmp-parameters-15"/> is requested for the updated <th>Reference</th>
introductory note that the values have additional usage for the Link </tr>
Identifier Type field.</t> </thead>
<tbody>
<tr>
<td>8</td>
<td>Optical Interface Class List</td>
<td>RFC 8780</td>
</tr>
<tr>
<td>9</td>
<td>Client Signal Information</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.13" numbered="true" toc="default">
<name>New Subobjects for the Include Route Object</name>
<t>
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a
subregistry titled "IRO Subobjects" <xref target="PCEP-NUMBERS"/>. Per <xref
target="sect-4.4.2" format="default"/>, IANA has added the following
subobjects that can be carried in the IRO:</t>
</section> <table align="left">
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>8</td>
<td>Optical Interface Class List</td>
<td>RFC 8780</td>
</tr>
<tr>
<td>9</td>
<td>Client Signal Information</td>
<td>RFC 8780</td>
</tr>
</tbody>
</table>
</section>
</section> <section anchor="sect-8.14" numbered="true" toc="default">
<name>Request for Updated Note for LMP TE Link Object Class Type</name>
<t>
The "TE_LINK Object Class type name space (Value 11)" registry was created
for the Link Management Protocol (LMP) <xref target="RFC4204"
format="default"/>. As discussed in <xref target="sect-4.3.1"
format="default"/>, IANA has added the following note at the top of the
"TE_LINK Object Class type name space (Value 11)" registry <xref
target="LMP-PARAM"/>:
</t>
<section title="Acknowledgments" anchor="sect-9"><t> <ul empty="true">
The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv <li>
Dhody and Benjamin Kaduk for many helpful comments that greatly These values have additional usage for the Link Identifier Type field.
improved the contents of this draft.</t> </li>
</ul>
</section> </section>
</section>
</middle>
<back>
</middle> <displayreference target="I-D.lee-pce-pcep-ls-optical" to="PCEP-LS"/>
<back> <references>
<references title="Normative References"> <name>References</name>
&RFC2119; <references>
&RFC3209; <name>Normative References</name>
&RFC3630; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC5329; ence.RFC.2119.xml"/>
&RFC5440; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC6205; ence.RFC.3209.xml"/>
&RFC7570; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7579; ence.RFC.3630.xml"/>
&RFC7581; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7689; ence.RFC.5329.xml"/>
&RFC7688; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8174; ence.RFC.5440.xml"/>
&RFC8253; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6205.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7570.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7579.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7581.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7689.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7688.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8253.xml"/>
<reference anchor='PCEP-GMPLS'> <!-- draft-ietf-pce-gmpls-pcep-extensions-16; C385 companion doc - ready for Pub
-->
<reference anchor='RFC8779' target="https://www.rfc-editor.org/info/rfc8779">
<front> <front>
<title>PCEP extensions for GMPLS</title> <title>Path Computation Element Communication Protocol (PCEP) Extensions for GMP
LS</title>
<author initials='C' surname='Margaria' fullname='Cyril Margaria'> <author initials='C' surname='Margaria' fullname='Cyril Margaria' role="editor">
<organization /> <organization />
</author> </author>
<author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de
<author initials='O' surname='Dios' fullname='Oscar de Dios'> Dios' role="editor">
<organization /> <organization />
</author> </author>
<author initials='F' surname='Zhang' fullname='Fatai Zhang' role="editor">
<author initials='F' surname='Zhang' fullname='Fatai Zhang'>
<organization /> <organization />
</author> </author>
<date month='July' year='2020' />
<date month='December' day='12' year='2019' />
<abstract><t>A Path Computation Element (PCE) provides path computation function
s for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks
. Additional requirements for GMPLS are identified in RFC7025. This memo provi
des extensions to the Path Computation Element communication Protocol (PCEP) for
the support of the GMPLS control plane to address those requirements.</t></abst
ract>
</front> </front>
<seriesInfo name="RFC" value="8779"/>
<seriesInfo name='Work in Progress,' value='draft-ietf-pce-gmpls-pcep-extensions <seriesInfo name="DOI" value="10.17487/RFC8779"/>
-16' />
</reference> </reference>
</references> </references>
<references title="Informative References"> <references>
&RFC3471; <name>Informative References</name>
&RFC4203; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC4204; ence.RFC.3471.xml"/>
&RFC4655; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC5420; ence.RFC.4203.xml"/>
&RFC5521; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC6163; ence.RFC.4204.xml"/>
&RFC6566; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7446; ence.RFC.4655.xml"/>
&RFC7449; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8126; ence.RFC.5420.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor='PCEP-LS'> ence.RFC.5521.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>PCEP Extension for Distribution of Link-State and TE information for Opti ence.RFC.6163.xml"/>
cal Networks</title> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6566.xml"/>
<author initials='Y' surname='Lee' fullname='Young Lee'> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization /> ence.RFC.7446.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7449.xml"/>
<author initials='H' surname='Zheng' fullname='Haomian Zheng'> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization /> ence.RFC.8126.xml"/>
</author>
<author initials='D' surname='Ceccarelli' fullname='Daniele Ceccarelli'>
<organization />
</author>
<author initials='W' surname='Wang' fullname='Wei Wang'>
<organization />
</author>
<author initials='P' surname='Park' fullname='Peter Park'>
<organization />
</author>
<author initials='B' surname='Yoon' fullname='Bin-Yeong Yoon'>
<organization />
</author>
<date month='September' day='2' year='2019' />
<abstract><t>In order to compute and provide optimal paths, Path Computation Ele <!--draft-lee-pce-pcep-ls-optical-08; IESG state, I-D Exists -->
ments (PCEs) require an accurate and timely Traffic Engineering Database (TED). <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.lee-pce-
Traditionally this Link State and TE information has been obtained from a link s pcep-ls-optical.xml"/>
tate routing protocol (supporting traffic engineering extensions). This documen
t extends the Path Communication Element Communication Protocol (PCEP) with Link
-State and TE information for optical networks.</t></abstract>
</front> <reference anchor="PCEP-NUMBERS"
target="https://www.iana.org/assignments/pcep/">
<front>
<title>Path Computation Element Protocol (PCEP) Numbers</title>
<author><organization>IANA</organization></author>
</front>
</reference>
<seriesInfo name='Work in Progress,' value='draft-lee-pce-pcep-ls-optical-08' /> <reference anchor="LMP-PARAM"
target="https://www.iana.org/assignments/lmp-parameters/">
<front>
<title>Link Management Protocol (LMP) Parameters</title>
<author><organization>IANA</organization></author>
</front>
</reference> </reference>
</references> </references>
<section title="Contributors" anchor="sect-11"><figure><artwork><![CDATA[ </references>
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Cyril Margaria <section anchor="sect-9" numbered="false" toc="default">
Nokia Siemens Networks <name>Acknowledgments</name>
St Martin Strasse 76 <t>
Munich, 81541 The authors would like to thank <contact fullname="Adrian Farrel"/>, <contact
Germany fullname="Julien Meuric"/>, <contact fullname="Dhruv Dhody" />,
Phone: +49 89 5159 16934 and <contact fullname="Benjamin Kaduk" /> for many helpful comments that grea
Email: cyril.margaria@nsn.com tly
improved the contents of this document.</t>
</section>
Oscar Gonzalez de Dios <section anchor="sect-11" numbered="false" toc="default">
Telefonica Investigacion y Desarrollo <name>Contributors</name>
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3374013
Email: ogondio@tid.es
Greg Bernstein <contact fullname="Fatai Zhang">
Grotto Networking <organization>Huawei Technologies</organization>
Fremont, CA, USA <address>
Phone: (510) 573-2237 <postal>
Email: gregb@grotto-networking.com <street/>
]]></artwork> <city/>
</figure> <region/><code/>
</section> <country/>
</postal>
<email>zhangfatai@huawei.com</email>
</address>
</contact>
</back> <contact fullname="Cyril Margaria">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>St. Martin Strasse 76</street>
<city>Munich</city>
<region></region><code>81541</code>
<country>Germany</country>
</postal>
<phone>+49 89 5159 16934</phone>
<email>cyril.margaria@nsn.com</email>
</address>
</contact>
</rfc> <contact fullname="Oscar Gonzalez de Dios">
<organization>Telefonica Investigacion y Desarrollo</organization>
<address>
<postal>
<street>C/ Emilio Vargas 6</street>
<city>Madrid</city>
<region></region><code>28043</code>
<country>Spain</country>
</postal>
<phone>+34 91 3374013</phone>
<email>ogondio@tid.es</email>
</address>
</contact>
<contact fullname="Greg Bernstein">
<organization>Grotto Networking</organization>
<address>
<postal>
<street/>
<city>Fremont</city>
<region>CA</region><code/>
<country>United States of America</country>
</postal>
<phone>+1 510 573 2237</phone>
<email>gregb@grotto-networking.com</email>
</address>
</contact>
</section>
</back>
</rfc>
 End of changes. 222 change blocks. 
1212 lines changed or deleted 1278 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/