<?xml 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">
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-wson-rwa-ext-17" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" docName="draft-ietf-pce-wson-rwa-ext-17" indexInclude="true" ipr="trust200902" number="8780" prepTime="2020-07-21T15:47:03" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext-17" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8780" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <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" stream="IETF"/>
    <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 showOnFrontPage="true">Samsung Electronics</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <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 showOnFrontPage="true">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="07" year="2020"/>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">
   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>
    <boilerplate>
      <section title="Terminology" anchor="sect-1"><t> anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t pn="section-boilerplate.1-2">
            This document uses is a product of the terminology defined Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in <xref target="RFC4655"/>, Section 2 of
            RFC 7841.
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and
   <xref target="RFC5440"/>.</t> how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8780" brackets="none"/>.
        </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", anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and
   "OPTIONAL" in this the persons identified as the
            document are authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, 78 and only when, they appear the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in all
   capitals, as shown here.</t>

	</section>

	<section title="Introduction" anchor="sect-3"><t>
   <xref target="RFC5440"/> specifies effect on the Path Computation Element (PCE) Communication
   Protocol (PCEP) for communications between a Path Computation Client
   (PCC) date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and a PCE, or between two PCEs.  Such interactions restrictions with
            respect to this document. Code Components extracted from this
            document must include
   path computation requests and path computation replies as well Simplified BSD License text as
   notifications described in
            Section 4.e of specific states related to the use of a PCE Trust Legal Provisions and are provided without
            warranty as described in the
   context Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encoding-of-an-rwa-path-req">Encoding of Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineering.</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 within a
   Wavelength Division Multiplexing (WDM) network.  The PCE, itself,
   can be RWA Path Request</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-assignment-wa-ob">Wavelength Assignment (WA) Object</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-selection-tlv">Wavelength Selection TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-restriction-tlv">Wavelength Restriction TLV</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-link-identifier-field">Link Identifier Field</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-constraint-field">Wavelength Constraint Field</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signal-processing-capabilit">Signal Processing Capability Restrictions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signal-processing-exclusion">Signal Processing Exclusion</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signal-processing-inclusion">Signal Processing Inclusion</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encoding-of-an-rwa-path-rep">Encoding of an RWA Path Reply</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-allocation-tlv">Wavelength Allocation TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-error-indicator">Error Indicator</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-path-indicator">NO-PATH Indicator</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-control-of-function-and-pol">Control of Function and Policy</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-liveness-detection-and-moni">Liveness Detection and Monitoring</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verifying-correct-operation">Verifying Correct Operation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-other-proto">Requirements on Other Protocols and Functional Components</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impact-on-network-operation">Impact on Network Operation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-object-wavelength-">New PCEP Object: Wavelength Assignment Object</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wa-object-flag-field">WA Object Flag Field</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-tlv-wavelength-sel">New PCEP TLV: Wavelength Selection TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-tlv-wavelength-res">New PCEP TLV: Wavelength Restriction TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-restriction-tlv-a">Wavelength Restriction TLV Action Values</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-tlv-wavelength-all">New PCEP TLV: Wavelength Allocation TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.7">
                <t pn="section-toc.1-1.8.2.7.1"><xref derivedContent="8.7" format="counter" sectionFormat="of" target="section-8.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wavelength-allocation-tlv-f">Wavelength Allocation TLV Flag Field</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.8">
                <t pn="section-toc.1-1.8.2.8.1"><xref derivedContent="8.8" format="counter" sectionFormat="of" target="section-8.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-tlv-optical-interf">New PCEP TLV: Optical Interface Class List TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.9">
                <t pn="section-toc.1-1.8.2.9.1"><xref derivedContent="8.9" format="counter" sectionFormat="of" target="section-8.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-pcep-tlv-client-signal-">New PCEP TLV: Client Signal Information TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.10">
                <t pn="section-toc.1-1.8.2.10.1"><xref derivedContent="8.10" format="counter" sectionFormat="of" target="section-8.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-bit-flag-for-no-path-ve">New Bit Flag for NO-PATH-VECTOR TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.11">
                <t pn="section-toc.1-1.8.2.11.1"><xref derivedContent="8.11" format="counter" sectionFormat="of" target="section-8.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-error-types-and-error-v">New Error-Types and Error-Values</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.12">
                <t pn="section-toc.1-1.8.2.12.1"><xref derivedContent="8.12" format="counter" sectionFormat="of" target="section-8.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-subobjects-for-the-excl">New Subobjects for the Exclude Route Object</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.13">
                <t pn="section-toc.1-1.8.2.13.1"><xref derivedContent="8.13" format="counter" sectionFormat="of" target="section-8.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-subobjects-for-the-incl">New Subobjects for the Include Route Object</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.14">
                <t pn="section-toc.1-1.8.2.14.1"><xref derivedContent="8.14" format="counter" sectionFormat="of" target="section-8.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-request-for-updated-note-fo">Request for Updated Note for LMP TE Link Object Class Type</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">
   <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> specifies the Path Computation Element Communication
   Protocol (PCEP) for communications between a Path Computation Client
   (PCC) and a PCE, or between two PCEs.  Such interactions include
   Path Computation Requests (PCReqs) and 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 (TE).</t>
      <t pn="section-1-2">
   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
   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>
      <t pn="section-1-3">
   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" sectionFormat="of" derivedContent="RFC6163"/> and <xref target="RFC7449"/>.</t>

	<t> target="RFC7449" format="default" sectionFormat="of" derivedContent="RFC7449"/>.</t>
      <t pn="section-1-4">
   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)
      <t pn="section-1-5">
   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" sectionFormat="of" derivedContent="Figure 1"/> illustrates the
   relationship between a an LSC LSP and transparent segments (optical
   paths).</t>
      <figure title="Illustration anchor="fig-1" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-illustration-of-an-lsc-lsp-">Illustration of a an LSC LSP and transparent segments" anchor="fig-1"><artwork><![CDATA[ Transparent Segments</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-6.1">
+---+       +-----+       +-----+      +-----+         +-----+
|   |I1     |     |       |     |      |     |       I2|     |
|   |o------|     |-------[(3R) ]------|     |--------o|     |
|   |       |     |       |     |      |     |         |     |
+---+       +-----+       +-----+      +-----+         +-----+
    (X  LSC)     (LSC  LSC)    (LSC  LSC)     (LSC  X)
     <------->   <------->       <----->     <------->
     <-----------------------><---------------------->
     &lt;-------&gt;   &lt;-------&gt;       &lt;-----&gt;     &lt;-------&gt;
     &lt;-----------------------&gt;&lt;----------------------&gt;
      Transparent Segment         Transparent Segment
    <------------------------------------------------->
    &lt;-------------------------------------------------&gt;
                           LSC LSP
]]></artwork>
</artwork>
      </figure>
	<t>
      <t pn="section-1-7">
   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>
      <t pn="section-1-8">
   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>
      <t pn="section-1-9">
   For example (see <xref target="fig-1"/>), target="fig-1" format="default" sectionFormat="of" derivedContent="Figure 1"/>), 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>
      <t pn="section-1-10">
   This document aligns with GMPLS extensions for PCEP
 <xref
   target="PCEP-GMPLS"/> target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8779"/> 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>

	<t> target="RFC7579" format="default" sectionFormat="of" derivedContent="RFC7579"/>.</t>
      <t pn="section-1-11">
   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" sectionFormat="of" derivedContent="RFC7581"/> and <xref target="RFC7688"/>. target="RFC7688" format="default" sectionFormat="of" derivedContent="RFC7688"/>. 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>
      <t pn="section-1-12">
   This document, however, does not address optical impairments as part
   of RWA path computation. See <xref target="RFC6566"/> target="RFC6566" format="default" sectionFormat="of" derivedContent="RFC6566"/> for the framework for optical
   impairments.</t>
    </section>
    <section title="Encoding anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t pn="section-2-1">
   This document uses the terminology defined in <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/> and
   <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t pn="section-3-1">
    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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-encoding-of-an-rwa-path-req">Encoding of a an RWA Path Request" anchor="sect-4"><t> Request</name>
      <t pn="section-4-1">
   <xref target="fig-2"/> target="fig-2" format="default" sectionFormat="of" derivedContent="Figure 2"/> 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" sectionFormat="of" derivedContent="RFC6163"/>, and the PCEP extensions that are specified in
   this document are based on this architecture.</t>
      <figure title="Combined anchor="fig-2" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-combined-process-rwa-archit">Combined Process (R&amp;WA) architecture" anchor="fig-2"><artwork><![CDATA[ Architecture</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-2.1">
                       +----------------------------+
         +-----+       |     +-------+     +--+     |
         |     |       |     |Routing|     |WA|     |
         | PCC |<----->| |&lt;-----&gt;|     +-------+     +--+     |
         |     |       |                            |
         +-----+       |             PCE            |
                       +----------------------------+
]]></artwork>
</artwork>
      </figure>
      <section title="Wavelength anchor="sect-4.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-wavelength-assignment-wa-ob">Wavelength Assignment (WA) Object" anchor="sect-4.1"><t> Object</name>
        <t pn="section-4.1-1">
   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)" start="1" pn="section-4.1-2">
          <li pn="section-4.1-2.1" derivedCounter="(a)">Explicit Label Control <xref target="RFC3471"/> target="RFC3471" format="default" sectionFormat="of" derivedContent="RFC3471"/>
          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 pn="section-4.1-2.2" derivedCounter="(b)">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>

	<t> path.</li>
        </ol>
        <t pn="section-4.1-3">
   Option (b) allows distributed label allocation (performed during
   signaling) to complete wavelength assignment.</t>

	<t>
        <t pn="section-4.1-4">
   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
        <t pn="section-4.1-5">
   Per <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, the format of a PCReq message per <xref target="RFC5440"/> after incorporating the
   Wavelength Assignment (WA) object is as follows:</t>

	<figure><artwork><![CDATA[
<PCReq Message>
        <sourcecode type="rbnf" markers="false" pn="section-4.1-6">
&lt;PCReq Message&gt; ::= <Common Header>

                       [<svec-list>]

                       <request-list>

   Where:

      <request-list>::=<request>[<request-list>]

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

                   <WA> &lt;Common Header&gt;

                       [&lt;svec-list&gt;]

                       &lt;request-list&gt;
</sourcecode>
        <t pn="section-4.1-7"> Where:</t>
        <sourcecode type="rbnf" markers="false" pn="section-4.1-8">
      &lt;request-list&gt;::=&lt;request&gt;[&lt;request-list&gt;]

      &lt;request&gt;::= &lt;RP&gt;
                   &lt;END-POINTS&gt;

                   &lt;WA&gt;

                   [other optional objects...]
]]></artwork>
	</figure>

	<t>
</sourcecode>
        <t pn="section-4.1-9">
   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" sectionFormat="of" derivedContent="RFC8779"/>. The WA Object object
   is mandatory in this document. Orderings for the other optional objects are
   irrelevant.</t>

	<t>
        <t pn="section-4.1-10">
   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
        <t pn="section-4.1-11">The format of the WA object body is as follows:</t>
        <figure title="WA Object" anchor="fig-3"><artwork><![CDATA[ anchor="fig-3" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-wa-object">WA Object</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-12.1">
 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>
</artwork>
        </figure>

	<t><list style="symbols">
        <t>Reserved
        <dl newline="false" spacing="normal" pn="section-4.1-13">
          <dt pn="section-4.1-13.1">Reserved (16 bits): Reserved bits):</dt>
          <dd pn="section-4.1-13.2">Reserved for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed
           and ignored on receipt.</t>

	<t>Flags receipt.</dd>
          <dt pn="section-4.1-13.3">Flags field (16 bits)</t>

	</list>
	</t>

	<t>
   One bits):</dt>
          <dd pn="section-4.1-13.4">
            <t pn="section-4.1-13.4.1">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" pn="section-4.1-13.4.2">
              <dt pn="section-4.1-13.4.2.1">M (1 bit):</dt>
              <dd pn="section-4.1-13.4.2.2">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6" derivedContent="RFC7579"/>
      in the response.  See Section 5 <xref target="sect-5" format="default" sectionFormat="of" derivedContent="Section 5"/> of this document for the encoding
      discussion of a Label Set Field in a PCRep message.</t>
      </list>
	</t>

   <t>All message.</dd>
            </dl>
            <t pn="section-4.1-13.4.3">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 pn="section-4.1-13.5">TLVs (variable):</dt>
          <dd pn="section-4.1-13.6">
            <t pn="section-4.1-13.6.1">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" pn="section-4.1-13.6.2">
              <dt pn="section-4.1-13.6.2.1">Wavelength Selection TLV:"> A TLV of TLV:</dt>
              <dd pn="section-4.1-13.6.2.2">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"/> for details.</t>

	<t hangText="Wavelength target="sect-4.2" format="default" sectionFormat="of" derivedContent="Section 4.2"/> for details.</dd>
              <dt pn="section-4.1-13.6.2.3">Wavelength Restriction Constraint TLV:"> A TLV of TLV:</dt>
              <dd pn="section-4.1-13.6.2.4">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"/> for details.</t>

	</list>
	</t> target="sect-4.3" format="default" sectionFormat="of" derivedContent="Section 4.3"/> for details.</dd>
            </dl>
          </dd>
        </dl>
      </section>
      <section title="Wavelength anchor="sect-4.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-wavelength-selection-tlv">Wavelength Selection TLV" anchor="sect-4.2"><t> TLV</name>
        <t pn="section-4.2-1">
   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" sectionFormat="of" derivedContent="Section 4.1"/>. This TLV MUST NOT <bcp14>MUST NOT</bcp14> be
   used when the M bit is cleared.</t>

	<t>
        <t pn="section-4.2-2">

   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7689#section-4.2.2" derivedContent="RFC7689"/>. 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="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-wavelength-restriction-tlv">Wavelength Restriction Constraint TLV" anchor="sect-4.3"><t> TLV</name>
        <t pn="section-4.3-1">
   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>
        <t pn="section-4.3-2">
   The format of the Wavelength Restriction Constraint TLV is as
   follows:</t>

	<figure><artwork><![CDATA[
<Wavelength Restriction Constraint>
        <sourcecode type="rbnf" markers="false" pn="section-4.3-3">
&lt;Wavelength Restriction&gt; ::=

               (<Action> <Count> <Reserved>

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

Where

<Link Identifiers>

               (&lt;Action&gt; &lt;Count&gt; &lt;Reserved&gt;

               &lt;Link Identifiers&gt; &lt;Wavelength Constraint&gt;)...
</sourcecode>
        <t pn="section-4.3-4">Where:</t>
        <sourcecode type="rbnf" markers="false" pn="section-4.3-5">
&lt;Link Identifiers&gt; ::= <Link Identifier> [<Link Identifiers>]
]]></artwork>
	</figure>

	<t>See Section 4.3.1. &lt;Link Identifier&gt; [&lt;Link Identifiers&gt;]
</sourcecode>
        <t pn="section-4.3-6">See <xref target="sect-4.3.1" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> for the encoding of the Link Identifiers Field.</t>

	<t>
        Identifier field.</t>
        <t pn="section-4.3-7"> 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>
        <t pn="section-4.3-8">
   IANA is to allocate a has allocated a new TLV type, type for the Wavelength Restriction
   Constraint
   TLV type (TBD3).</t>

	<t>The (Type 9).</t>
        <t pn="section-4.3-9">The TLV data is defined as follows:</t>
        <figure title="Wavelength anchor="fig-4" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-wavelength-restriction-tlv-">Wavelength Restriction Constraint TLV Encoding" anchor="fig-4"><artwork><![CDATA[ Encoding</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.3-10.1">
 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>
</artwork>
        </figure>

	<t><list style="symbols"><t>Action
        <dl newline="true" spacing="normal" pn="section-4.3-11">
          <dt pn="section-4.3-11.1">Action (8 bits):

	<list style="symbols"><t>0 - Inclusive List indicates bits):</dt>
          <dd pn="section-4.3-11.2">
            <dl newline="false" spacing="normal" pn="section-4.3-11.2.1">
              <dt pn="section-4.3-11.2.1.1">0:</dt>
              <dd pn="section-4.3-11.2.1.2">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 pn="section-4.3-11.2.1.3">1:</dt>
              <dd pn="section-4.3-11.2.1.4">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 pn="section-4.3-11.2.1.5">2-255:</dt>
              <dd pn="section-4.3-11.2.1.6">Unassigned.</dd>
            </dl>
            <t pn="section-4.3-11.2.2">IANA has created a new registry to manage the Action values of the
Wavelength Restriction Constraint TLV.</t>

	<t>
            <t pn="section-4.3-11.2.3">
   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" sectionFormat="of" derivedContent="Section 5.2"/> for details.</t>

	<t>
            <t pn="section-4.3-11.2.4">
   Note that "links" are assumed to be bidirectional.</t>

	<t><list style="symbols"><t>Count
          </dd>
          <dt pn="section-4.3-11.3">Count (8 bits): The bits):</dt>
          <dd pn="section-4.3-11.4">
            <t pn="section-4.3-11.4.1">The number of the link identifiers</t>

	</list>
	</t>

	<t> identifiers.</t>
            <t pn="section-4.3-11.4.2">
   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>
            <t pn="section-4.3-11.4.3">
   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 pn="section-4.3-11.5">Reserved (16 bits):"> bits):</dt>
          <dd pn="section-4.3-11.6"> Reserved for future use and SHOULD <bcp14>SHOULD</bcp14>
	be zeroed and ignored on receipt.
	</t>

	<t hangText="Link Identifiers:">
	</dd>
          <dt pn="section-4.3-11.7">Link Identifiers:</dt>
          <dd pn="section-4.3-11.8"> 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" sectionFormat="of" derivedContent="Section 4.3.1"/> for
	encoding of the Link Identifier
	encoding.
	</t>

	<t hangText="Wavelength Restriction:"> field.
	</dd>
          <dt pn="section-4.3-11.9">Wavelength Constraint:</dt>
          <dd pn="section-4.3-11.10"> See Section 4.3.2. <xref target="sect-4.3.2" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/> for the encoding of the
	Wavelength Restriction Field encoding.
	</t>

	</list>
	</t>

	<t> Constraint field.
	</dd>
        </dl>
        <t pn="section-4.3-12">
   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" sectionFormat="of" derivedContent="Section 5.2"/> for the details.</t>
        <section title="Link anchor="sect-4.3.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-link-identifier-field">Link Identifier Field" anchor="sect-4.3.1"><t> Field</name>
          <t pn="section-4.3.1-1">
   The link identifier Link Identifier field can be an IPv4 <xref target="RFC3630"/>, target="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/>, IPv6 <xref target="RFC5329"/> target="RFC5329" format="default" sectionFormat="of" derivedContent="RFC5329"/>, or
   unnumbered interface ID <xref target="RFC4203"/>.</t>

	<figure><artwork><![CDATA[
<Link Identifier> target="RFC4203" format="default" sectionFormat="of" derivedContent="RFC4203"/>.</t>
          <sourcecode type="rbnf" markers="false" pn="section-4.3.1-2">
&lt;Link Identifier&gt; ::=

            <IPv4 Address>

            &lt;IPv4 Address&gt; | <IPv6 Address> &lt;IPv6 Address&gt; | <Unnumbered &lt;Unnumbered IF ID>
]]></artwork>
	</figure>

<t>The ID&gt;
</sourcecode>
          <t pn="section-4.3.1-3">The encoding of each case is as follows:</t>

<figure><artwork><![CDATA[

   IPv4 follows.</t>
          <figure anchor="fig-4.3.1-1" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-ipv4-address-field">IPv4 Address Field Field</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.3.1-4.1">
 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" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-ipv6-address-field">IPv6 Address Field Field</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.3.1-5.1">
 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" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-unnumbered-interface-id-add">Unnumbered Interface ID Address Field Field</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.3.1-6.1">
 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>
</artwork>
          </figure>

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

	<t hangText="Type
          <dl newline="false" spacing="normal" indent="3" pn="section-4.3.1-7">
            <dt pn="section-4.3.1-7.1">Type (8 bits):"> It indicates bits):</dt>
            <dd pn="section-4.3.1-7.2"> Indicates the type of the link identifier.</t>

        <t hangText="Reserved identifier.</dd>
            <dt pn="section-4.3.1-7.3">Reserved (24 bits):"> Reserved bits):</dt>
            <dd pn="section-4.3.1-7.4">Reserved for future use and SHOULD <bcp14>SHOULD</bcp14>
        be zeroed and ignored on receipt.</t>

	<t hangText="Link Identifier:"> When receipt.</dd>
            <dt pn="section-4.3.1-7.5">Link Identifier:</dt>
            <dd pn="section-4.3.1-7.6">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>

	<t> encoded.</dd>
          </dl>
          <t pn="section-4.3.1-8">
   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" sectionFormat="of" derivedContent="RFC4204"/> (see <xref target="sect-8.14"/>
   for the request to update the target="LMP-PARAM" format="default" sectionFormat="of" derivedContent="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" sectionFormat="of" derivedContent="Section 8.14"/>.</t>
        </section>
        <section title="Wavelength Restriction Field" anchor="sect-4.3.2"><t> anchor="sect-4.3.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-wavelength-constraint-field">Wavelength Constraint Field</name>
          <t pn="section-4.3.2-1">
   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6" derivedContent="RFC7579"/> with the base label encoded as a 32 bit 32-bit LSC
   label, as defined in <xref target="RFC6205"/>. target="RFC6205" format="default" sectionFormat="of" derivedContent="RFC6205"/>.  The Label Set format is repeated here
   for convenience, with the base label internal structure included.
   See <xref target="RFC6205"/> target="RFC6205" format="default" sectionFormat="of" derivedContent="RFC6205"/> 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" sectionFormat="of" derivedContent="RFC7579"/> for the details of each action.</t>

	<figure><artwork><![CDATA[
          <figure anchor="fig-7.1" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-wavelength-constraint-field-2">Wavelength Constraint Field</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.3.2-2.1">
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>
</artwork>
          </figure>

<t> Action
          <dl newline="true" spacing="normal" pn="section-4.3.2-3">
            <dt pn="section-4.3.2-3.1">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 pn="section-4.3.2-3.2">
              <dl newline="false" spacing="normal" pn="section-4.3.2-3.2.1">
                <dt pn="section-4.3.2-3.2.1.1">0:</dt>
                <dd pn="section-4.3.2-3.2.1.2">Inclusive List</dd>
                <dt pn="section-4.3.2-3.2.1.3">1:</dt>
                <dd pn="section-4.3.2-3.2.1.4">Exclusive List</dd>
                <dt pn="section-4.3.2-3.2.1.5">2:</dt>
                <dd pn="section-4.3.2-3.2.1.6">Inclusive Range</dd>
                <dt pn="section-4.3.2-3.2.1.7">3:</dt>
                <dd pn="section-4.3.2-3.2.1.8">Exclusive Range</dd>
                <dt pn="section-4.3.2-3.2.1.9">4:</dt>
                <dd pn="section-4.3.2-3.2.1.10">Bitmap Set</dd>
              </dl>
            </dd>
            <dt pn="section-4.3.2-3.3">Num Labels (12 bits):"> bits):</dt>
            <dd pn="section-4.3.2-3.4"> It is generally the number of
	labels. It has a specific meaning depending on the action value.</t>

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

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

	<t> ignore.</dd>
          </dl>
          <t pn="section-4.3.2-4">
   See Sections 2.6.1 - 2.6.3 of <xref target="RFC7579"/> target="RFC7579" section="2.6.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6.1" derivedContent="RFC7579"/>-<xref target="RFC7579" section="2.6.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6.3" derivedContent="RFC7579"/> of <xref target="RFC7579" format="default" sectionFormat="of" derivedContent="RFC7579"/> for details on additional
   field discussion for each action.</t>
        </section>
      </section>
      <section title="Signal anchor="sect-4.4" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-signal-processing-capabilit">Signal Processing Capability Restrictions" anchor="sect-4.4"><t> Restrictions</name>
        <t pn="section-4.4-1">
   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>
        <t pn="section-4.4-2">
   The supported signal processing capabilities considered in the RWA
   Information Model <xref target="RFC7446"/> target="RFC7446" format="default" sectionFormat="of" derivedContent="RFC7446"/> are:

	<list style="symbols">
	<t>Optical
        </t>
        <ul spacing="normal" bare="false" empty="false" pn="section-4.4-3">
          <li pn="section-4.4-3.1">Optical Interface Class List</t>

	<t>Bit Rate</t>

	<t>Client Signal</t>

	</list>
	</t>

	<t> List</li>
          <li pn="section-4.4-3.2">Bit Rate</li>
          <li pn="section-4.4-3.3">Client Signal</li>
        </ul>
        <t pn="section-4.4-4">
   The Bit Rate bit rate restriction is already expressed in <xref
   target="PCEP-GMPLS"/> in the BANDWIDTH object.</t>

	<t> object in <xref target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8779"/>.</t>
        <t pn="section-4.4-5">
   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" bare="false" empty="false" pn="section-4.4-6">
          <li pn="section-4.4-6.1">Client Signal TLV</t>

	<t>Optical Information TLV</li>
          <li pn="section-4.4-6.2">Optical Interface Class List TLV</t>

	</list>
	</t>

	<t> TLV</li>
        </ul>
        <t pn="section-4.4-7">
   The END-POINTS type generalized endpoint Generalized Endpoint is extended as follows:</t>

	<figure><artwork><![CDATA[
<endpoint-restriction>
        <sourcecode type="rbnf" markers="false" pn="section-4.4-8">
&lt;endpoint-restriction&gt; ::=
                      <LABEL-REQUEST> <label-restriction-list>

<label-restriction-list>
                      &lt;LABEL-REQUEST&gt; &lt;label-restriction-list&gt;

&lt;label-restriction-list&gt; ::= <label-restriction>
                             [<label-restriction-list>]

<label-restriction> &lt;label-restriction&gt;
                             [&lt;label-restriction-list&gt;]

&lt;label-restriction&gt; ::= (<LABEL-SET>|
                        [<Wavelength Restriction Constraint>]
                        [<signal-compatibility-restriction>])
Where

<signal-compatibility-restriction> (&lt;LABEL-SET&gt;|
                        [&lt;Wavelength Restriction&gt;]
                        [&lt;signal-compatibility-restriction&gt;])
</sourcecode>
        <t pn="section-4.4-9">Where:</t>
        <sourcecode type="rbnf" markers="false" pn="section-4.4-10">
&lt;signal-compatibility-restriction&gt; ::=
    [<Optical
    [&lt;Optical Interface Class List>] [<Client Signal>]

]]></artwork>
	</figure>

        <t> List&gt;] [&lt;Client Signal Information&gt;]
</sourcecode>
        <t pn="section-4.4-11">
   The Wavelength Restriction Constraint TLV is defined in Section 4.3.</t>

	<t> <xref target="sect-4.3" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
        <t pn="section-4.4-12">
   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>

	<t> target="RFC7581" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.1" derivedContent="RFC7581"/>.</t>
        <t pn="section-4.4-13">
   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.2" derivedContent="RFC7581"/>.</t>
        <section title="Signal anchor="sect-4.4.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.1">
          <name slugifiedName="name-signal-processing-exclusion">Signal Processing Exclusion" anchor="sect-4.4.1"><t> Exclusion</name>
          <t pn="section-4.4.1-1">
   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" sectionFormat="of" derivedContent="RFC5521"/> defines how the Exclude Route
   Object (XRO) subobject is used. In this draft, document, we add two new XRO
   Signal Processing Exclusion Subobjects.</t>

	<t> subobjects.</t>
          <t pn="section-4.4.1-2">
   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" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-optical-interface-class-lis">Optical Interface Class List XRO Subobject" anchor="fig-5"><artwork><![CDATA[ Subobject</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.4.1-3.1">
 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>
</artwork>
          </figure>
	<t>
          <t pn="section-4.4.1-4">
   Refer to <xref target="RFC5521"/> target="RFC5521" format="default" sectionFormat="of" derivedContent="RFC5521"/> for the definition definitions of
   X, Length Length, and Attribute.</t>

	<t>
   Type
          <dl newline="false" spacing="normal" pn="section-4.4.1-5">
            <dt pn="section-4.4.1-5.1">Type (7 bits): The Type bits):</dt>
            <dd pn="section-4.4.1-5.2">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 pn="section-4.4.1-5.3">Reserved bits (8 bits) bits):</dt>
            <dd pn="section-4.4.1-5.4">These are for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed and
   ignored on receipt.</t>

	<t>
   The Attribute field receipt.</dd>
            <dt pn="section-4.4.1-5.5">Attribute (8 bits): <xref target="RFC5521"/> bits):</dt>
            <dd pn="section-4.4.1-5.6">
              <xref target="RFC5521" format="default" sectionFormat="of" derivedContent="RFC5521"/> 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 pn="section-4.4.1-5.7">Optical Interface Class List List:</dt>
            <dd pn="section-4.4.1-5.8">This field is encoded as
   described in Section
   4.1 of <xref target="RFC7581"/>.</t>

	<t> target="RFC7581" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.1" derivedContent="RFC7581"/>.</dd>
          </dl>
          <t pn="section-4.4.1-6">
   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" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-client-signal-information-x">Client Signal Information XRO Subobject" anchor="fig-6"><artwork><![CDATA[ Subobject</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.4.1-7.1">
 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>
</artwork>
          </figure>
	<t>
          <t pn="section-4.4.1-8">
   Refer to <xref target="RFC5521"/> target="RFC5521" format="default" sectionFormat="of" derivedContent="RFC5521"/> for the definition definitions of
   X, Length Length, and Attribute.</t>

   <t>Type
          <dl newline="false" spacing="normal" pn="section-4.4.1-9">
            <dt pn="section-4.4.1-9.1">Type (7 bits): The Type bits):</dt>
            <dd pn="section-4.4.1-9.2">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 pn="section-4.4.1-9.3">Reserved bits (8 bits) bits):</dt>
            <dd pn="section-4.4.1-9.4">These are for future use and SHOULD <bcp14>SHOULD</bcp14> be zeroed and
   ignored on receipt.</t>

   <t>The Attribute field receipt.</dd>
            <dt pn="section-4.4.1-9.5">Attribute (8 bits): [RFC5521] bits):</dt>
            <dd pn="section-4.4.1-9.6">
              <xref target="RFC5521" format="default" sectionFormat="of" derivedContent="RFC5521"/> 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 pn="section-4.4.1-9.7">Client Signal Information Information:</dt>
            <dd pn="section-4.4.1-9.8">This field is encoded as described
   in Section 4.2
   of <xref target="RFC7581"/>.</t>

	<t> target="RFC7581" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.2" derivedContent="RFC7581"/>.</dd>
          </dl>
          <t pn="section-4.4.1-10">
   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" bare="false" spacing="normal" pn="section-4.4.1-11">
            <li pn="section-4.4.1-11.1">
              <dl spacing="normal" newline="false" pn="section-4.4.1-11.1.1">
                <dt pn="section-4.4.1-11.1.1.1">8:</dt>
                <dd pn="section-4.4.1-11.1.1.2">Optical Interface Class List

      TBD10     Client List</dd>
                <dt pn="section-4.4.1-11.1.1.3">9:</dt>
                <dd pn="section-4.4.1-11.1.1.4">Client Signal Information

]]></artwork>
	</figure> Information</dd>
              </dl>
            </li>
          </ul>
        </section>
        <section title="Signal anchor="sect-4.4.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.2">
          <name slugifiedName="name-signal-processing-inclusion">Signal Processing Inclusion" anchor="sect-4.4.2"><t> Inclusion</name>
          <t pn="section-4.4.2-1">
   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" sectionFormat="of" derivedContent="RFC5440"/> defines how the Include Route Object (IRO) subobject is used.
   In this draft, document, we add two new Signal Processing Inclusion
   Subobjects.</t>

	<t>
   subobjects.</t>
          <t pn="section-4.4.2-2">
   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" sectionFormat="of" derivedContent="RFC5440"/>:</t>
          <ul empty="true" bare="false" spacing="normal" pn="section-4.4.2-3">
            <li pn="section-4.4.2-3.1">
              <dl newline="false" spacing="normal" pn="section-4.4.2-3.1.1">
                <dt pn="section-4.4.2-3.1.1.1">8:</dt>
                <dd pn="section-4.4.2-3.1.1.2">Optical Interface Class List

      TBD12     Client List</dd>
                <dt pn="section-4.4.2-3.1.1.3">9:</dt>
                <dd pn="section-4.4.2-3.1.1.4">Client Signal Information
]]></artwork>
	</figure>

	<t> Information</dd>
              </dl>
            </li>
          </ul>
          <t pn="section-4.4.2-4">
   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" sectionFormat="of" derivedContent="Section 4.4.1"/> 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" sectionFormat="of" derivedContent="RFC3209"/>.</t>
        </section>
      </section>
    </section>
    <section title="Encoding anchor="sect-5" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-encoding-of-an-rwa-path-rep">Encoding of a an RWA Path Reply" anchor="sect-5"><t> Reply</name>
      <t pn="section-5-1">
   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" sectionFormat="of" derivedContent="Section 4"/>.</t>
      <section title="Wavelength anchor="sect-5.1" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-wavelength-allocation-tlv">Wavelength Allocation TLV" anchor="sect-5.1"><t> TLV</name>
        <t pn="section-5.1-1">
   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)" start="1" pn="section-5.1-2">
          <li pn="section-5.1-2.1" derivedCounter="(a)">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 pn="section-5.1-2.2" derivedCounter="(b)">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>

	<t> path.</li>
        </ol>
        <t pn="section-5.1-3">
   Option (b) allows distributed label allocation (performed during
   signaling) to complete wavelength allocation.</t>

	<t>
        <t pn="section-5.1-4">
   The type for the Wavelength Allocation TLV type is TBD4 (See 10 (see <xref target="sect-8.4"/>). target="sect-8.4" format="default" sectionFormat="of" derivedContent="Section 8.4"/>). 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" align="left" suppress-title="false" pn="figure-11">
          <name slugifiedName="name-wavelength-allocation-tlv-e">Wavelength Allocation TLV Encoding" anchor="fig-7"><artwork><![CDATA[ Encoding</name>
          <artwork name="" type="" align="left" alt="" pn="section-5.1-5.1">
 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>
</artwork>
        </figure>

	<t><list style="symbols">

	  <t>Reserved
        <dl newline="false" spacing="normal" pn="section-5.1-6">
          <dt pn="section-5.1-6.1">Reserved (16 bits): Reserved bits):</dt>
          <dd pn="section-5.1-6.2">Reserved for future use.</t>

	  <t>Flags use.</dd>
          <dt pn="section-5.1-6.3">Flags field (16 bits)</t>

	</list>
	</t>

	<t>
   One bits):</dt>
          <dd pn="section-5.1-6.4">
            <t pn="section-5.1-6.4.1">One flag bit is allocated as follows:

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

	<t>0 indicates follows:</t>
            <dl newline="false" spacing="normal" pn="section-5.1-6.4.2">
              <dt pn="section-5.1-6.4.2.1">M (1 bit):</dt>
              <dd pn="section-5.1-6.4.2.2">
                <t pn="section-5.1-6.4.2.2.1">Wavelength Allocation Mode.</t>
                <dl newline="false" spacing="normal" pn="section-5.1-6.4.2.2.2">
                  <dt pn="section-5.1-6.4.2.2.2.1">0:</dt>
                  <dd pn="section-5.1-6.4.2.2.2.2">Indicates the allocation is under Explicit relies on the use of Label Control.</t>

	<t>1 indicates Sets.</dd>
                  <dt pn="section-5.1-6.4.2.2.2.3">1:</dt>
                  <dd pn="section-5.1-6.4.2.2.2.4">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 pn="section-5.1-6.4.3">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 pn="section-5.1-6.5">Link Identifier:</dt>
          <dd pn="section-5.1-6.6">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" sectionFormat="of" derivedContent="Section 4.3.1"/> for encoding of the Link Identifier encoding.</t>

	  <t hangText="Allocated Wavelength(s):"> field.</dd>
          <dt pn="section-5.1-6.7">Allocated Wavelength(s):</dt>
          <dd pn="section-5.1-6.8"> 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" sectionFormat="of" derivedContent="Section 4.3.2"/>
          for encoding details.</t>

	</list>
	</t>

	<t> details.</dd>
        </dl>
        <t pn="section-5.1-7">
   This TLV is carried in a PCRep message as an attribute Attribute TLV <xref target="RFC5420"/> target="RFC5420" format="default" sectionFormat="of" derivedContent="RFC5420"/>
   in the Hop Attribute Subobjects subobjects <xref target="RFC7570"/> target="RFC7570" format="default" sectionFormat="of" derivedContent="RFC7570"/> in the ERO Explicit Route Object (ERO) <xref target="RFC5440"/>.</t> target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
      </section>
      <section title="Error Indicator" anchor="sect-5.2"><t> anchor="sect-5.2" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-error-indicator">Error Indicator</name>
        <t pn="section-5.2-1">
   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" bare="false" empty="false" pn="section-5.2-2">
          <li pn="section-5.2-2.1">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 pn="section-5.2-2.2">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 pn="section-5.2-2.3">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="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-no-path-indicator">NO-PATH Indicator</name>
        <t pn="section-5.3-1">
   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" sectionFormat="of" derivedContent="RFC5440"/>.  The object may contain a NO-PATH-VECTOR TLV to provide
   additional information about why a path computation has failed.</t>

	<t>
   One
        <t pn="section-5.3-2">
   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" pn="section-5.3-3">
          <dt pn="section-5.3-3.1">Bit 23:</dt>
          <dd pn="section-5.3-3.2"> 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="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t pn="section-6-1">
   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="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-control-of-function-and-pol">Control of Function and Policy" anchor="sect-6.1"><t> Policy</name>
        <t pn="section-6.1-1">
   In addition to the parameters already listed in Section 8.1 of <xref target="RFC5440"/>, target="RFC5440" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.1" derivedContent="RFC5440"/>, 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" bare="false" empty="false" pn="section-6.1-2">
          <li pn="section-6.1-2.1">The ability to send a WSON RWA request.</t>

	</list>
	</t>

	<t> request.</li>
        </ul>
        <t pn="section-6.1-3">
   In addition to the parameters already listed in Section 8.1 of <xref target="RFC5440"/>, target="RFC5440" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.1" derivedContent="RFC5440"/>, 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" bare="false" empty="false" pn="section-6.1-4">
          <li pn="section-6.1-4.1">The support for WSON RWA.</t>

	  <t>A RWA.</li>
          <li pn="section-6.1-4.2">A set of WSON RWA specific WSON-RWA-specific policies (authorized sender, request
	  rate limiter, etc).</t>

	</list>
	</t>

	<t> etc).</li>
        </ul>
        <t pn="section-6.1-5">
   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="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-liveness-detection-and-moni">Liveness Detection and Monitoring" anchor="sect-6.2"><t> Monitoring</name>
        <t pn="section-6.2-1">
   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.3" derivedContent="RFC5440"/>.</t>
      </section>
      <section title="Verifying anchor="sect-6.3" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-verifying-correct-operation">Verifying Correct Operation" anchor="sect-6.3"><t> Operation</name>
        <t pn="section-6.3-1">
   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.4" derivedContent="RFC5440"/>.</t>
      </section>
      <section title="Requirements anchor="sect-6.4" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-requirements-on-other-proto">Requirements on Other Protocols and Functional Components" anchor="sect-6.4"><t> Components</name>
        <t pn="section-6.4-1">
   The PCEP Link-State mechanism <xref target="PCEP-LS"/> target="I-D.lee-pce-pcep-ls-optical" format="default" sectionFormat="of" derivedContent="PCEP-LS"/> may be used to advertise
   WSON RWA path computation capabilities to PCCs.</t>
      </section>
      <section title="Impact anchor="sect-6.5" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-impact-on-network-operation">Impact on Network Operation" anchor="sect-6.5"><t> Operation</name>
        <t pn="section-6.5-1">
   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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.6" derivedContent="RFC5440"/>.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-7"><t> anchor="sect-7" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-7-1">
   The security considerations discussed in <xref target="RFC5440"/> target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> 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" sectionFormat="of" derivedContent="RFC8253"/> <bcp14>SHOULD</bcp14> be used.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-8-1">
   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="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-new-pcep-object-wavelength-">New PCEP Object: Wavelength Assignment Object" anchor="sect-8.1"><t> Object</name>
        <t pn="section-8.1-1">
   As described in <xref target="sect-4.1"/>, target="sect-4.1" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:</t>
        <table align="left" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Object-Class Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Object-Type</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">42</td>
              <td align="left" colspan="1" rowspan="1">WA</td>
              <td align="left" colspan="1" rowspan="1">0: Reserved</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">1: Wavelength Assignment   [This.I-D]
]]></artwork>
	</figure> Assignment</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="WA anchor="sect-8.2" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-wa-object-flag-field">WA Object Flag Field" anchor="sect-8.2"><t> Field</name>
        <t pn="section-8.2-1">
   As described in <xref target="sect-4.1"/>, target="sect-4.1" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, 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" format="default" sectionFormat="of" derivedContent="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" sectionFormat="of" derivedContent="RFC8126"/>. Each bit should
   be tracked with the following qualities:</t>

	<t><list style="symbols">

	  <t>Bit
        <ul spacing="normal" bare="false" empty="false" pn="section-8.2-2">
          <li pn="section-8.2-2.1">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 pn="section-8.2-2.2">Capability description</li>
          <li pn="section-8.2-2.3">Defining RFC</li>
        </ul>
        <t pn="section-8.2-3">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" pn="table-2">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0-14</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">15</td>
              <td align="left" colspan="1" rowspan="1">Wavelength Allocation Mode</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.3" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-new-pcep-tlv-wavelength-sel">New PCEP TLV: Wavelength Selection TLV" anchor="sect-8.3"><t>
   As described in TLV</name>
        <t pn="section-8.3-1">
   In <xref target="sect-4.2"/>, target="sect-4.2" format="default" sectionFormat="of" derivedContent="Section 4.2"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:</t>
        <table align="left" pn="table-3">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">Wavelength Selection</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.4" numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-new-pcep-tlv-wavelength-res">New PCEP TLV: Wavelength Restriction Constraint TLV" anchor="sect-8.4"><t>
   As described in TLV</name>
        <t pn="section-8.4-1">
   In <xref target="sect-4.3"/>, target="sect-4.3" format="default" sectionFormat="of" derivedContent="Section 4.3"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD3              Wavelength Restriction     [This.I-D]
                  Constraint
]]></artwork>
	</figure>
        <table align="left" pn="table-4">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">Wavelength Restriction</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Wavelength anchor="sect-8.5" numbered="true" toc="include" removeInRFC="false" pn="section-8.5">
        <name slugifiedName="name-wavelength-restriction-tlv-a">Wavelength Restriction Constraint TLV Action Values" anchor="sect-8.5"><t> Values</name>
        <t pn="section-8.5-1">
   As described in <xref target="sect-4.3"/>, target="sect-4.3" format="default" sectionFormat="of" derivedContent="Section 4.3"/>, 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" format="default" sectionFormat="of" derivedContent="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" sectionFormat="of" derivedContent="RFC8126"/>. Each value should be tracked with the following
   qualities: value, meaning, and defining RFC. The following values
   are defined in </t>
        <ul spacing="normal" bare="false" empty="false" pn="section-8.5-2">
          <li pn="section-8.5-2.1">Value</li>
          <li pn="section-8.5-2.2">Meaning</li>
          <li pn="section-8.5-2.3">Defining RFC</li>
        </ul>
        <t pn="section-8.5-3">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" pn="table-5">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">Inclusive List</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">Inclusive Range</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">2-255</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.6" numbered="true" toc="include" removeInRFC="false" pn="section-8.6">
        <name slugifiedName="name-new-pcep-tlv-wavelength-all">New PCEP TLV: Wavelength Allocation TLV" anchor="sect-8.6"><t>
   As described in TLV</name>
        <t pn="section-8.6-1">
   In <xref target="sect-5.1"/>, target="sect-5.1" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD4              Wavelength Allocation      [This.I-D]
]]></artwork>
	</figure>
        <table align="left" pn="table-6">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">Wavelength Allocation</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Wavelength anchor="sect-8.7" numbered="true" toc="include" removeInRFC="false" pn="section-8.7">
        <name slugifiedName="name-wavelength-allocation-tlv-f">Wavelength Allocation TLV Flag Field" anchor="sect-8.7"><t> Field</name>
        <t pn="section-8.7-1">
   As described in <xref target="sect-5.1"/>, target="sect-5.1" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, IANA is to allocate has
   created a registry new "Wavelength Allocation TLV Flag Field" subregistry under the
   "Path Computation Element Protocol (PCEP) Numbers" registry <xref target="PCEP-NUMBERS" format="default" sectionFormat="of" derivedContent="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" sectionFormat="of" derivedContent="RFC8126"/>.  Each bit should
   be tracked with the following qualities:</t>

	<t><list style="symbols">

	  <t>Bit
        <ul spacing="normal" bare="false" empty="false" pn="section-8.7-2">
          <li pn="section-8.7-2.1">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 pn="section-8.7-2.2">Capability description</li>
          <li pn="section-8.7-2.3">Defining RFC</li>
        </ul>
        <t pn="section-8.7-3">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" pn="table-7">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0-14</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">15</td>
              <td align="left" colspan="1" rowspan="1">Wavelength Allocation Mode    [This.I-D]
]]></artwork>
	</figure> Mode</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.8" numbered="true" toc="include" removeInRFC="false" pn="section-8.8">
        <name slugifiedName="name-new-pcep-tlv-optical-interf">New PCEP TLV: Optical Interface Class List TLV" anchor="sect-8.8"><t>
   As described in TLV</name>
        <t pn="section-8.8-1">
   In <xref target="sect-4.4"/>, target="sect-4.4" format="default" sectionFormat="of" derivedContent="Section 4.4"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD5              Optical
        <table align="left" pn="table-8">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">11</td>
              <td align="left" colspan="1" rowspan="1">Optical Interface          [This.I-D] Class List
]]></artwork>
	</figure> List</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.9" numbered="true" toc="include" removeInRFC="false" pn="section-8.9">
        <name slugifiedName="name-new-pcep-tlv-client-signal-">New PCEP TLV: Client Signal TLV" anchor="sect-8.9"><t>
   As described in Information TLV</name>
        <t pn="section-8.9-1">
   In <xref target="sect-4.4"/>, target="sect-4.4" format="default" sectionFormat="of" derivedContent="Section 4.4"/>, 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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
        </t>

	<figure><artwork><![CDATA[
Value             Description                Reference
---------------------------------------------------------
TBD6              Client
        <table align="left" pn="table-9">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">Client Signal Information  [This.I-D]
]]></artwork>
	</figure> Information</td>
              <td align="left" colspan="1" rowspan="1">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="include" removeInRFC="false" pn="section-8.10">
        <name slugifiedName="name-new-bit-flag-for-no-path-ve">New Bit Flag for NO-PATH-VECTOR TLV</name>
        <t pn="section-8.10-1">
   In <xref target="sect-5.3"/>, target="sect-5.3" format="default" sectionFormat="of" derivedContent="Section 5.3"/>, 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>
        <t pn="section-8.10-2">
   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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
</t>
        <table align="left" pn="table-10">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">23</td>
              <td align="left" colspan="1" rowspan="1">No RWA constraints met     [This.I-D]
]]></artwork>
	</figure> met</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.11" numbered="true" toc="include" removeInRFC="false" pn="section-8.11">
        <name slugifiedName="name-new-error-types-and-error-v">New Error-Types and Error-Values" anchor="sect-8.11"><t>
   As described in Error-Values</name>
        <t pn="section-8.11-1">
   In <xref target="sect-5.2"/>, target="sect-5.2" format="default" sectionFormat="of" derivedContent="Section 5.2"/>, new PCEP error
   codes are defined for WSON RWA errors. IANA is to allocate from has made the following allocations
   in the ""PCEP-ERROR "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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:</t>
        <table align="left" pn="table-11">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Error-Type</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Error-value</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">27</td>
              <td align="left" colspan="1" rowspan="1">WSON RWA Error    0: Unassigned        [This.I-D]

                              1: error</td>
              <td align="left" colspan="1" rowspan="1">0: Unassigned</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">1: Insufficient      [This.I-D]
                                 Memory

                              2: memory</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">2: RWA computation   [This.I-D]
                                 Not supported

                              3: not supported</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">3: Syntactical       [This.I-D]
                                 Encoding error

                              4-255: Unassigned    [This.I-D]
]]></artwork>
	</figure> encoding error</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">4-255: Unassigned</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.12" numbered="true" toc="include" removeInRFC="false" pn="section-8.12">
        <name slugifiedName="name-new-subobjects-for-the-excl">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 pn="section-8.12-1">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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>. Per <xref target="sect-4.4.1" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/>, 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" pn="table-12">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">Optical Interface Class List     [This.I-D]

TBD10           Client List</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">Client Signal Information        [This.I-D]

]]></artwork>
	</figure> Information</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New anchor="sect-8.13" numbered="true" toc="include" removeInRFC="false" pn="section-8.13">
        <name slugifiedName="name-new-subobjects-for-the-incl">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 pn="section-8.13-1">
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" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>.  Per <xref target="sect-4.4.2" format="default" sectionFormat="of" derivedContent="Section 4.4.2"/>, 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" pn="table-13">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">Optical Interface Class List     [This.I-D]

TBD12         Client List</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">Client Signal Information        [This.I-D]
]]></artwork>
	</figure> Information</td>
              <td align="left" colspan="1" rowspan="1">RFC 8780</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Request anchor="sect-8.14" numbered="true" toc="include" removeInRFC="false" pn="section-8.14">
        <name slugifiedName="name-request-for-updated-note-fo">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 pn="section-8.14-1">
   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 target="RFC4204" format="default" sectionFormat="of" derivedContent="RFC4204"/>. As discussed in <xref target="sect-4.3.1" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>, IANA has added the following note at the top of the
   "TE_LINK Object Class Type type name space": <eref target="https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15"/> is requested for the updated
   introductory note that the space (Value 11)" registry <xref target="LMP-PARAM" format="default" sectionFormat="of" derivedContent="LMP-PARAM"/>:
</t>
        <ul empty="true" bare="false" spacing="normal" pn="section-8.14-2">
          <li pn="section-8.14-2.1">
These values have additional usage for the Link Identifier Type field.</t>

	</section> field.
</li>
        </ul>
      </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>
    <displayreference target="I-D.lee-pce-pcep-ls-optical" to="PCEP-LS"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references title="Normative References">
	&RFC2119;
	&RFC3209;
	&RFC3630;
	&RFC5329;
	&RFC5440;
	&RFC6205;
	&RFC7570;
	&RFC7579;
	&RFC7581;
	&RFC7689;
	&RFC7688;
	&RFC8174;
	&RFC8253; pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor='PCEP-GMPLS'> anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
<title>PCEP extensions
            <title>Key words for GMPLS</title> use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author initials='C' surname='Margaria' fullname='Cyril Margaria'> initials="D." surname="Awduche" fullname="D. Awduche">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='O' surname='Dios' fullname='Oscar de Dios'> initials="L." surname="Berger" fullname="L. Berger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Gan" fullname="D. Gan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='F' surname='Zhang' fullname='Fatai Zhang'> initials="G." surname="Swallow" fullname="G. Swallow">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='December' day='12' year='2019' />

<abstract><t>A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized year="2001" month="December"/>
            <abstract>
              <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (GMPLS) networks.  Additional requirements for GMPLS are (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified in RFC7025.  This memo provides extensions to by the Path Computation Element communication Protocol (PCEP) for label applied at the support ingress node of the GMPLS control plane to address those requirements.</t></abstract> path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name='Work in Progress,' value='draft-ietf-pce-gmpls-pcep-extensions-16' /> name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>

	</references>
	<references title="Informative References">
	&RFC3471;
	&RFC4203;
	&RFC4204;
	&RFC4655;
	&RFC5420;
	&RFC5521;
	&RFC6163;
	&RFC6566;
	&RFC7446;
	&RFC7449;
	&RFC8126;
        <reference anchor='PCEP-LS'> anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3630" quoteTitle="true" derivedAnchor="RFC3630">
          <front>
<title>PCEP Extension for Distribution of Link-State and TE information for Optical Networks</title>
            <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
            <author initials='Y' surname='Lee' fullname='Young Lee'> initials="D." surname="Katz" fullname="D. Katz">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='H' surname='Zheng' fullname='Haomian Zheng'> initials="K." surname="Kompella" fullname="K. Kompella">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='D' surname='Ceccarelli' fullname='Daniele Ceccarelli'> initials="D." surname="Yeung" fullname="D. Yeung">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="September"/>
            <abstract>
              <t>This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3630"/>
          <seriesInfo name="DOI" value="10.17487/RFC3630"/>
        </reference>
        <reference anchor="RFC5329" target="https://www.rfc-editor.org/info/rfc5329" quoteTitle="true" derivedAnchor="RFC5329">
          <front>
            <title>Traffic Engineering Extensions to OSPF Version 3</title>
            <author initials="K." surname="Ishiguro" fullname="K. Ishiguro">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='W' surname='Wang' fullname='Wei Wang'> initials="V." surname="Manral" fullname="V. Manral">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='P' surname='Park' fullname='Peter Park'> initials="A." surname="Davey" fullname="A. Davey">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='B' surname='Yoon' fullname='Bin-Yeong Yoon'> initials="A." surname="Lindem" fullname="A. Lindem" role="editor">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' day='2' year='2019' />

<abstract><t>In order year="2008" month="September"/>
            <abstract>
              <t>This document describes extensions to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely OSPFv3 to support intra-area Traffic Engineering Database (TED). Traditionally this Link State and (TE).  This document extends OSPFv2 TE information to handle IPv6 networks.  A new TLV and several new sub-TLVs are defined to support IPv6 networks.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5329"/>
          <seriesInfo name="DOI" value="10.17487/RFC5329"/>
        </reference>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" quoteTitle="true" derivedAnchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="March"/>
            <abstract>
              <t>This document 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 and path computation replies 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.  PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC6205" target="https://www.rfc-editor.org/info/rfc6205" quoteTitle="true" derivedAnchor="RFC6205">
          <front>
            <title>Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers</title>
            <author initials="T." surname="Otani" fullname="T. Otani" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t>Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been obtained developed and is currently being deployed.</t>
              <t>Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a link state routing protocol (supporting traffic engineering extensions).  This range of technologies including wavelength (or lambda) switching.  For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.  Global wavelength semantics are not considered.</t>
              <t>In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document extends defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6205"/>
          <seriesInfo name="DOI" value="10.17487/RFC6205"/>
        </reference>
        <reference anchor="RFC7570" target="https://www.rfc-editor.org/info/rfc7570" quoteTitle="true" derivedAnchor="RFC7570">
          <front>
            <title>Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)</title>
            <author initials="C." surname="Margaria" fullname="C. Margaria" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Martinelli" fullname="G. Martinelli">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Balls" fullname="S. Balls">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Wright" fullname="B. Wright">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="July"/>
            <abstract>
              <t>RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP).  This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7570"/>
          <seriesInfo name="DOI" value="10.17487/RFC7570"/>
        </reference>
        <reference anchor="RFC7579" target="https://www.rfc-editor.org/info/rfc7579" quoteTitle="true" derivedAnchor="RFC7579">
          <front>
            <title>General Network Element Constraint Encoding for GMPLS-Controlled Networks</title>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Han" fullname="J. Han">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies.  In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.</t>
              <t>This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability.  It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7579"/>
          <seriesInfo name="DOI" value="10.17487/RFC7579"/>
        </reference>
        <reference anchor="RFC7581" target="https://www.rfc-editor.org/info/rfc7581" quoteTitle="true" derivedAnchor="RFC7581">
          <front>
            <title>Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks</title>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Han" fullname="J. Han">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength                           Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.</t>
              <t>This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields.  It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses.  Such encodings can be used to extend GMPLS signaling and routing protocols.  In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7581"/>
          <seriesInfo name="DOI" value="10.17487/RFC7581"/>
        </reference>
        <reference anchor="RFC7688" target="https://www.rfc-editor.org/info/rfc7688" quoteTitle="true" derivedAnchor="RFC7688">
          <front>
            <title>GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks</title>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t>This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements.  These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.</t>
              <t>This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7688"/>
          <seriesInfo name="DOI" value="10.17487/RFC7688"/>
        </reference>
        <reference anchor="RFC7689" target="https://www.rfc-editor.org/info/rfc7689" quoteTitle="true" derivedAnchor="RFC7689">
          <front>
            <title>Signaling Extensions for Wavelength Switched Optical Networks</title>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Xu" fullname="S. Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Martinelli" fullname="G. Martinelli">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Harai" fullname="H. Harai">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t>This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs).  Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes.  This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7689"/>
          <seriesInfo name="DOI" value="10.17487/RFC7689"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8253" target="https://www.rfc-editor.org/info/rfc8253" quoteTitle="true" derivedAnchor="RFC8253">
          <front>
            <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
            <author initials="D." surname="Lopez" fullname="D. Lopez">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Dhody" fullname="D. Dhody">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t>The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP.  The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</t>
              <t>This document updates RFC 5440 in regards to the PCEP initialization phase procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8253"/>
          <seriesInfo name="DOI" value="10.17487/RFC8253"/>
        </reference>
        <reference anchor="RFC8779" target="https://www.rfc-editor.org/info/rfc8779" quoteTitle="true" derivedAnchor="RFC8779">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS</title>
            <author initials="C" surname="Margaria" fullname="Cyril Margaria" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O" surname="Gonzalez de Dios" fullname="Oscar Gonzalez de          Dios" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F" surname="Zhang" fullname="Fatai Zhang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8779"/>
          <seriesInfo name="DOI" value="10.17487/RFC8779"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="LMP-PARAM" target="https://www.iana.org/assignments/lmp-parameters/" quoteTitle="true" derivedAnchor="LMP-PARAM">
          <front>
            <title>Link Management Protocol (LMP) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.lee-pce-pcep-ls-optical" quoteTitle="true" target="https://tools.ietf.org/html/draft-lee-pce-pcep-ls-optical-09" derivedAnchor="PCEP-LS">
          <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 showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Zheng" fullname="Haomian Zheng">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D" surname="Ceccarelli" fullname="Daniele Ceccarelli">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W" surname="Wang" fullname="Wei Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Park" fullname="Peter Park">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Yoon" fullname="Bin-Yeong Yoon">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" day="9" year="2020"/>
            <abstract>
              <t>In order to compute and provide optimal paths, 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>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-lee-pce-pcep-ls-optical-09"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-lee-pce-pcep-ls-optical-09.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="PCEP-NUMBERS" target="https://www.iana.org/assignments/pcep/" quoteTitle="true" derivedAnchor="PCEP-NUMBERS">
          <front>
            <title>Path Computation Element Protocol (PCEP) Numbers</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC3471" target="https://www.rfc-editor.org/info/rfc3471" quoteTitle="true" derivedAnchor="RFC3471">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="January"/>
            <abstract>
              <t>This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS.  Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  This document presents a functional description of the extensions.  Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3471"/>
          <seriesInfo name="DOI" value="10.17487/RFC3471"/>
        </reference>
        <reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4203" quoteTitle="true" derivedAnchor="RFC4203">
          <front>
            <title>OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="October"/>
            <abstract>
              <t>This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4203"/>
          <seriesInfo name="DOI" value="10.17487/RFC4203"/>
        </reference>
        <reference anchor="RFC4204" target="https://www.rfc-editor.org/info/rfc4204" quoteTitle="true" derivedAnchor="RFC4204">
          <front>
            <title>Link Management Protocol (LMP)</title>
            <author initials="J." surname="Lang" fullname="J. Lang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="October"/>
            <abstract>
              <t>For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link.  Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques.  This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links.  Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4204"/>
          <seriesInfo name="DOI" value="10.17487/RFC4204"/>
        </reference>
        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" quoteTitle="true" derivedAnchor="RFC4655">
          <front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ash" fullname="J. Ash">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t>Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks.  Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
              <t>This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.  This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4655"/>
          <seriesInfo name="DOI" value="10.17487/RFC4655"/>
        </reference>
        <reference anchor="RFC5420" target="https://www.rfc-editor.org/info/rfc5420" quoteTitle="true" derivedAnchor="RFC5420">
          <front>
            <title>Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)</title>
            <author initials="A." surname="Farrel" fullname="A. Farrel" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Ayyangar" fullname="A. Ayyangar">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="February"/>
            <abstract>
              <t>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions.  This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP.  That Flags field has eight bits, allowing for eight options to be set.  Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.</t>
              <t>This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements.  Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.</t>
              <t>The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.</t>
              <t>This document replaces and obsoletes the previous version of this work, published as RFC 4420.  The only change is in the encoding of the Type-Length-Variable (TLV) data structures.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5420"/>
          <seriesInfo name="DOI" value="10.17487/RFC5420"/>
        </reference>
        <reference anchor="RFC5521" target="https://www.rfc-editor.org/info/rfc5521" quoteTitle="true" derivedAnchor="RFC5521">
          <front>
            <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions</title>
            <author initials="E." surname="Oki" fullname="E. Oki">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Takeda" fullname="T. Takeda">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="April"/>
            <abstract>
              <t>The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</t>
              <t>When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".</t>
              <t>The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs.  This document presents PCEP extensions for route exclusions.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5521"/>
          <seriesInfo name="DOI" value="10.17487/RFC5521"/>
        </reference>
        <reference anchor="RFC6163" target="https://www.rfc-editor.org/info/rfc6163" quoteTitle="true" derivedAnchor="RFC6163">
          <front>
            <title>Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)</title>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t>This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs).  In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.</t>
              <t>This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6163"/>
          <seriesInfo name="DOI" value="10.17487/RFC6163"/>
        </reference>
        <reference anchor="RFC6566" target="https://www.rfc-editor.org/info/rfc6566" quoteTitle="true" derivedAnchor="RFC6566">
          <front>
            <title>A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments</title>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Martinelli" fullname="G. Martinelli">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="March"/>
            <abstract>
              <t>As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters.  When such alterations result in signal degradation, these processes are usually referred to as "impairments".  These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.</t>
              <t>This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks.  Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation.  This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6566"/>
          <seriesInfo name="DOI" value="10.17487/RFC6566"/>
        </reference>
        <reference anchor="RFC7446" target="https://www.rfc-editor.org/info/rfc7446" quoteTitle="true" derivedAnchor="RFC7446">
          <front>
            <title>Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks</title>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="February"/>
            <abstract>
              <t>This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs).  The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs.  This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments.  Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7446"/>
          <seriesInfo name="DOI" value="10.17487/RFC7446"/>
        </reference>
        <reference anchor="RFC7449" target="https://www.rfc-editor.org/info/rfc7449" quoteTitle="true" derivedAnchor="RFC7449">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment</title>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Martensson" fullname="J. Martensson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Takeda" fullname="T. Takeda">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Tsuritani" fullname="T. Tsuritani">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="February"/>
            <abstract>
              <t>This memo provides application-specific requirements for the Path Communication Computation Element Communication Protocol (PCEP) with Link-State for the support of Wavelength Switched Optical Networks (WSONs).  Lightpath provisioning in WSONs requires a Routing and TE information Wavelength Assignment (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 light path computation.  Requirements for PCEP extensions in support of optical networks.</t></abstract> impairments will be addressed in a separate document.</t>
            </abstract>
          </front>
          <seriesInfo name='Work name="RFC" value="7449"/>
          <seriesInfo name="DOI" value="10.17487/RFC7449"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in Progress,' value='draft-lee-pce-pcep-ls-optical-08' /> the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
      </references>
    </references>
    <section anchor="sect-9" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t pn="section-appendix.a-1">
   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="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Fatai Zhang">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>zhangfatai@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Cyril Margaria">
        <organization showOnFrontPage="true">Nokia Siemens Networks
St Networks</organization>
        <address>
          <postal>
            <street>St. Martin Strasse 76
Munich,   81541
Germany
Phone: +49 76</street>
            <city>Munich</city>
            <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 showOnFrontPage="true">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/>
            <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 showOnFrontPage="true">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="Y." surname="Lee" fullname="Young Lee" role="editor">
        <organization showOnFrontPage="true">Samsung Electronics</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>younglee.tx@gmail.com</email>
        </address>
      </author>
      <author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor" role="editor">
        <organization showOnFrontPage="true">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>
    </section>
  </back>
</rfc>