<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3630 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC5329 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC6205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6205.xml">
<!ENTITY RFC7570 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7570.xml">
<!ENTITY RFC7579 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7579.xml">
<!ENTITY RFC7581 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7581.xml">
<!ENTITY RFC7689 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7689.xml">
<!ENTITY RFC7688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7688.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY RFC3471 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC4203 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml">
<!ENTITY RFC4204 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4204.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC5521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml">
<!ENTITY RFC6163 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC6566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6566.xml">
<!ENTITY RFC7446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7446.xml">
<!ENTITY RFC7449 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7449.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     docName="draft-ietf-pce-wson-rwa-ext-17" number="8780" category="std" 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"?>
     consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
     symRefs="true" sortRefs="true" tocInclude="true" version="3">
	<front>

    <title abbrev="PCEP Extension for WSON RWA">PCEP RWA">The Path Computation Element Communication Protocol (PCEP) Extension for WSON Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment</title> Assignment (RWA)</title>
    <seriesInfo name="RFC" value="8780"/>
    <author initials="Y." surname="Lee" fullname="Young Lee, Editor" Lee" role="editor">
	<organization>Huawei Technologies</organization>
	<address><postal><street>5700 Tennyson Parkway Suite 600</street>
	<street>Plano, TX 75024</street>
	<street>United States of America</street>

       <organization>Samsung Electronics</organization>
      <address>
        <postal>
          <street></street>
          <city></city> <region></region><code></code>
          <country></country>
        </postal>
	<email>leeyoung@huawei.com</email>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor" role="editor">
	<organization abbrev="CTTC">Carl
      <organization>CTTC</organization>
      <address>
        <postal>
	  <extaddr>Carl Friedrich Gauss 7</organization>
	<address><postal><street>CTTC PMT 7</extaddr>
          <street>PMT Ed B4 Av.</street>
	<street>Castelldefels Barcelona 08860</street>
	<street>Spain</street>
          <city>Castelldefels</city><region>Barcelona</region><code>08860</code>
          <country>Spain</country>
        </postal>
	<phone>(34)
        <phone>+34 936452916</phone>
        <email>ramon.casellas@cttc.es</email>
      </address>
    </author>
    <date year="2020" month="February"/>
	<abstract><t> month="July"/>

    <abstract>
      <t>
   This document provides the Path Computation Element communication Communication
   Protocol (PCEP) extensions for the support of Routing and Wavelength
   Assignment (RWA) in Wavelength Switched Optical Networks (WSON). (WSONs).
   Path provisioning in WSONs requires a routing and wavelength
   assignment (RWA) an RWA process.  From a path computation perspective,
   wavelength assignment is the process of determining which wavelength
   can be used on each hop of a path and forms an additional routing
   constraint to optical path computation.</t>
    </abstract>
  </front>
  <middle>

    <section title="Terminology" anchor="sect-1"><t>
   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> anchor="sect-3" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   <xref target="RFC5440"/> target="RFC5440" format="default"/> specifies the Path Computation Element (PCE) Communication
   Protocol (PCEP) for communications between a Path Computation Client
   (PCC) and a PCE, or between two PCEs.  Such interactions include
   path computation requests
   Path Computation Requests (PCReqs) and path computation replies Path Computation Replies (PCReps) as well as
   notifications of specific states related to the use of a PCE in the
   context of Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineering.</t> Engineering (TE).</t>
      <t>
   A PCC is said to be any network component that makes such a request
   and may be, for instance, an Optical Switching Element optical switching element within a
   Wavelength Division Multiplexing (WDM) network.  The PCE, itself,
   can be located anywhere within the network, network and may be within an
   optical switching element, a Network Management System (NMS) (NMS), or
   an Operational Support System (OSS), or it may be an independent network
   server.</t>
      <t>
   This document provides the PCEP extensions for the support of
   Routing and Wavelength Assignment (RWA) in Wavelength Switched
   Optical Networks (WSON) (WSONs) based on the requirements specified in
   <xref target="RFC6163"/> target="RFC6163" format="default"/> and <xref target="RFC7449"/>.</t> target="RFC7449" format="default"/>.</t>
      <t>
   WSON refers to WDM based WDM-based optical networks in which switching is performed
   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
   known as Lambda Switch Capable (LSC). WSONs can be transparent or
   translucent. A transparent optical network is made up of optical devices
   that can switch but not convert from one wavelength to another, all within
   the optical domain. On the other hand, translucent networks include 3R
   regenerators (Re-amplification, Re-shaping, Re-timing) (reamplification, reshaping, and retiming) that are sparsely
   placed. The main function of the 3R regenerators is to convert one optical
   wavelength to another.</t>
      <t>
   A Lambda Switch Capable (LSC)
   An LSC Label Switched Path (LSP) may span one
   or several transparent segments, which are delimited by 3R
   regenerators typically with electronic regenerator and optional
   wavelength conversion. Each transparent segment or path in WSON is
   referred to as an optical path. An optical path may span multiple
   fiber links links, and the path should be assigned the same wavelength for
   each link. In such a case, the optical path is said to satisfy the
   wavelength-continuity constraint. <xref target="fig-1"/> target="fig-1" format="default"/> illustrates the
   relationship between a an LSC LSP and transparent segments (optical
   paths).</t>
      <figure title="Illustration anchor="fig-1">
        <name>Illustration of a an LSC LSP and transparent segments" anchor="fig-1"><artwork><![CDATA[ Transparent Segments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+---+       +-----+       +-----+      +-----+         +-----+
|   |I1     |     |       |     |      |     |       I2|     |
|   |o------|     |-------[(3R) ]------|     |--------o|     |
|   |       |     |       |     |      |     |         |     |
+---+       +-----+       +-----+      +-----+         +-----+
    (X  LSC)     (LSC  LSC)    (LSC  LSC)     (LSC  X)
     <------->   <------->       <----->     <------->
     <-----------------------><---------------------->
      Transparent Segment         Transparent Segment
    <------------------------------------------------->
                           LSC LSP
]]></artwork>
      </figure>
      <t>
   Note that two transparent segments within a WSON LSP do not need to
   operate on the same wavelength (due to the wavelength conversion
   capabilities). Two optical channels that share a common fiber link
   cannot be assigned the same wavelength; Otherwise, otherwise, the two signals
   would interfere with each other. Note that advanced additional
   multiplexing techniques such as polarization based polarization-based multiplexing are
   not addressed in this document since the physical layer physical-layer aspects are
   not currently standardized. Therefore, assigning the proper
   wavelength on a path is an essential requirement in the optical path
   computation process.</t>
      <t>
   When a switching node has the ability to perform wavelength
   conversion, the wavelength-continuity constraint can be relaxed, and
   a LSC Label Switched Path (LSP)
   an LSP may use different wavelengths on
   different links along its route from origin to destination. It is,
   however, to be noted that wavelength converters may be limited due
   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
   composed of network nodes that cannot perform wavelength conversion,
   nodes with limited wavelength conversion, and nodes with full
   wavelength conversion abilities, wavelength assignment is an
   additional routing constraint to be considered in all optical path
   computation.</t>
      <t>
   For example (see <xref target="fig-1"/>), target="fig-1" format="default"/>), within a translucent WSON, a an LSC
   LSP may be established between interfaces I1 and I2, spanning 2 two transparent
   segments (optical paths) where the wavelength continuity constraint applies
   (i.e.
   (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, the switching capabilities of the TE link would be (X X) X), where X
   refers to the switching capability of I1 and I2.  For example, X can be
   Packet Switch Capable (PSC), Time Division Time-Division Multiplexing (TDM), etc.</t>
      <t>
   This document aligns with GMPLS extensions for PCEP
 <xref
   target="PCEP-GMPLS"/> target="RFC8779"
   format="default"/> for generic properties such as label, label-set label set, and
   label assignment assignment, noting that a wavelength is a type of label. Wavelength
   restrictions and constraints are also formulated in terms of labels per
   <xref target="RFC7579"/>.</t> target="RFC7579" format="default"/>.</t>
      <t>
   The optical modulation properties, which are also referred to as signal
   compatibility, are already considered in the signaling in <xref
   target="RFC7581"/> target="RFC7581" format="default"/> and <xref target="RFC7688"/>. target="RFC7688" format="default"/>. In order to improve the
   signal quality and limit some optical effects effects, several advanced modulation
   processing capabilities are used by the mechanisms specified in this
   document.

   These modulation capabilities contribute not only contribute to optical signal
   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
   and Forward Error Correction (FEC)) indicated by means of optical interface
   class the Optical Interface
   Class (OIC) must be compatible between the sender and the receiver of the
   optical path across all optical elements.</t>
      <t>
   This document, however, does not address optical impairments as part
   of RWA path computation. See <xref target="RFC6566"/> target="RFC6566" format="default"/> for the framework for optical
   impairments.</t>
    </section>

   <section title="Encoding 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>REQUIRED</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 anchor="sect-4" numbered="true" toc="default">
      <name>Encoding of a an RWA Path Request" anchor="sect-4"><t> Request</name>
      <t>
   <xref target="fig-2"/> target="fig-2" format="default"/> shows one typical PCE based PCE-based implementation, which is
   referred to as the Combined Process (R&amp;WA). With this architecture,
   the two processes of routing and wavelength assignment are accessed
   via a single PCE. This architecture is the base architecture
   specified in <xref target="RFC6163"/> target="RFC6163" format="default"/>, and the PCEP extensions that are specified in
   this document are based on this architecture.</t>
      <figure title="Combined anchor="fig-2">
        <name>Combined Process (R&amp;WA) architecture" anchor="fig-2"><artwork><![CDATA[ Architecture</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                       +----------------------------+
         +-----+       |     +-------+     +--+     |
         |     |       |     |Routing|     |WA|     |
         | PCC |<----->|     +-------+     +--+     |
         |     |       |                            |
         +-----+       |             PCE            |
                       +----------------------------+
]]></artwork>
      </figure>
      <section title="Wavelength anchor="sect-4.1" numbered="true" toc="default">
        <name>Wavelength Assignment (WA) Object" anchor="sect-4.1"><t> Object</name>
        <t>
   Wavelength allocation can be performed by the PCE by different
   means:

   <list style="format (%c)">

   <t>By
   means of Explicit of:

        </t>
        <ol spacing="normal" type="(%c)">
          <li>Explicit Label Control <xref target="RFC3471"/> target="RFC3471" format="default"/>
          where the PCE allocates which label to use for each interface/node
          along the path.  The allocated labels MAY <bcp14>MAY</bcp14> appear
          after an interface route subobject.</t>

   <t>By means of a subobject.</li>

          <li>A Label Set where the PCE provides a range of potential
   labels to allocate be allocated by each node along the path.</t>

   </list>
    </t> path.</li>
        </ol>
        <t>
   Option (b) allows distributed label allocation (performed during
   signaling) to complete wavelength assignment.</t>

        <t>
   Additionally, given a range of potential labels to allocate, a PC
   Request SHOULD PCReq
   <bcp14>SHOULD</bcp14> convey the heuristic / or mechanism used for the
   allocation.</t>
        <t>
   The
   Per <xref target="RFC5440" format="default"/>, the format of a PCReq message per <xref target="RFC5440"/> after incorporating the
   Wavelength Assignment (WA) object is as follows:</t>

	<figure><artwork><![CDATA[

<sourcecode type="rbnf"><![CDATA[
<PCReq Message> ::= <Common Header>

                       [<svec-list>]

                       <request-list>

   Where:
]]></sourcecode>

  <t> Where:</t>

<sourcecode type="rbnf"><![CDATA[
      <request-list>::=<request>[<request-list>]

      <request>::= <RP>
                   <END-POINTS>

                   <WA>

                   [other optional objects...]
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   If the WA object is present in the request, it MUST <bcp14>MUST</bcp14> be encoded after the
   END-POINTS object as defined in <xref target="PCEP-GMPLS"/>. target="RFC8779" format="default"/>. The WA Object object
   is mandatory in this document. Orderings for the other optional objects are
   irrelevant.</t>
        <t>
   For the WA object, the Object-Class is (TBD1) (To be assigned by IANA).</t>

	<t>
   WA 42,
   and the Object-Type is 1.</t>
        <t>The format of the WA object body is as follows:</t>
        <figure title="WA Object" anchor="fig-3"><artwork><![CDATA[ anchor="fig-3">
          <name>WA Object</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |            Flags            |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                            TLVs                             //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

	<t><list style="symbols">
        <t>Reserved

<dl newline="false" spacing="normal">

          <dt>Reserved (16 bits): Reserved bits):</dt><dd>Reserved for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed
           and ignored on receipt.</t>

	<t>Flags receipt.</dd>

          <dt>Flags field (16 bits)</t>

	</list>
	</t>

	<t>
   One bits):</dt><dd><t>One flag bit is allocated as follows:

      <list style="hanging" hangIndent="6">

      <t hangText="M (Mode - 1 bit):"> follows:</t>

        <dl newline="false" spacing="normal">
          <dt>M (1 bit):</dt><dd>Wavelength Allocation Mode. The M bit is used to 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
      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
      label assigned by the PCE need not be explicit (i.e., it can be
      suggested in the form of label set Label Set objects in the corresponding
      response, to allow distributed WA. If M is 0, the PCE MUST <bcp14>MUST</bcp14> return a
      Label Set Field as described in Section 2.6 of <xref target="RFC7579"/> target="RFC7579" sectionFormat="of" section="2.6"/>
      in the response.  See Section 5 <xref target="sect-5" /> of this document for the encoding
      discussion of a Label Set Field in a PCRep message.</t>
      </list>
	</t> message.</dd>
         </dl>
        <t>All unused flags SHOULD <bcp14>SHOULD</bcp14> be zeroed. IANA is to create has created
        a new registry to manage the Flag Flags field of the WA object.

	<list style="symbols">
	  <t>TLVs (variable). In object.</t>
 </dd>

         <dt>TLVs (variable):</dt><dd><t>In the TLVs field, the following two TLVs are
	  defined. At least one TLV MUST <bcp14>MUST</bcp14> be present.</t>
        </list>

	<list style="hanging" hangIndent="3">

	<t hangText="Wavelength

        <dl newline="false" spacing="normal">
          <dt>Wavelength Selection TLV:"> A TLV of TLV:</dt><dd>The type (TBD2) with of this TLV is 8,
	  and it has a
          fixed length of 32 bits indicating bits. This TLV indicates the wavelength selection. See
          <xref
	target="sect-4.2"/> target="sect-4.2" format="default"/> for details.</t>

	<t hangText="Wavelength details.</dd>
          <dt>Wavelength Restriction Constraint TLV:"> A TLV of TLV:</dt><dd>The type
	(TBD3) with of this
	  TLV is 9, and it has a variable length indicating length. This TLV indicates wavelength restrictions. See
	<xref target="sect-4.3"/> target="sect-4.3" format="default"/> for details.</t>

	</list>
	</t> details.</dd>
</dl>
</dd>
</dl>

      </section>
      <section title="Wavelength anchor="sect-4.2" numbered="true" toc="default">
        <name>Wavelength Selection TLV" anchor="sect-4.2"><t> TLV</name>
        <t>
   The Wavelength Selection TLV is used to indicate the wavelength
   selection constraint in regard to the order of wavelength assignment
   to be returned by the PCE. This TLV is only applied when the M bit is
   set in the WA Object object specified in <xref target="sect-4.1"/>. target="sect-4.1" format="default"/>. This TLV MUST NOT <bcp14>MUST NOT</bcp14> be
   used when the M bit is cleared.</t>
        <t>

   The encoding of this TLV is specified as the Wavelength Selection
   Sub-TLV WavelengthSelection sub-TLV
   in Section 4.2.2 of <xref target="RFC7689"/>. target="RFC7689" sectionFormat="of" section="4.2.2"/>. IANA is to allocate has
   allocated a new TLV
   type, type for the Wavelength Selection TLV type (TBD2).</t> (Type 8).</t>
      </section>
      <section title="Wavelength anchor="sect-4.3" numbered="true" toc="default">
        <name>Wavelength Restriction Constraint TLV" anchor="sect-4.3"><t> TLV</name>
        <t>
   For any request that contains a wavelength assignment, the requester (PCC) MUST
   <bcp14>MUST</bcp14> specify a restriction on the wavelengths to be
   used. This restriction is to be interpreted by the PCE as a constraint on
   the tuning ability of the origination laser transmitter or on any other
   maintenance related
   maintenance-related constraints. Note that if the LSP LSC LSP spans different
   segments, the PCE must have mechanisms to know the tunability restrictions
   of the involved wavelength converters /
   regenerators, e.g. converters/regenerators, e.g., by means of the
   Traffic Engineering Database (TED) either via either IGP or Network Management System (NMS). NMS. Even if the 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>

	<figure><artwork><![CDATA[
<sourcecode type="rbnf"><![CDATA[
<Wavelength Restriction Constraint> Restriction> ::=

               (<Action> <Count> <Reserved>

               <Link Identifiers> <Wavelength Restriction>)...

Where Constraint>)...
]]></sourcecode>

<t>Where:</t>

<sourcecode type="rbnf"><![CDATA[
<Link Identifiers> ::= <Link Identifier> [<Link Identifiers>]
]]></artwork>
	</figure>
]]></sourcecode>

        <t>See Section 4.3.1. <xref target="sect-4.3.1"/> for the encoding of the Link Identifiers Field.</t>
        Identifier field.</t>
        <t> These fields (i.e., &lt;Action&gt;, &lt;Link Identifiers&gt; Identifiers&gt;, and
	&lt;Wavelength Restriction&gt;, Constraint&gt;, etc.) MAY <bcp14>MAY</bcp14> appear together more than
	once to be able to specify multiple actions and their
	restrictions.</t>
        <t>
   IANA is to allocate has allocated a new TLV type, type for the Wavelength Restriction
   Constraint
   TLV type (TBD3).</t> (Type 9).</t>
        <t>The TLV data is defined as follows:</t>
        <figure title="Wavelength anchor="fig-4">
          <name>Wavelength Restriction Constraint TLV Encoding" anchor="fig-4"><artwork><![CDATA[ Encoding</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action        |    Count      |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Link Identifiers Field                         |
//                          . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Wavelength Restriction Field Constraint                      |
//                        . . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         . . . .                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action        |    Count      |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Link Identifiers Field                         |
//                          . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Wavelength Restriction Field Constraint                      |
//                        . . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

	<t><list style="symbols"><t>Action

<dl newline="true" spacing="normal">
          <dt>Action (8 bits):

	<list style="symbols"><t>0 - Inclusive List indicates bits):</dt><dd>

              <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
	separate link that is part of the set.</t>

	<t>1 - Inclusive Range indicates set.</dd>
              <dt>1:</dt><dd>Inclusive Range. Indicates that the Link Set defines a
           range of links.  It contains two link identifiers. The first
           identifier indicates the start of the range (inclusive). The
           second identifier indicates the end of the range
           (inclusive). All links with numeric values between the
           bounds are considered to be part of the set. A value of zero
           in either position indicates that there is no bound on the
           corresponding portion of the range.</t>

	<t>2-255 - For future use</t>

	</list>
	</t>

	</list>
	</t>

	<t>
   IANA is to create range.</dd>
              <dt>2-255:</dt><dd>Unassigned.</dd>
              </dl>
<t>IANA has created a new registry to manage the Action values of the
Wavelength Restriction Constraint TLV.</t>

        <t>
   If a PCE receives an unrecognized Action value, the PCE MUST <bcp14>MUST</bcp14> send a
   PCErr
   PCEP Error (PCErr) message with a PCEP-ERROR Object (Error-Type=TBD8) object with Error-Type=27 and
   an
   Error-value (Error-value=3). Error-value=3. See <xref target="sect-5.2"/> target="sect-5.2" format="default"/> for details.</t>
        <t>
   Note that "links" are assumed to be bidirectional.</t>

	<t><list style="symbols"><t>Count

 </dd>

<dt>Count (8 bits): The bits):</dt><dd><t>The number of the link identifiers</t>

	</list>
	</t> identifiers.</t>
        <t>
   Note that a PCC MAY <bcp14>MAY</bcp14> add a Wavelength restriction that applies to all
   links by setting the Count field to zero and specifying just a set
   of wavelengths.</t>
        <t>
   Note that all link identifiers in the same list MUST <bcp14>MUST</bcp14> be of the same
   type.</t>

	<t><list style="hanging" hangIndent="3">
	<t hangText="Reserved
 </dd>

          <dt>Reserved (16 bits):"> bits):</dt>
          <dd> Reserved for future use and SHOULD <bcp14>SHOULD</bcp14>
	be zeroed and ignored on receipt.
	</t>

	<t hangText="Link Identifiers:">
	</dd>

          <dt>Link Identifiers:</dt>
          <dd> Identifies each link ID for which
	restriction is applied. The length is dependent on the link format and
	the Count field. See <xref target="sect-4.3.1"/>. target="sect-4.3.1" format="default"/> for
	encoding of the Link Identifier
	encoding.
	</t>

	<t hangText="Wavelength Restriction:"> field.
	</dd>

          <dt>Wavelength Constraint:</dt>
          <dd> See Section 4.3.2. <xref target="sect-4.3.2"/> for the encoding of the
	Wavelength Restriction Field encoding.
	</t>

	</list>
	</t> Constraint field.
	</dd>
        </dl>

        <t>
   Various encoding errors are possible with this TLV (e.g., not
   exactly two link identifiers with the range case, unknown identifier
   types, no matching link for a given identifier, etc.).

   To indicate
   errors associated with this encoding, a PCEP speaker MUST <bcp14>MUST</bcp14> send a
   PCErr message with Error-Type=TBD8 Error-Type=27 and Error-value=3. See <xref target="sect-5.1"/> target="sect-5.2" format="default"/> for the details.</t>
        <section title="Link anchor="sect-4.3.1" numbered="true" toc="default">
          <name>Link Identifier Field" anchor="sect-4.3.1"><t> Field</name>
          <t>
   The link identifier Link Identifier field can be an IPv4 <xref target="RFC3630"/>, target="RFC3630"
   format="default"/>, IPv6 <xref target="RFC5329"/> target="RFC5329" format="default"/>, or
   unnumbered interface ID <xref target="RFC4203"/>.</t>

	<figure><artwork><![CDATA[ target="RFC4203" format="default"/>.</t>

<sourcecode type="rbnf"><![CDATA[
<Link Identifier> ::=

            <IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID>
]]></artwork>
	</figure>
]]></sourcecode>

          <t>The encoding of each case is as follows:</t>

<figure><artwork><![CDATA[

   IPv4 follows.</t>

<figure anchor="fig-4.3.1-1">
<name>IPv4 Address Field Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 1     |    Reserved  (24 bits)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes)                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6
]]></artwork>
</figure>

<figure anchor="fig-4.3.1-2">
<name>IPv6 Address Field Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 2     |    Reserved  (24 bits)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes)                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued)                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued)                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued)                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unnumbered
]]></artwork>
</figure>

<figure anchor="fig-4.3.1-3">
<name>Unnumbered Interface ID Address Field Field</name>

<artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 3     |    Reserved (24 bits)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        TE Node ID (32 bits)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Interface ID (32 bits)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

	<t><list style="hanging" hangIndent="3">

	<t hangText="Type

          <dl newline="false" spacing="normal" indent="3">
            <dt>Type (8 bits):"> It indicates bits):</dt>
            <dd> Indicates the type of the link identifier.</t>

        <t hangText="Reserved identifier.</dd>

            <dt>Reserved (24 bits):"> Reserved bits):</dt>
            <dd>Reserved for future use and SHOULD <bcp14>SHOULD</bcp14>
        be zeroed and ignored on receipt.</t>

	<t hangText="Link Identifier:"> When receipt.</dd>

            <dt>Link Identifier:</dt>
            <dd>When the Type field is 1, 4-bytes a 4-byte IPv4
	address is encoded; when the Type field is 2, 16-bytes a 16-byte IPv6 address is
	encoded; and when the Type field is 3, a tuple of 4-bytes a 4-byte TE node ID and
	4-bytes
	a 4-byte interface ID is encoded.</t>

	</list>
	</t> encoded.</dd>
       </dl>
          <t>
   The Type field is extensible and matches to the IANA "TE_LINK Object Class type
   name space (Value 11)" registry created for the
   Link Management Protocol (LMP) <xref target="RFC4204"/> for "TE Link Object Class Type name space": <eref target="https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15."/> See target="RFC4204"
   format="default"/> (see <xref target="sect-8.14"/>
   for the request to update the target="LMP-PARAM"/>). IANA has added
   an introductory text of note before the aforementioned registry to note stating that the values
   have additional usage for the Link Identifier Type field.</t> field. See <xref
   target="sect-8.14" format="default"/>.</t>
        </section>
        <section title="Wavelength Restriction Field" anchor="sect-4.3.2"><t> anchor="sect-4.3.2" numbered="true" toc="default">
          <name>Wavelength Constraint Field</name>
          <t>
   The Wavelength Restriction Field Constraint field of the Wavelength Restriction
   Constraint
   TLV is encoded as a Label Set field Field as specified in
   Section 2.6 in
   <xref target="RFC7579"/> target="RFC7579" sectionFormat="of" section="2.6"/> with the base label encoded as a 32 bit 32-bit LSC
   label, as defined in <xref target="RFC6205"/>. target="RFC6205" format="default"/>.  The Label Set format is repeated here
   for convenience, with the base label internal structure included.
   See <xref target="RFC6205"/> target="RFC6205" format="default"/> for a description of Grid, C.S, Identifier Channel Spacing (C.S.), Identifier, and n, as
   well as and see <xref target="RFC7579"/> target="RFC7579" format="default"/> 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 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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S C.S.  |    Identifier   |              n                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Additional fields as necessary per action                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
	</figure>

<t> Action
]]></artwork></figure>

          <dl newline="true" spacing="normal">

          <dt>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 bits):</dt><dd>

            <dl newline="false" spacing="normal">
            <dt>0:</dt><dd>Inclusive List</dd>
            <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>

            <dt>Num Labels (12 bits):"> bits):</dt>
            <dd> It is generally the number of
	labels. It has a specific meaning depending on the action value.</t>

	<t hangText="Length value.</dd>
            <dt>Length (16 bits):"> bits):</dt>
            <dd> It is the length in bytes of the entire Wavelength
	Restriction field.</t>

	<t hangText="Identifier
	Constraint field.</dd>
            <dt>Identifier (9 bits):"> bits):</dt>
            <dd> The Identifier is always set to
	0. If PCC receives the value of the identifier other than 0, it will ignore.</t>
	</list>
	</t> ignore.</dd>
          </dl>

          <t>
   See Sections 2.6.1 - 2.6.3 <xref target="RFC7579" section="2.6.1" sectionFormat="bare"/>-<xref target="RFC7579" section="2.6.3" sectionFormat="bare"/> of <xref target="RFC7579"/> for details on additional
   field discussion for each action.</t>
        </section>
      </section>
      <section title="Signal anchor="sect-4.4" numbered="true" toc="default">
        <name>Signal Processing Capability Restrictions" anchor="sect-4.4"><t> Restrictions</name>
        <t>
   Path computation for WSON includes the checking of signal processing
   capabilities at each interface against requested capability; the PCE
   MUST
   <bcp14>MUST</bcp14> have mechanisms to know the signal processing capabilities at
   each interface, e.g. e.g., by means of the Traffic Engineering Database
   (TED) either via either IGP or Network Management System (NMS). NMS.  Moreover,
   a PCC should be able to indicate additional restrictions to signal
   processing compatibility, either on either the endpoint or any given link.</t>
        <t>
   The supported signal processing capabilities considered in the RWA
   Information Model <xref target="RFC7446"/> target="RFC7446" format="default"/> are:

	<list style="symbols">
	<t>Optical
        </t>
        <ul spacing="normal">
          <li>Optical Interface Class List</t>

	<t>Bit Rate</t>

	<t>Client Signal</t>

	</list>
	</t> List</li>
          <li>Bit Rate</li>
          <li>Client Signal</li>
        </ul>
        <t>
   The Bit Rate bit rate restriction is already expressed in <xref
   target="PCEP-GMPLS"/> in the BANDWIDTH object.</t> object in <xref target="RFC8779"
   format="default"/>.</t>
        <t>
   In order to support the Optical Interface Class optical interface class information and the Client
   Signal information client
   signal information, new TLVs are introduced as endpoint-restriction endpoint restrictions in the
   END-POINTS type Generalized endpoint:

        <list style="symbols">
	<t>Client Endpoint:

        </t>
        <ul spacing="normal">
          <li>Client Signal TLV</t>

	<t>Optical Information TLV</li>
          <li>Optical Interface Class List TLV</t>

	</list>
	</t> TLV</li>
        </ul>
        <t>
   The END-POINTS type generalized endpoint Generalized Endpoint is extended as follows:</t>

	<figure><artwork><![CDATA[

<sourcecode type="rbnf"><![CDATA[
<endpoint-restriction> ::=
                      <LABEL-REQUEST> <label-restriction-list>

<label-restriction-list> ::= <label-restriction>
                             [<label-restriction-list>]

<label-restriction> ::= (<LABEL-SET>|
                        [<Wavelength Restriction Constraint>] Restriction>]
                        [<signal-compatibility-restriction>])
Where
]]></sourcecode>

<t>Where:</t>

<sourcecode type="rbnf"><![CDATA[
<signal-compatibility-restriction> ::=
    [<Optical Interface Class List>] [<Client Signal>]

]]></artwork>
	</figure> Signal Information>]
]]></sourcecode>
        <t>
   The Wavelength Restriction Constraint TLV is defined in Section 4.3.</t> <xref target="sect-4.3"/>.</t>

        <t>
   A new TLV for the Optical Interface Class List TLV (TBD5) (Type 11) is
   defined, and
   defined; the encoding of the value part of the Optical Interface
   Class List this TLV
   is described in Section 4.1 of <xref target="RFC7581"/>.</t> target="RFC7581" sectionFormat="of" section="4.1"/>.</t>
        <t>
   A new TLV for the Client Signal Information TLV (TBD6) (Type 12) is defined,
   and defined;
   the encoding of the value part of the Client Signal Information this
   TLV is described in Section 4.2 of <xref target="RFC7581"/>.</t> target="RFC7581" sectionFormat="of" section="4.2"/>.</t>

        <section title="Signal anchor="sect-4.4.1" numbered="true" toc="default">
          <name>Signal Processing Exclusion" anchor="sect-4.4.1"><t> Exclusion</name>
          <t>
   The PCC/PCE should be able to exclude particular types of signal
   processing along the path in order to handle client restriction or
   multi-domain path computation.

   <xref target="RFC5440"/> target="RFC5521" format="default"/> defines how the Exclude Route
   Object (XRO) subobject is used. In this draft, document, we add two new XRO
   Signal Processing Exclusion Subobjects.</t> subobjects.</t>
          <t>
   The first XRO subobject type (TBD9) (8) is the Optical Interface Class
   List Field
   List, which is defined as follows:</t>
          <figure title="Optical anchor="fig-5">
            <name>Optical Interface Class List XRO Subobject" anchor="fig-5"><artwork><![CDATA[ Subobject</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type=TBD9  Type=8     |     Length    |   Reserved    | Attribute     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//              Optical Interface Class List                   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>
   Refer to <xref target="RFC5521"/> target="RFC5521" format="default"/> for the definition definitions of
   X, Length Length, and Attribute.</t>

	<t>
   Type
    <dl newline="false" spacing="normal">
   <dt>Type (7 bits): The Type bits):</dt><dd>The type of the Signaling Processing Exclusion Field.
   The TLV Type value (TBD9) is to be assigned by the field.
   IANA has assigned value 8 for the
   Optical Interface Class List XRO Subobject Type.</t>

	<t>
   Reserved subobject type.</dd>

   <dt>Reserved bits (8 bits) bits):</dt><dd>These are for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed and
   ignored on receipt.</t>

	<t>
   The Attribute field receipt.</dd>

   <dt>Attribute (8 bits): <xref target="RFC5521"/> 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).</t>

	<t>
   The Optical (Node).</dd>

   <dt>Optical Interface Class List List:</dt><dd>This field is encoded as
   described in Section
   4.1 of <xref target="RFC7581"/>.</t> target="RFC7581" sectionFormat="of"
   section="4.1"/>.</dd>
    </dl>

          <t>
   The second XRO subobject type (TBD10) (9) is the Client Signal
   Information
   Information, which is defined as follows:</t>
          <figure title="Client anchor="fig-6">
            <name>Client Signal Information XRO Subobject" anchor="fig-6"><artwork><![CDATA[ Subobject</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type=TBD10  Type=9     |     Length    |   Reserved    |  Attribute    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                Client Signal Information                    //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>
   Refer to <xref target="RFC5521"/> target="RFC5521" format="default"/> for the definition definitions of
   X, Length Length, and Attribute.</t>

   <t>Type

<dl newline="false" spacing="normal">
          <dt>Type (7 bits): The Type bits):</dt><dd>The type of the Signaling Processing Exclusion Field.
   The TLV Type value (TBD10) is to be assigned by the field.
   IANA has assigned value 9 for the Client
   Signal Information XRO Subobject Type.</t>

   <t>Reserved subobject type.</dd>
          <dt>Reserved bits (8 bits) bits):</dt><dd>These are for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed and
   ignored on receipt.</t>

   <t>The Attribute field receipt.</dd>
          <dt>Attribute (8 bits): [RFC5521] 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).</t>

	<t>
   The Client
          (Node).</dd>

   <dt>Client Signal Information Information:</dt><dd>This field is encoded as described
   in Section 4.2
   of <xref target="RFC7581"/>.</t> target="RFC7581" sectionFormat="of" section="4.2"/>.</dd>
</dl>
          <t>
   The XRO needs to support the new Signaling Processing Exclusion XRO
   Subobject
   subobject types:</t>

<figure><artwork><![CDATA[
      Type      XRO Subobject Type

      TBD9      Optical
     <ul empty="true"><li>
   <dl spacing="normal">

      <dt>8:</dt><dd>Optical Interface Class List

      TBD10     Client List</dd>

      <dt>9:</dt><dd>Client Signal Information

]]></artwork>
	</figure> Information</dd>
   </dl>
   </li></ul>
        </section>
        <section title="Signal anchor="sect-4.4.2" numbered="true" toc="default">
          <name>Signal Processing Inclusion" anchor="sect-4.4.2"><t> Inclusion</name>
          <t>
   Similar to the XRO subobject, the PCC/PCE should be able to include
   particular types of signal processing along the path in order to
   handle client restriction or multi-domain path computation.
   <xref target="RFC5440"/> target="RFC5440" format="default"/> defines how the Include Route Object (IRO) subobject is used.
   In this draft, document, we add two new Signal Processing Inclusion
   Subobjects.</t>
   subobjects.</t>
          <t>
   The IRO needs to support the new IRO Subobject subobject types (TBD11 (8 and
   TBD12)
   9) for the PCEP IRO object <xref target="RFC5440"/>:</t>

<figure><artwork><![CDATA[
      Type      IRO Subobject Type

      TBD11     Optical target="RFC5440" format="default"/>:</t>
 <ul empty="true"><li>
   <dl>

      <dt>8:</dt><dd>Optical Interface Class List

      TBD12     Client List</dd>

      <dt>9:</dt><dd>Client Signal Information
]]></artwork>
	</figure> Information</dd>
      </dl>
      </li></ul>
          <t>
   The encoding of the Signal Processing Inclusion subobjects is
   similar to the process in <xref target="sect-4.4.1"/> target="sect-4.4.1" format="default"/> where the 'X' field is replaced with the 'L'
   field,
   field; all the other fields remains remain the same. The 'L' field is
   described in <xref target="RFC3209"/>.</t> target="RFC3209" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section title="Encoding anchor="sect-5" numbered="true" toc="default">
      <name>Encoding of a an RWA Path Reply" anchor="sect-5"><t> Reply</name>
      <t>
   This section provides the encoding of a an RWA Path Reply for a
   wavelength allocation request as discussed in <xref target="sect-4"/>.</t> target="sect-4" format="default"/>.</t>
      <section title="Wavelength anchor="sect-5.1" numbered="true" toc="default">
        <name>Wavelength Allocation TLV" anchor="sect-5.1"><t> TLV</name>
        <t>
   Recall that wavelength allocation can be performed by the PCE by
   different means:</t>

	<t><list style="format (%c)">

	<t>By
   means of Explicit of:</t>
        <ol spacing="normal" type="(%c)">
          <li>Explicit Label Control (ELC) where the PCE allocates
	which label to use for each interface/node along the path.</t>

	<t>By means of a path.</li>
          <li>A Label Set where the PCE provides a range of potential
   labels to allocate be allocated by each node along the path.</t>

	</list>
	</t> path.</li>
        </ol>
        <t>
   Option (b) allows distributed label allocation (performed during
   signaling) to complete wavelength allocation.</t>
        <t>
   The type for the Wavelength Allocation TLV type is TBD4 (See 10 (see <xref target="sect-8.4"/>). target="sect-8.4" format="default"/>). Note
   that this TLV is used for both (a) and (b). (b) above. The TLV data is defined
   as follows:</t>
        <figure title="Wavelength anchor="fig-7.2">
          <name>Wavelength Allocation TLV Encoding" anchor="fig-7"><artwork><![CDATA[ Encoding</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |          Flag          Flags              |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Link Identifier Field                         |
//                          . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Allocated Wavelength(s)                    |
//                        . . . .                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

	<t><list style="symbols">

	  <t>Reserved

<dl newline="false" spacing="normal">

          <dt>Reserved (16 bits): Reserved bits):</dt><dd>Reserved for future use.</t>

	  <t>Flags use.</dd>
          <dt>Flags field (16 bits)</t>

	</list>
	</t>

	<t>
   One bits):</dt><dd><t>One flag bit is allocated as follows:

	<list>
	<t>M (Mode): 1 bit</t>

	<t>0 indicates follows:</t>

        <dl newline="false" spacing="normal">
          <dt>M (1 bit):</dt><dd><t>Wavelength Allocation Mode.</t>
             <dl newline="false" spacing="normal">
              <dt>0:</dt><dd>Indicates the allocation is under Explicit relies on the use of Label Control.</t>

	<t>1 indicates Sets.</dd>
              <dt>1:</dt><dd>Indicates the allocation is expressed in done using Explicit Label Sets.</t>

	</list>
	</t>

	<t>
   IANA is to create Control.</dd>

             </dl>
</dd></dl>
        <t>IANA has created a new registry to manage the Flag Flags 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">
	  <t hangText="Link Identifier:"> Identifies
       </dd>

          <dt>Link Identifier:</dt><dd>Identifies the interface to which the
          assignment wavelength(s) is applied. See <xref
	  target="sect-4.3.1"/>. target="sect-4.3.1"
          format="default"/> for encoding of the Link Identifier encoding.</t>

	  <t hangText="Allocated Wavelength(s):"> field.</dd>
          <dt>Allocated Wavelength(s):</dt>
          <dd> Indicates the allocated wavelength(s) to be associated with the Link Identifier.
          link identifier. See <xref
	  target="sect-4.3.2"/> target="sect-4.3.2" format="default"/>
          for encoding details.</t>

	</list>
	</t> details.</dd>
        </dl>

        <t>
   This TLV is carried in a PCRep message as an attribute Attribute TLV <xref target="RFC5420"/> target="RFC5420" format="default"/>
   in the Hop Attribute Subobjects subobjects <xref target="RFC7570"/> target="RFC7570" format="default"/> in the ERO Explicit Route Object (ERO) <xref target="RFC5440"/>.</t> target="RFC5440" format="default"/>.</t>

      </section>

      <section title="Error Indicator" anchor="sect-5.2"><t> 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
   (TBD8) Error-Type
   27 (WSON RWA Error) and subsequent error-values Error-values are defined as follows for
   inclusion in the PCEP-ERROR Object:</t>

	<t>
   A new Error-Type (TBD8) and subsequent error-values are defined as
   follows:

<list style="symbols">

<t>Error-Type=TBD8; object:</t>

        <ul spacing="normal">
          <li>Error-Type=27; Error-value=1: if If a PCE receives a an RWA request
          and the PCE is not capable of processing the request due to
          insufficient memory, the PCE MUST <bcp14>MUST</bcp14> send a PCErr
          message with a PCEP-ERROR Object (Error-Type=TBD8) object with Error-Type=27 and an Error-value (Error- value=1).
          Error-value=1.  The PCE stops processing the request.
          The corresponding RWA request MUST <bcp14>MUST</bcp14> be cancelled canceled at the PCC.</t>

<t>Error-Type=TBD8;
          PCC.</li>

          <li>Error-Type=27; Error-value=2: if If a PCE receives a an RWA request and the PCE
   is not capable of RWA computation, the PCE MUST <bcp14>MUST</bcp14> send a PCErr message
   with a PCEP-ERROR Object (Error-Type=TBD8) object with Error-Type=27 and an Error-value
   (Error-value=2).
   Error-value=2. The PCE stops processing the request.  The
   corresponding RWA computation MUST <bcp14>MUST</bcp14> be cancelled canceled at the PCC.</t>

<t>Error-Type=TBD8; PCC.</li>

          <li>Error-Type=27; Error-value=3: if If a PCE receives a an RWA request and there
   are syntactical encoding errors (e.g., not exactly two link identifiers
   with the range case, unknown identifier types, no matching link for a
   given identifier, unknown Action value, etc.), the PCE MUST <bcp14>MUST</bcp14> send a PCErr
   message with a PCEP- ERROR Object (Error-Type=TBD8) PCEP-ERROR object with Error-Type=27 and an Error-value
   (Error- value=3).</t>
</list>
	</t> Error-value=3.</li>
        </ul>
      </section>
      <section title="NO-PATH Indicator" anchor="sect-5.3"><t> anchor="sect-5.3" numbered="true" toc="default">
        <name>NO-PATH Indicator</name>
        <t>
   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
   response.  The format of the NO-PATH object body is defined in
   <xref target="RFC5440"/>. 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>
        <t>
   One
   This document defines a new bit flag is defined to be carried in the Flags field in the
   NO-PATH-VECTOR TLV TLV, which is carried in the NO-PATH Object.</t>

	<t><list style="hanging" hangIndent="3">
	  <t hangText="Bit TBD7:"> object:</t>

        <dl newline="false" spacing="normal" indent="3">
          <dt>Bit 23:</dt>
          <dd> When set, the PCE indicates no feasible
	  route was found that meets all the constraints (e.g., wavelength
	  restriction, signal compatibility, etc.) associated with RWA.
	</t>

	</list>
	</t>
	</dd>
        </dl>

      </section>
    </section>
    <section title="Manageability Considerations" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>
   Manageability of WSON Routing and Wavelength Assignment (RWA) RWA with
   PCE must address the considerations in the following considerations:</t> subsections.</t>
      <section title="Control anchor="sect-6.1" numbered="true" toc="default">
        <name>Control of Function and Policy" anchor="sect-6.1"><t> Policy</name>
        <t>
   In addition to the parameters already listed in Section 8.1 of <xref target="RFC5440"/>, target="RFC5440" sectionFormat="of" section="8.1"/>, a PCEP implementation SHOULD <bcp14>SHOULD</bcp14> allow configuration of the
   following PCEP session parameters on a PCC:</t>

	<t><list style="symbols">
	  <t>The
        <ul spacing="normal">
          <li>The ability to send a WSON RWA request.</t>

	</list>
	</t> request.</li>
        </ul>
        <t>
   In addition to the parameters already listed in Section 8.1 of <xref target="RFC5440"/>, target="RFC5440" sectionFormat="of" section="8.1"/>, a PCEP implementation SHOULD <bcp14>SHOULD</bcp14> allow configuration of the
   following PCEP session parameters on a PCE:</t>

	<t><list style="symbols">
	  <t>The
        <ul spacing="normal">
          <li>The support for WSON RWA.</t>

	  <t>A RWA.</li>
          <li>A set of WSON RWA specific WSON-RWA-specific policies (authorized sender, request
	  rate limiter, etc).</t>

	</list>
	</t> etc).</li>
        </ul>
        <t>
   These parameters may be configured as default parameters for any
   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
   sessions with a specific group of PCEP peers.</t>
      </section>
      <section title="Liveness anchor="sect-6.2" numbered="true" toc="default">
        <name>Liveness Detection and Monitoring" anchor="sect-6.2"><t> Monitoring</name>
        <t>
   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to requirements, aside from those already
   listed in section 8.3 of <xref target="RFC5440"/>.</t> target="RFC5440" sectionFormat="of" section="8.3"/>.</t>
      </section>
      <section title="Verifying anchor="sect-6.3" numbered="true" toc="default">
        <name>Verifying Correct Operation" anchor="sect-6.3"><t> Operation</name>
        <t>
   Mechanisms defined in this document do not imply any new
   verification requirements in addition to requirements, aside from those already listed in
   section 8.4 of
   <xref target="RFC5440"/></t> target="RFC5440" sectionFormat="of" section="8.4"/>.</t>
      </section>
      <section title="Requirements anchor="sect-6.4" numbered="true" toc="default">
        <name>Requirements on Other Protocols and Functional Components" anchor="sect-6.4"><t> Components</name>
        <t>
   The PCEP Link-State mechanism <xref target="PCEP-LS"/> target="I-D.lee-pce-pcep-ls-optical" format="default"/> may be used to advertise
   WSON RWA path computation capabilities to PCCs.</t>
      </section>
      <section title="Impact anchor="sect-6.5" numbered="true" toc="default">
        <name>Impact on Network Operation" anchor="sect-6.5"><t> Operation</name>
        <t>
   Mechanisms defined in this document do not imply any new network
   operation requirements in addition to requirements, aside from those already listed in
   section 8.6 of
   <xref target="RFC5440"/>.</t> target="RFC5440" sectionFormat="of" section="8.6"/>.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-7"><t> anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security considerations discussed in <xref target="RFC5440"/> target="RFC5440" format="default"/> are relevant for
   this document, document; this document does not introduce any new security
   issues. If an operator wishes to keep private the information
   distributed by WSON, WSON private, PCEPS (Usage of TLS to Provide a Secure Transport for PCEP) <xref target="RFC8253"/> SHOULD target="RFC8253" format="default"/> <bcp14>SHOULD</bcp14> be used.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA maintains a registry of PCEP parameters. IANA has made
   allocations from the sub-registries subregistries as described in the following
   sections.</t>
      <section title="New anchor="sect-8.1" numbered="true" toc="default">
        <name>New PCEP Object: Wavelength Assignment Object" anchor="sect-8.1"><t> Object</name>
        <t>
   As described in <xref target="sect-4.1"/>, target="sect-4.1" format="default"/>, a new PCEP Object
   object is defined to carry
   wavelength assignment related wavelength-assignment-related constraints. IANA is to allocate
   has allocated the following from in the "PCEP Objects" sub-registry
   (<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects"/>):</t>

	<figure><artwork><![CDATA[
Object Class   Name  Object                     Reference
Value                Type
---------------------------------------------------------

TBD1           WA    1: subregistry <xref
   target="PCEP-NUMBERS"/>:</t>

<table align="left">
  <thead>
    <tr>
      <th>Object-Class Value</th>
      <th>Name</th>
      <th>Object-Type</th>
      <th>Reference</th>
 </tr>
  </thead>
  <tbody>
  <tr>
  <td>42</td>
  <td>WA</td>
  <td>0: Reserved</td>
  <td>RFC 8780</td>
  </tr>
  <tr>
  <td></td>
  <td></td>
  <td>1: Wavelength Assignment   [This.I-D]
]]></artwork>
	</figure> Assignment</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>
      <section title="WA anchor="sect-8.2" numbered="true" toc="default">
        <name>WA Object Flag Field" anchor="sect-8.2"><t> Field</name>
        <t>
   As described in <xref target="sect-4.1"/>, target="sect-4.1" format="default"/>, IANA is to create a has
   created the "WA Object Flag Field" subregistry under the "Path Computation
   Element Protocol (PCEP) Numbers" registry <xref target="PCEP-NUMBERS"/> to
   manage the Flag Flags field of the WA object. New values are to be assigned by
   Standards Action <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Each bit should
   be tracked with the following qualities:</t>

	<t><list style="symbols">

	  <t>Bit
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most significant bit)</t>

	  <t>Capability description</t>

	  <t>Defining RFC</t>

	</list>
	</t>

	<t>
   The following values are defined in bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>

        <t>The initial contents of this document:</t>

	<t> registry are shown below. One bit is defined has been
        allocated for the WA Object flag defined 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>

<table align="left">
  <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 title="New anchor="sect-8.3" numbered="true" toc="default">
        <name>New PCEP TLV: Wavelength Selection TLV" anchor="sect-8.3"><t>
   As described in TLV</name>
        <t>
   In <xref target="sect-4.2"/>, target="sect-4.2" format="default"/>, a new PCEP TLV is defined to
   indicate wavelength selection constraints. IANA is to allocate this new TLV
   from has made the following
   allocation in 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> <xref
   target="PCEP-NUMBERS"/>:</t>

<table align="left">
  <thead>
    <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>

      <section title="New anchor="sect-8.4" numbered="true" toc="default">
        <name>New PCEP TLV: Wavelength Restriction Constraint TLV" anchor="sect-8.4"><t>
   As described in TLV</name>
        <t>
   In <xref target="sect-4.3"/>, target="sect-4.3" format="default"/>, a new PCEP TLV is defined to indicate
   wavelength restriction constraints. restrictions. IANA is to allocate this new TLV
   from has made the following allocation in
   the "PCEP TLV Type Indicators" subregistry
   (<eref
   target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators"/>). <xref target="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD3              Wavelength Restriction     [This.I-D]
                  Constraint
]]></artwork>
	</figure>

<table align="left">
  <thead>
    <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 title="Wavelength anchor="sect-8.5" numbered="true" toc="default">
        <name>Wavelength Restriction Constraint TLV Action Values" anchor="sect-8.5"><t> Values</name>
        <t>
   As described in <xref target="sect-4.3"/>, target="sect-4.3" format="default"/>, IANA is to allocate a has
   created the new "Wavelength Restriction TLV Action Values"
   subregistry under the "Path Computation Element Protocol (PCEP) Numbers" registry
   <xref target="PCEP-NUMBERS"/> to
   manage the Action values of the Action field in of the Wavelength
   Restriction Constraint TLV. New values are assigned by Standards
   Action <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Each value should be tracked with the following
   qualities: value, meaning, and defining RFC. The following values
   are defined in </t>
<ul spacing="normal">
<li>Value</li>
<li>Meaning</li>
<li>Defining RFC</li>
</ul>

<t>The initial contents of 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> registry are shown below:</t>

<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 anchor="sect-8.6" numbered="true" toc="default">
        <name>New PCEP TLV: Wavelength Allocation TLV" anchor="sect-8.6"><t>
   As described in TLV</name>
        <t>
   In <xref target="sect-5.1"/>, target="sect-5.1" format="default"/>, a new PCEP TLV
   is defined to indicate the allocation of the wavelength(s) by the PCE in
   response to a request by the PCC. IANA is to allocate this new TLV from has made the following allocation in
   "PCEP TLV Type Indicators" subregistry
   (<eref
   target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators"/>). <xref target="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD4              Wavelength Allocation      [This.I-D]
]]></artwork>
	</figure>
<table align="left">
  <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>

      <section title="Wavelength anchor="sect-8.7" numbered="true" toc="default">
        <name>Wavelength Allocation TLV Flag Field" anchor="sect-8.7"><t> Field</name>
        <t>
   As described in <xref target="sect-5.1"/>, target="sect-5.1" format="default"/>, IANA is to allocate has
   created a new "Wavelength Allocation TLV Flag Field" subregistry under the
   "Path Computation Element Protocol (PCEP) Numbers" registry <xref
   target="PCEP-NUMBERS"/> to
   manage the Flag Flags field of the Wavelength Allocation TLV. New values
   are to be assigned by Standards Action <xref target="RFC8126"/>. target="RFC8126" format="default"/>.  Each bit should
   be tracked with the following qualities:</t>

	<t><list style="symbols">

	  <t>Bit
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most significant bit)</t>

	  <t>Capability description</t>

	  <t>Defining RFC</t>

	</list>
	</t>

	<t>
   One bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>

   <t>One bit is defined for the Wavelength Allocation flag defined in this -
   document:</t>

	<t>
   Codespace
   document. The initial contents of the Flag field (Wavelength Allocation TLV)</t>

	<figure><artwork><![CDATA[
Bit      Description                   Reference
-------------------------------------------------
0-14     Unassigned                    [This.I-D]

15       Wavelength this registry are shown below:</t>

<table align="left">
  <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    [This.I-D]
]]></artwork>
	</figure> Mode</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>
      <section title="New anchor="sect-8.8" numbered="true" toc="default">
        <name>New PCEP TLV: Optical Interface Class List TLV" anchor="sect-8.8"><t>
   As described in TLV</name>
        <t>
   In <xref target="sect-4.4"/>, target="sect-4.4" format="default"/>, a new PCEP TLV is defined to
   indicate the optical interface class list. Optical Interface Class List. IANA is to allocate this new TLV
   from has made the following
   allocation in the "PCEP TLV Type Indicators" subregistry
   (<eref
   target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators"/>). <xref
   target="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD5              Optical
<table align="left">
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
 </tr>
  </thead>
  <tbody>
  <tr>
  <td>11</td>
  <td>Optical Interface          [This.I-D] Class List
]]></artwork>
	</figure> List</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>
      <section title="New anchor="sect-8.9" numbered="true" toc="default">
        <name>New PCEP TLV: Client Signal TLV" anchor="sect-8.9"><t>
   As described in Information TLV</name>
        <t>
   In <xref target="sect-4.4"/>, target="sect-4.4" format="default"/>, a new PCEP TLV is defined to
   indicate the client signal information. Client Signal Information. IANA is to allocate this new TLV from has made the following
   allocation in the "PCEP TLV Type Indicators" subregistry
   (<eref
   target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators"/>). <xref
   target="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD6              Client
<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  [This.I-D]
]]></artwork>
	</figure> Information</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>

      <section title="New No-Path Reasons" anchor="sect-8.10"><t>
   As described in anchor="sect-8.10" numbered="true" toc="default">
   	<name>New Bit Flag for NO-PATH-VECTOR TLV</name>
        <t>
   In <xref target="sect-5.3"/>, target="sect-5.3" format="default"/>, a new bit flag are is defined to be
   carried in the Flags field in the NO-PATH-VECTOR TLV TLV, which is carried in the
   NO-PATH Object. object. This flag, when set, indicates that no feasible
   route was found that meets all the RWA constraints (e.g., wavelength
   restriction, signal compatibility, etc.) associated with a an RWA path
   computation request.</t>
        <t>
   IANA is to allocate has made the following allocation for this new bit flag from in the "PCEP NO-PATH-VECTOR
   "NO-PATH-VECTOR TLV Flag Field" subregistry
   (<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector-tlv"/>).</t>

	<figure><artwork><![CDATA[
Bit         Description                Reference
-----------------------------------------------------
TBD7        No <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     [This.I-D]
]]></artwork>
	</figure> met</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>

      <section title="New anchor="sect-8.11" numbered="true" toc="default">
        <name>New Error-Types and Error-Values" anchor="sect-8.11"><t>
   As described in Error-Values</name>
        <t>
   In <xref target="sect-5.2"/>, target="sect-5.2" format="default"/>, new PCEP error
   codes are defined for WSON RWA errors. IANA is to allocate from has made the ""PCEP-ERROR following allocations
   in the "PCEP-ERROR Object Error Types and Values" sub-registry (<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object"/>).</t>

	<figure><artwork><![CDATA[
Error-      Meaning           Error-Value       Reference
Type
---------------------------------------------------------------

TBD8        WSON subregistry <xref
   target="PCEP-NUMBERS"/>:</t>

<table align="left">
  <thead>
    <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    0: Unassigned        [This.I-D]

                              1: error</td>
      <td>0: Unassigned</td>
      <td>RFC 8780</td>
    </tr>
     <tr>
      <td></td>
      <td></td>
      <td>1: Insufficient      [This.I-D]
                                 Memory

                              2: memory</td>
      <td>RFC 8780</td>
    </tr>
    <tr>
      <td></td>
      <td></td>
      <td>2: RWA computation   [This.I-D]
                                 Not supported

                              3: not supported</td>
      <td>RFC 8780</td>
    </tr>
    <tr>
      <td></td>
      <td></td>
     <td>3: Syntactical       [This.I-D]
                                 Encoding error

                              4-255: Unassigned    [This.I-D]
]]></artwork>
	</figure> 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 title="New anchor="sect-8.12" numbered="true" toc="default">
        <name>New Subobjects for the Exclude Route Object" anchor="sect-8.12"><t>
   As described in <xref target="sect-4.4.1"/>, the "PCEP Parameters" Object</name>
        <t>The "Path Computation Element Protocol (PCEP) Numbers" registry
        contains a subregistry "PCEP Objects" with an entry for the Exclude
   Route Object (XRO). titled "XRO Subobjects" <xref
        target="PCEP-NUMBERS"/>. Per <xref target="sect-4.4.1"
        format="default"/>, IANA is requested to add further has added the following subobjects that can
        be carried in the XRO as follows:</t>

	<figure><artwork><![CDATA[
Subobject       Type                             Reference

----------------------------------------------------------

TBD9            Optical XRO:</t>

<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     [This.I-D]

TBD10           Client List</td>
  <td>RFC 8780</td>
  </tr>
 <tr>
  <td>9</td>
  <td>Client Signal Information        [This.I-D]

]]></artwork>
	</figure> Information</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>
      <section title="New anchor="sect-8.13" numbered="true" toc="default">
        <name>New Subobjects for the Include Route Object" anchor="sect-8.13"><t>
   As described in <xref target="sect-4.4.2"/>, the "PCEP Parameters" Object</name>
        <t>
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a
subregistry "PCEP Objects" with an entry for the Include
   Route Object (IRO). titled "IRO Subobjects" <xref target="PCEP-NUMBERS"/>.  Per <xref
target="sect-4.4.2" format="default"/>, IANA is requested to add further has added the following
subobjects that can be carried in the IRO as follows:</t>

	<figure><artwork><![CDATA[
Subobject     Type                             Reference

----------------------------------------------------------

TBD11         Optical IRO:</t>

<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     [This.I-D]

TBD12         Client List</td>
  <td>RFC 8780</td>
  </tr>
 <tr>
  <td>9</td>
  <td>Client Signal Information        [This.I-D]
]]></artwork>
	</figure> Information</td>
  <td>RFC 8780</td>
  </tr>
 </tbody>
</table>
      </section>

      <section title="Request anchor="sect-8.14" numbered="true" toc="default">
        <name>Request for Updated Note for LMP TE Link Object Class Type" anchor="sect-8.14"><t>
   As discussed in <xref target="sect-4.3.1"/>, the 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"/> for "TE Link Object Class Type name space": <eref target="https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15"/> is requested for target="RFC4204"
   format="default"/>. As discussed in <xref target="sect-4.3.1"
   format="default"/>, IANA has added the updated
   introductory following note that at the top of the
   "TE_LINK Object Class type name space (Value 11)" registry <xref
   target="LMP-PARAM"/>:
</t>

<ul empty="true">
<li>
These values have additional usage for the Link Identifier Type field.</t> field.
</li>
</ul>

      </section>
    </section>

	<section title="Acknowledgments" anchor="sect-9"><t>
   The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv
   Dhody and Benjamin Kaduk for many helpful comments that greatly
   improved the contents of this draft.</t>

	</section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC3209;
	&RFC3630;
	&RFC5329;
	&RFC5440;
	&RFC6205;
	&RFC7570;
	&RFC7579;
	&RFC7581;
	&RFC7689;
	&RFC7688;
	&RFC8174;
	&RFC8253;

<displayreference target="I-D.lee-pce-pcep-ls-optical" to="PCEP-LS"/>

  <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6205.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7570.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7579.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7581.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7689.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7688.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>

<!-- draft-ietf-pce-gmpls-pcep-extensions-16; C385 companion doc - ready for Pub-->
<reference anchor='PCEP-GMPLS'> anchor='RFC8779' target="https://www.rfc-editor.org/info/rfc8779">
<front>
<title>PCEP extensions
<title>Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS</title>
<author initials='C' surname='Margaria' fullname='Cyril Margaria'> Margaria' role="editor">
    <organization />
</author>
<author initials='O' surname='Dios' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios'>
							  Dios' role="editor">
    <organization />
</author>
<author initials='F' surname='Zhang' fullname='Fatai Zhang'> Zhang' role="editor">
    <organization />
</author>
<date month='December' day='12' year='2019' month='July' year='2020' />

<abstract><t>A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.  Additional requirements for GMPLS are identified in RFC7025.  This memo provides extensions to the Path Computation Element communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-pce-gmpls-pcep-extensions-16' /> name="RFC" value="8779"/>
<seriesInfo name="DOI" value="10.17487/RFC8779"/>
</reference>

      </references>
	<references title="Informative References">
	&RFC3471;
	&RFC4203;
	&RFC4204;
	&RFC4655;
	&RFC5420;
	&RFC5521;
	&RFC6163;
	&RFC6566;
	&RFC7446;
	&RFC7449;
	&RFC8126;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3471.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4204.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5420.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6163.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7446.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7449.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

<!--draft-lee-pce-pcep-ls-optical-08; IESG state, I-D Exists -->
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.lee-pce-pcep-ls-optical.xml"/>

<reference anchor='PCEP-LS'> anchor="PCEP-NUMBERS"
           target="https://www.iana.org/assignments/pcep/">
  <front>
<title>PCEP Extension for Distribution of Link-State and TE information for Optical Networks</title>

<author initials='Y' surname='Lee' fullname='Young Lee'>
    <organization />
</author>

<author initials='H' surname='Zheng' fullname='Haomian Zheng'>
    <organization />
</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
    <title>Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this Link State and TE information has been obtained from a link state routing protocol (supporting traffic engineering extensions).  This document extends the Path Communication Element Communication Protocol (PCEP) with Link-State and TE information for optical networks.</t></abstract> Numbers</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<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>

<seriesInfo name='Work in Progress,' value='draft-lee-pce-pcep-ls-optical-08' />
</reference>

      </references>
    </references>

  <section anchor="sect-9" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
   The authors would like to thank <contact fullname="Adrian Farrel"/>, <contact fullname="Julien Meuric"/>, <contact fullname="Dhruv Dhody" />,
   and <contact fullname="Benjamin Kaduk" /> for many helpful comments that greatly
   improved the contents of this document.</t>
    </section>

    <section title="Contributors" anchor="sect-11"><figure><artwork><![CDATA[
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com

Cyril Margaria
Nokia anchor="sect-11" numbered="false" toc="default">
      <name>Contributors</name>

<contact fullname="Fatai Zhang">
<organization>Huawei Technologies</organization>
    <address>
          <postal>
<street/>
<city/>
<region/><code/>
<country/>
</postal>
<email>zhangfatai@huawei.com</email>
</address>
</contact>

<contact fullname="Cyril Margaria">
<organization>Nokia Siemens Networks
St Networks</organization>
<address>
      <postal>
<street>St. Martin Strasse 76
Munich,   81541
Germany
Phone: +49 76</street>
<city>Munich</city>
<region></region><code>81541</code>
<country>Germany</country>
</postal>
<phone>+49 89 5159 16934
Email: cyril.margaria@nsn.com

Oscar 16934</phone>
<email>cyril.margaria@nsn.com</email>
</address>
</contact>

<contact fullname="Oscar Gonzalez de Dios
Telefonica Dios">
<organization>Telefonica Investigacion y Desarrollo
C/ Desarrollo</organization>
  <address>
          <postal>
<street>C/ Emilio Vargas 6
Madrid,   28043
Spain
Phone: +34 6</street>
<city>Madrid</city>
<region></region><code>28043</code>
<country>Spain</country>
</postal>
<phone>+34 91 3374013
Email: ogondio@tid.es

Greg Bernstein
Grotto Networking
Fremont, CA, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
]]></artwork>
	</figure> 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>