rfc8780xml2.original.xml   rfc8780.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF nsus="true" docName="draft-ietf-pce-wson-rwa-ext-17" indexInclude="true" ipr="tr
C.2119.xml"> ust200902" number="8780" prepTime="2020-07-21T15:47:03" scripts="Common,Latin" s
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF ortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tru
C.3209.xml"> e" xml:lang="en">
<!ENTITY RFC3630 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext-17" r
C.3630.xml"> el="prev"/>
<!ENTITY RFC5329 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://dx.doi.org/10.17487/rfc8780" rel="alternate"/>
C.5329.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <front>
C.5440.xml"> <title abbrev="PCEP Extension for WSON RWA">The Path Computation Element Com
<!ENTITY RFC6205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF munication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WS
C.6205.xml"> ON) Routing and Wavelength Assignment (RWA)</title>
<!ENTITY RFC7570 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <seriesInfo name="RFC" value="8780" stream="IETF"/>
C.7570.xml"> <author initials="Y." surname="Lee" fullname="Young Lee" role="editor">
<!ENTITY RFC7579 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <organization showOnFrontPage="true">Samsung Electronics</organization>
C.7579.xml"> <address>
<!ENTITY RFC7581 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <postal>
C.7581.xml"> <street/>
<!ENTITY RFC7689 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <city/>
C.7689.xml"> <region/>
<!ENTITY RFC7688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <code/>
C.7688.xml"> <country/>
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </postal>
C.8174.xml"> <email>younglee.tx@gmail.com</email>
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </address>
C.8253.xml"> </author>
<!ENTITY RFC3471 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor" r
C.3471.xml"> ole="editor">
<!ENTITY RFC4203 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <organization showOnFrontPage="true">CTTC</organization>
C.4203.xml"> <address>
<!ENTITY RFC4204 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <postal>
C.4204.xml"> <extaddr>Carl Friedrich Gauss 7</extaddr>
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <street>PMT Ed B4 Av.</street>
C.4655.xml"> <city>Castelldefels</city>
<!ENTITY RFC5420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <region>Barcelona</region>
C.5420.xml"> <code>08860</code>
<!ENTITY RFC5521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <country>Spain</country>
C.5521.xml"> </postal>
<!ENTITY RFC6163 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <phone>+34 936452916</phone>
C.6163.xml"> <email>ramon.casellas@cttc.es</email>
<!ENTITY RFC6566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </address>
C.6566.xml"> </author>
<!ENTITY RFC7446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <date month="07" year="2020"/>
C.7446.xml"> <abstract pn="section-abstract">
<!ENTITY RFC7449 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <t pn="section-abstract-1">
C.7449.xml"> This document provides Path Computation Element Communication
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-wson-rwa-ext-17" category="st
d" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2020-02-05T20:57:21Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc toc="yes"?>
<front>
<title abbrev="PCEP Extension for WSON RWA">PCEP Extension for WSON Routi
ng and Wavelength Assignment</title>
<author initials="Y." surname="Lee" fullname="Young Lee, Editor" role="ed
itor">
<organization>Huawei Technologies</organization>
<address><postal><street>5700 Tennyson Parkway Suite 600</street>
<street>Plano, TX 75024</street>
<street>United States of America</street>
</postal>
<email>leeyoung@huawei.com</email>
</address>
</author>
<author initials="R." surname="Casellas" fullname="Ramon Casellas, Editor
" role="editor">
<organization abbrev="CTTC">Carl Friedrich Gauss 7</organization>
<address><postal><street>CTTC PMT Ed B4 Av.</street>
<street>Castelldefels Barcelona 08860</street>
<street>Spain</street>
</postal>
<phone>(34) 936452916</phone>
<email>ramon.casellas@cttc.es</email>
</address>
</author>
<date year="2020" month="February"/>
<abstract><t>
This document provides the Path Computation Element communication
Protocol (PCEP) extensions for the support of Routing and Wavelength Protocol (PCEP) extensions for the support of Routing and Wavelength
Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Assignment (RWA) in Wavelength Switched Optical Networks (WSONs).
Path provisioning in WSONs requires a routing and wavelength Path provisioning in WSONs requires an RWA process. From a path computation
assignment (RWA) process. From a path computation perspective, perspective,
wavelength assignment is the process of determining which wavelength wavelength assignment is the process of determining which wavelength
can be used on each hop of a path and forms an additional routing can be used on each hop of a path and forms an additional routing
constraint to optical path computation.</t> constraint to optical path computation.</t>
</abstract>
</abstract> <boilerplate>
</front> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<middle> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section title="Terminology" anchor="sect-1"><t> >
This document uses the terminology defined in <xref target="RFC4655"/>, and <t pn="section-boilerplate.1-1">
<xref target="RFC5440"/>.</t> This is an Internet Standards Track document.
</t>
</section> <t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
<section title="Requirements Language" anchor="sect-2"><t> (IETF). It represents the consensus of the IETF community. It has
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", received public review and has been approved for publication by
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and the Internet Engineering Steering Group (IESG). Further
"OPTIONAL" in this document are to be interpreted as described in information on Internet Standards is available in Section 2 of
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RFC 7841.
they appear in all </t>
capitals, as shown here.</t> <t pn="section-boilerplate.1-3">
Information about the current status of this document, any
</section> errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8780" brackets="non
<section title="Introduction" anchor="sect-3"><t> e"/>.
<xref target="RFC5440"/> specifies the Path Computation Element (PCE) Communi </t>
cation </section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.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 derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</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 derivedCon
tent="" 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 derivedCon
tent="" format="title" sectionFormat="of" target="name-requirements-language">Re
quirements 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="titl
e" sectionFormat="of" target="name-encoding-of-an-rwa-path-req">Encoding of an R
WA Path Request</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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" forma
t="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-assignment-wa-ob">Wave
length 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" forma
t="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-selection-tlv">Wavelen
gth 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" forma
t="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-restriction-tlv">Wavel
ength Restriction TLV</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derive
dContent="" 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 derive
dContent="" 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" forma
t="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-signal-processing-capabilit">Sign
al Processing Capability Restrictions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derive
dContent="" format="title" sectionFormat="of" target="name-signal-processing-exc
lusion">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 derive
dContent="" format="title" sectionFormat="of" target="name-signal-processing-inc
lusion">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="titl
e" sectionFormat="of" target="name-encoding-of-an-rwa-path-rep">Encoding of an R
WA Path Reply</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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" forma
t="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-allocation-tlv">Wavele
ngth 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" forma
t="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" forma
t="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-no-path-indicator">NO-PATH Indica
tor</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="titl
e" sectionFormat="of" target="name-manageability-consideration">Manageability Co
nsiderations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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" forma
t="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-control-of-function-and-pol">Cont
rol 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" forma
t="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-liveness-detection-and-moni">Live
ness 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" forma
t="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-verifying-correct-operation">Veri
fying 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" forma
t="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-requirements-on-other-proto">Requ
irements 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" forma
t="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-impact-on-network-operation">Impa
ct 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="titl
e" sectionFormat="of" target="name-security-considerations">Security Considerati
ons</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="titl
e" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xre
f></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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" forma
t="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" forma
t="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wa-object-flag-field">WA Object F
lag 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" forma
t="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" forma
t="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" forma
t="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-restriction-tlv-a">Wav
elength 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" forma
t="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" forma
t="counter" sectionFormat="of" target="section-8.7"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-wavelength-allocation-tlv-f">Wave
length 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" forma
t="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" forma
t="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" for
mat="counter" sectionFormat="of" target="section-8.10"/>. <xref derivedContent="
" format="title" sectionFormat="of" target="name-new-bit-flag-for-no-path-ve">Ne
w 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" for
mat="counter" sectionFormat="of" target="section-8.11"/>. <xref derivedContent="
" format="title" sectionFormat="of" target="name-new-error-types-and-error-v">Ne
w 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" for
mat="counter" sectionFormat="of" target="section-8.12"/>. <xref derivedContent="
" format="title" sectionFormat="of" target="name-new-subobjects-for-the-excl">Ne
w 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" for
mat="counter" sectionFormat="of" target="section-8.13"/>. <xref derivedContent="
" format="title" sectionFormat="of" target="name-new-subobjects-for-the-incl">Ne
w 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" for
mat="counter" sectionFormat="of" target="section-8.14"/>. <xref derivedContent="
" format="title" sectionFormat="of" target="name-request-for-updated-note-fo">Re
quest 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="titl
e" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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" forma
t="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-normative-references">Normative R
eferences</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" forma
t="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-informative-references">Informati
ve 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" s
ectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="t
itle" 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" s
ectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="t
itle" 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" s
ectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="t
itle" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xre
f></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" p
n="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
<xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RF
C5440"/> specifies the Path Computation Element Communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a PCE, or between two PCEs. Such interactions include (PCC) and a PCE, or between two PCEs. Such interactions include
path computation requests and path computation replies as well as Path Computation Requests (PCReqs) and Path Computation Replies (PCReps) as w ell as
notifications of specific states related to the use of a PCE in the notifications of specific states related to the use of a PCE in the
context of Multiprotocol Label Switching (MPLS) and Generalized MPLS context of Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering.</t> (GMPLS) Traffic Engineering (TE).</t>
<t pn="section-1-2">
<t>
A PCC is said to be any network component that makes such a request A PCC is said to be any network component that makes such a request
and may be, for instance, an Optical Switching Element within a and may be, for instance, an optical switching element within a
Wavelength Division Multiplexing (WDM) network. The PCE, itself, Wavelength Division Multiplexing (WDM) network. The PCE, itself,
can be located anywhere within the network, and may be within an can be located anywhere within the network and may be within an
optical switching element, a Network Management System (NMS) or optical switching element, a Network Management System (NMS), or
Operational Support System (OSS), or may be an independent network an Operational Support System (OSS), or it may be an independent network
server.</t> server.</t>
<t pn="section-1-3">
<t>
This document provides the PCEP extensions for the support of This document provides the PCEP extensions for the support of
Routing and Wavelength Assignment (RWA) in Wavelength Switched Routing and Wavelength Assignment (RWA) in Wavelength Switched
Optical Networks (WSON) based on the requirements specified in Optical Networks (WSONs) based on the requirements specified in
<xref target="RFC6163"/> and <xref target="RFC7449"/>.</t> <xref target="RFC6163" format="default" sectionFormat="of" derivedContent="RF
C6163"/> and <xref target="RFC7449" format="default" sectionFormat="of" derivedC
<t> ontent="RFC7449"/>.</t>
WSON refers to WDM based optical networks in which switching is performed <t pn="section-1-4">
WSON refers to WDM-based optical networks in which switching is performed
selectively based on the wavelength of an optical signal. The devices used selectively based on the wavelength of an optical signal. The devices used
in WSONs that are able to switch signals based on signal wavelength are in WSONs that are able to switch signals based on signal wavelength are
known as Lambda Switch Capable (LSC). WSONs can be transparent or known as Lambda Switch Capable (LSC). WSONs can be transparent or
translucent. A transparent optical network is made up of optical devices translucent. A transparent optical network is made up of optical devices
that can switch but not convert from one wavelength to another, all within that can switch but not convert from one wavelength to another, all within
the optical domain. On the other hand, translucent networks include 3R the optical domain. On the other hand, translucent networks include 3R
regenerators (Re-amplification, Re-shaping, Re-timing) that are sparsely regenerators (reamplification, reshaping, and retiming) that are sparsely
placed. The main function of the 3R regenerators is to convert one optical placed. The main function of the 3R regenerators is to convert one optical
wavelength to another.</t> wavelength to another.</t>
<t pn="section-1-5">
<t> An LSC Label Switched Path (LSP) may span one
A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one
or several transparent segments, which are delimited by 3R or several transparent segments, which are delimited by 3R
regenerators typically with electronic regenerator and optional regenerators typically with electronic regenerator and optional
wavelength conversion. Each transparent segment or path in WSON is wavelength conversion. Each transparent segment or path in WSON is
referred to as an optical path. An optical path may span multiple referred to as an optical path. An optical path may span multiple
fiber links and the path should be assigned the same wavelength for fiber links, and the path should be assigned the same wavelength for
each link. In such case, the optical path is said to satisfy the each link. In a case, the optical path is said to satisfy the
wavelength-continuity constraint. <xref target="fig-1"/> illustrates the wavelength-continuity constraint. <xref target="fig-1" format="default" secti
relationship between a LSC LSP and transparent segments (optical onFormat="of" derivedContent="Figure 1"/> illustrates the
relationship between an LSC LSP and transparent segments (optical
paths).</t> paths).</t>
<figure anchor="fig-1" align="left" suppress-title="false" pn="figure-1">
<figure title="Illustration of a LSC LSP and transparent segments" anchor <name slugifiedName="name-illustration-of-an-lsc-lsp-">Illustration of a
="fig-1"><artwork><![CDATA[ n LSC LSP and Transparent Segments</name>
<artwork name="" type="" align="left" alt="" pn="section-1-6.1">
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
| |I1 | | | | | | I2| | | |I1 | | | | | | I2| |
| |o------| |-------[(3R) ]------| |--------o| | | |o------| |-------[(3R) ]------| |--------o| |
| | | | | | | | | | | | | | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
(X LSC) (LSC LSC) (LSC LSC) (LSC X) (X LSC) (LSC LSC) (LSC LSC) (LSC X)
<-------> <-------> <-----> <-------> &lt;-------&gt; &lt;-------&gt; &lt;-----&gt; &lt;-------&gt;
<-----------------------><----------------------> &lt;-----------------------&gt;&lt;----------------------&gt;
Transparent Segment Transparent Segment Transparent Segment Transparent Segment
<-------------------------------------------------&gt; <-------------------------------------------------&gt;
LSC LSP LSC LSP
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-1-7">
Note that two transparent segments within a WSON LSP do not need to Note that two transparent segments within a WSON LSP do not need to
operate on the same wavelength (due to the wavelength conversion operate on the same wavelength (due to wavelength conversion
capabilities). Two optical channels that share a common fiber link capabilities). Two optical channels that share a common fiber link
cannot be assigned the same wavelength; Otherwise, the two signals cannot be assigned the same wavelength; otherwise, the two signals
would interfere with each other. Note that advanced additional would interfere with each other. Note that advanced additional
multiplexing techniques such as polarization based multiplexing are multiplexing techniques such as polarization-based multiplexing are
not addressed in this document since the physical layer aspects are not addressed in this document since the physical-layer aspects are
not currently standardized. Therefore, assigning the proper not currently standardized. Therefore, assigning the proper
wavelength on a path is an essential requirement in the optical path wavelength on a path is an essential requirement in the optical path
computation process.</t> computation process.</t>
<t pn="section-1-8">
<t>
When a switching node has the ability to perform wavelength When a switching node has the ability to perform wavelength
conversion, the wavelength-continuity constraint can be relaxed, and conversion, the wavelength-continuity constraint can be relaxed, and
a LSC Label Switched Path (LSP) may use different wavelengths on an LSP may use different wavelengths on
different links along its route from origin to destination. It is, different links along its route from origin to destination. It is,
however, to be noted that wavelength converters may be limited due however, to be noted that wavelength converters may be limited due
to their relatively high cost, while the number of WDM channels that to their relatively high cost, while the number of WDM channels that
can be supported in a fiber is also limited. As a WSON can be can be supported in a fiber is also limited. As a WSON can be
composed of network nodes that cannot perform wavelength conversion, composed of network nodes that cannot perform wavelength conversion,
nodes with limited wavelength conversion, and nodes with full nodes with limited wavelength conversion, and nodes with full
wavelength conversion abilities, wavelength assignment is an wavelength conversion abilities, wavelength assignment is an
additional routing constraint to be considered in all optical path additional routing constraint to be considered in all optical path
computation.</t> computation.</t>
<t pn="section-1-9">
<t> For example (see <xref target="fig-1" format="default" sectionFormat="of" der
For example (see <xref target="fig-1"/>), within a translucent WSON, a LSC ivedContent="Figure 1"/>), within a translucent WSON, an LSC
LSP may be established between interfaces I1 and I2, spanning 2 transparent LSP may be established between interfaces I1 and I2, spanning two transparent
segments (optical paths) where the wavelength continuity constraint applies segments (optical paths) where the wavelength continuity constraint applies
(i.e. the same unique wavelength must be assigned to the LSP at each TE (i.e., the same unique wavelength must be assigned to the LSP at each TE
link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE
link, the switching capabilities of the TE link would be (X X) where X link, the switching capabilities of the TE link would be (X X), where X
refers to the switching capability of I1 and I2. For example, X can be refers to the switching capability of I1 and I2. For example, X can be
Packet Switch Capable (PSC), Time Division Multiplexing (TDM), etc.</t> Packet Switch Capable (PSC), Time-Division Multiplexing (TDM), etc.</t>
<t pn="section-1-10">
<t> This document aligns with
This document aligns with GMPLS extensions for PCEP <xref <xref target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8
target="PCEP-GMPLS"/> for generic properties such as label, label-set and 779"/> for generic properties such as label, label set, and
label assignment noting that wavelength is a type of label. Wavelength label assignment, noting that a wavelength is a type of label. Wavelength
restrictions and constraints are also formulated in terms of labels per restrictions and constraints are also formulated in terms of labels per
<xref target="RFC7579"/>.</t> <xref target="RFC7579" format="default" sectionFormat="of" derivedContent="RF
C7579"/>.</t>
<t> <t pn="section-1-11">
The optical modulation properties, which are also referred to as signal The optical modulation properties, which are also referred to as signal
compatibility, are already considered in signaling in <xref compatibility, are already considered in the signaling in <xref target="RFC75
target="RFC7581"/> and <xref target="RFC7688"/>. In order to improve the 81" format="default" sectionFormat="of" derivedContent="RFC7581"/> and <xref tar
signal quality and limit some optical effects several advanced modulation get="RFC7688" format="default" sectionFormat="of" derivedContent="RFC7688"/>. In
order to improve the
signal quality and limit some optical effects, several advanced modulation
processing capabilities are used by the mechanisms specified in this processing capabilities are used by the mechanisms specified in this
document. These modulation capabilities contribute not only to optical document.
signal quality checks but also constrain the selection of sender and
receiver, as they should have matching signal processing capabilities. This These modulation capabilities not only contribute to optical signal
document includes signal compatibility constraints as part of RWA path quality checks but also constrain the selection of sender and
receiver, as they should have matching signal processing
capabilities.
This document includes signal compatibility constraints as part of RWA path
computation. That is, the signal processing capabilities (e.g., modulation computation. That is, the signal processing capabilities (e.g., modulation
and Forward Error Correction (FEC)) indicated by means of optical interface and Forward Error Correction (FEC)) indicated by means of the Optical Interfa
class (OIC) must be compatible between the sender and the receiver of the ce
Class (OIC) must be compatible between the sender and the receiver of the
optical path across all optical elements.</t> optical path across all optical elements.</t>
<t pn="section-1-12">
<t>
This document, however, does not address optical impairments as part This document, however, does not address optical impairments as part
of RWA path computation. See <xref target="RFC6566"/> for the framework for o ptical of RWA path computation. See <xref target="RFC6566" format="default" sectionF ormat="of" derivedContent="RFC6566"/> for the framework for optical
impairments.</t> impairments.</t>
</section>
</section> <section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" p
n="section-2">
<section title="Encoding of a RWA Path Request" anchor="sect-4"><t> <name slugifiedName="name-terminology">Terminology</name>
<xref target="fig-2"/> shows one typical PCE based implementation, which is <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="RF
C5440"/>.</t>
</section>
<section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" p
n="section-3">
<name slugifiedName="name-requirements-language">Requirements Language</na
me>
<t pn="section-3-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT 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="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="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" p
n="section-4">
<name slugifiedName="name-encoding-of-an-rwa-path-req">Encoding of an RWA
Path Request</name>
<t pn="section-4-1">
<xref target="fig-2" format="default" sectionFormat="of" derivedContent="Figu
re 2"/> shows one typical PCE-based implementation, which is
referred to as the Combined Process (R&amp;WA). With this architecture, referred to as the Combined Process (R&amp;WA). With this architecture,
the two processes of routing and wavelength assignment are accessed the two processes of routing and wavelength assignment are accessed
via a single PCE. This architecture is the base architecture via a single PCE. This architecture is the base architecture
specified in <xref target="RFC6163"/> and the PCEP extensions that are specif ied in specified in <xref target="RFC6163" format="default" sectionFormat="of" deriv edContent="RFC6163"/>, and the PCEP extensions that are specified in
this document are based on this architecture.</t> this document are based on this architecture.</t>
<figure anchor="fig-2" align="left" suppress-title="false" pn="figure-2">
<figure title="Combined Process (R&amp;WA) architecture" anchor="fig-2">< <name slugifiedName="name-combined-process-rwa-archit">Combined Process
artwork><![CDATA[ (R&amp;WA) Architecture</name>
<artwork name="" type="" align="left" alt="" pn="section-4-2.1">
+----------------------------+ +----------------------------+
+-----+ | +-------+ +--+ | +-----+ | +-------+ +--+ |
| | | |Routing| |WA| | | | | |Routing| |WA| |
| PCC |<-----&gt;| +-------+ +--+ | | PCC |<-----&gt;| +-------+ +--+ |
| | | | | | | |
+-----+ | PCE | +-----+ | PCE |
+----------------------------+ +----------------------------+
]]></artwork> </artwork>
</figure> </figure>
<section title="Wavelength Assignment (WA) Object" anchor="sect-4.1"><t> <section anchor="sect-4.1" numbered="true" toc="include" removeInRFC="fals
Wavelength allocation can be performed by the PCE by different e" pn="section-4.1">
means: <name slugifiedName="name-wavelength-assignment-wa-ob">Wavelength Assign
ment (WA) Object</name>
<list style="format (%c)"> <t pn="section-4.1-1">
Wavelength allocation can be performed by the PCE by
<t>By means of Explicit Label Control <xref target="RFC3471"/> where the means of:
PCE allocates which label to use for each interface/node along the path.
The allocated labels MAY appear after an interface route subobject.</t>
<t>By means of a Label Set where the PCE provides a range of potential
labels to allocate by each node along the path.</t>
</list>
</t>
<t> </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" format="default" sectionFormat="of" derivedContent="RFC347
1"/>
where the PCE allocates which label to use for each interface/node
along the path. The allocated labels <bcp14>MAY</bcp14> appear
after an interface route subobject.</li>
<li pn="section-4.1-2.2" derivedCounter="(b)">A Label Set where the PC
E provides a range of potential
labels to be allocated by each node along the path.</li>
</ol>
<t pn="section-4.1-3">
Option (b) allows distributed label allocation (performed during Option (b) allows distributed label allocation (performed during
signaling) to complete wavelength assignment.</t> signaling) to complete wavelength assignment.</t>
<t pn="section-4.1-4">
<t> Additionally, given a range of potential labels to allocate, a PCReq
Additionally, given a range of potential labels to allocate, a PC <bcp14>SHOULD</bcp14> convey the heuristic or mechanism used for the
Request SHOULD convey the heuristic / mechanism used for the
allocation.</t> allocation.</t>
<t pn="section-4.1-5">
<t> Per <xref target="RFC5440" format="default" sectionFormat="of" derivedContent
The format of a PCReq message per <xref target="RFC5440"/> after incorporatin ="RFC5440"/>, the format of a PCReq message after incorporating the
g the
Wavelength Assignment (WA) object is as follows:</t> Wavelength Assignment (WA) object is as follows:</t>
<sourcecode type="rbnf" markers="false" pn="section-4.1-6">
&lt;PCReq Message&gt; ::= &lt;Common Header&gt;
<figure><artwork><![CDATA[ [&lt;svec-list&gt;]
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
Where:
<request-list>::=<request>[<request-list>] &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;]
<request>::= <RP> &lt;request&gt;::= &lt;RP&gt;
<END-POINTS> &lt;END-POINTS&gt;
<WA&gt; <WA&gt;
[other optional objects...] [other optional objects...]
]]></artwork> </sourcecode>
</figure> <t pn="section-4.1-9">
If the WA object is present in the request, it <bcp14>MUST</bcp14> be encoded
<t> after the
If the WA object is present in the request, it MUST be encoded after the END-POINTS object as defined in <xref target="RFC8779" format="default" secti
END-POINTS object as defined in <xref target="PCEP-GMPLS"/>. The WA Object onFormat="of" derivedContent="RFC8779"/>. The WA object
is mandatory in this document. Orderings for the other optional objects are is mandatory in this document. Orderings for the other optional objects are
irrelevant.</t> irrelevant.</t>
<t pn="section-4.1-10">
<t> For the WA object, the Object-Class is 42,
WA Object-Class is (TBD1) (To be assigned by IANA).</t> and the Object-Type is 1.</t>
<t pn="section-4.1-11">The format of the WA object body is as follows:</
<t> t>
WA Object-Type is 1.</t> <figure anchor="fig-3" align="left" suppress-title="false" pn="figure-3"
>
<t>The format of the WA object body is as follows:</t> <name slugifiedName="name-wa-object">WA Object</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-12.1">
<figure title="WA Object" anchor="fig-3"><artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |M| | Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<dl newline="false" spacing="normal" pn="section-4.1-13">
<t><list style="symbols"> <dt pn="section-4.1-13.1">Reserved (16 bits):</dt>
<t>Reserved (16 bits): Reserved for future use and SHOULD be zeroed <dd pn="section-4.1-13.2">Reserved for future use and <bcp14>SHOULD</b
and ignored on receipt.</t> cp14> be zeroed
and ignored on receipt.</dd>
<t>Flags (16 bits)</t> <dt pn="section-4.1-13.3">Flags field (16 bits):</dt>
<dd pn="section-4.1-13.4">
</list> <t pn="section-4.1-13.4.1">One flag bit is allocated as follows:</t>
</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>
<t> <dd pn="section-4.1-13.4.2.2">Wavelength Allocation Mode. The M bi
One flag bit is allocated as follows: t is used to indicate the mode of
wavelength assignment. When the M bit is set to 1, this indicates that the
<list style="hanging" hangIndent="6">
<t hangText="M (Mode - 1 bit):"> M bit is used to indicate the mode of
wavelength assignment. When M bit is set to 1, this indicates that the
label assigned by the PCE must be explicit. That is, the selected way to label assigned by the PCE must be explicit. That is, the selected way to
convey the allocated wavelength is by means of Explicit Label Control convey the allocated wavelength is by means of Explicit Label Control
for each hop of a computed LSP. Otherwise (M bit is set to 0), the for each hop of a computed LSP. Otherwise (M bit is set to 0), the
label assigned by the PCE need not be explicit (i.e., it can be label assigned by the PCE need not be explicit (i.e., it can be
suggested in the form of label set objects in the corresponding suggested in the form of Label Set objects in the corresponding
response, to allow distributed WA. If M is 0, the PCE MUST return a response, to allow distributed WA. If M is 0, the PCE <bcp14>MUST</bcp14>
Label Set Field as described in Section 2.6 of <xref target="RFC7579"/> return a
in the response. See Section 5 of this document for the encoding Label Set Field as described in <xref target="RFC7579" sectionFormat="of"
discussion of a Label Set Field in a PCRep message.</t> section="2.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#s
</list> ection-2.6" derivedContent="RFC7579"/>
</t> in the response. See <xref target="sect-5" format="default" sectionFormat
="of" derivedContent="Section 5"/> of this document for the encoding
<t>All unused flags SHOULD be zeroed. IANA is to create a new registry to discussion of a Label Set Field in a PCRep message.</dd>
manage the Flag field of the WA object. </dl>
<t pn="section-4.1-13.4.3">All unused flags <bcp14>SHOULD</bcp14> be
<list style="symbols"> zeroed. IANA has created
<t>TLVs (variable). In the TLVs field, the following two TLVs are a new registry to manage the Flags field of the WA object.</t>
defined. At least one TLV MUST be present.</t> </dd>
</list> <dt pn="section-4.1-13.5">TLVs (variable):</dt>
<dd pn="section-4.1-13.6">
<list style="hanging" hangIndent="3"> <t pn="section-4.1-13.6.1">In the TLVs field, the following two TLVs
are
<t hangText="Wavelength Selection TLV:"> A TLV of type (TBD2) with defined. At least one TLV <bcp14>MUST</bcp14> be present.</t>
fixed length of 32 bits indicating the wavelength selection. See <xref <dl newline="false" spacing="normal" pn="section-4.1-13.6.2">
target="sect-4.2"/> for details.</t> <dt pn="section-4.1-13.6.2.1">Wavelength Selection TLV:</dt>
<dd pn="section-4.1-13.6.2.2">The type of this TLV is 8,
<t hangText="Wavelength Restriction Constraint TLV:"> A TLV of type and it has a
(TBD3) with variable length indicating wavelength restrictions. See fixed length of 32 bits. This TLV indicates the wavelength selection.
<xref target="sect-4.3"/> for details.</t> See
<xref target="sect-4.2" format="default" sectionFormat="of" derivedCon
</list> tent="Section 4.2"/> for details.</dd>
</t> <dt pn="section-4.1-13.6.2.3">Wavelength Restriction TLV:</dt>
<dd pn="section-4.1-13.6.2.4">The type of this
</section> TLV is 9, and it has a variable length. This TLV indicates wavelength r
estrictions. See
<section title="Wavelength Selection TLV" anchor="sect-4.2"><t> <xref target="sect-4.3" format="default" sectionFormat="of" derivedConten
t="Section 4.3"/> for details.</dd>
</dl>
</dd>
</dl>
</section>
<section anchor="sect-4.2" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4.2">
<name slugifiedName="name-wavelength-selection-tlv">Wavelength Selection
TLV</name>
<t pn="section-4.2-1">
The Wavelength Selection TLV is used to indicate the wavelength The Wavelength Selection TLV is used to indicate the wavelength
selection constraint in regard to the order of wavelength assignment selection constraint in regard to the order of wavelength assignment
to be returned by the PCE. This TLV is only applied when M bit is to be returned by the PCE. This TLV is only applied when the M bit is
set in the WA Object specified in <xref target="sect-4.1"/>. This TLV MUST NO set in the WA object specified in <xref target="sect-4.1" format="default" se
T be ctionFormat="of" derivedContent="Section 4.1"/>. This TLV <bcp14>MUST NOT</bcp14
> be
used when the M bit is cleared.</t> used when the M bit is cleared.</t>
<t pn="section-4.2-2">
<t> The encoding of this TLV is specified as the WavelengthSelection sub-TLV
The encoding of this TLV is specified as the Wavelength Selection in <xref target="RFC7689" sectionFormat="of" section="4.2.2" format="default"
Sub-TLV in Section 4.2.2 of <xref target="RFC7689"/>. IANA is to allocate a n derivedLink="https://rfc-editor.org/rfc/rfc7689#section-4.2.2" derivedContent="
ew TLV RFC7689"/>. IANA has
type, Wavelength Selection TLV type (TBD2).</t> allocated a new TLV type for the Wavelength Selection TLV (Type 8).</t>
</section>
</section> <section anchor="sect-4.3" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4.3">
<section title="Wavelength Restriction Constraint TLV" anchor="sect-4.3"> <name slugifiedName="name-wavelength-restriction-tlv">Wavelength Restric
<t> tion TLV</name>
For any request that contains a wavelength assignment, the requester <t pn="section-4.3-1">
(PCC) MUST specify a restriction on the wavelengths to be used. This For any request that contains a wavelength assignment, the requester (PCC)
restriction is to be interpreted by the PCE as a constraint on the <bcp14>MUST</bcp14> specify a restriction on the wavelengths to be
tuning ability of the origination laser transmitter or on any other used. This restriction is to be interpreted by the PCE as a constraint on
maintenance related constraints. Note that if the LSP LSC spans the tuning ability of the origination laser transmitter or on any other
different segments, the PCE must have mechanisms to know the maintenance-related constraints. Note that if the LSC LSP spans different
tunability restrictions of the involved wavelength converters / segments, the PCE must have mechanisms to know the tunability restrictions
regenerators, e.g. by means of the Traffic Engineering Database of the involved wavelength converters/regenerators, e.g., by means of the
(TED) either via IGP or Network Management System (NMS). Even if the Traffic Engineering Database (TED) via either IGP or NMS. Even if the PCE
PCE knows the tunability of the transmitter, the PCC must be able to knows the tunability of the transmitter, the PCC must be able to apply
apply additional constraints to the request.</t> additional constraints to the request.</t>
<t pn="section-4.3-2">
<t> The format of the Wavelength Restriction TLV is as
The format of the Wavelength Restriction Constraint TLV is as
follows:</t> follows:</t>
<sourcecode type="rbnf" markers="false" pn="section-4.3-3">
&lt;Wavelength Restriction&gt; ::=
<figure><artwork><![CDATA[ (&lt;Action&gt; &lt;Count&gt; &lt;Reserved&gt;
<Wavelength Restriction Constraint> ::=
(<Action> <Count> <Reserved>
<Link Identifiers> <Wavelength Restriction>)...
Where
<Link Identifiers> ::= <Link Identifier> [<Link Identifiers>]
]]></artwork>
</figure>
<t>See Section 4.3.1. for the encoding of the Link Identifiers Field.</t>
<t> These fields (i.e., &lt;Action&gt;, &lt;Link Identifiers&gt; and &lt;Link Identifiers&gt; &lt;Wavelength Constraint&gt;)...
&lt;Wavelength Restriction&gt;, etc.) MAY appear together more than </sourcecode>
<t pn="section-4.3-4">Where:</t>
<sourcecode type="rbnf" markers="false" pn="section-4.3-5">
&lt;Link Identifiers&gt; ::= &lt;Link Identifier&gt; [&lt;Link Identifiers&gt;]
</sourcecode>
<t pn="section-4.3-6">See <xref target="sect-4.3.1" format="default" sec
tionFormat="of" derivedContent="Section 4.3.1"/> for the encoding of the Link
Identifier field.</t>
<t pn="section-4.3-7"> These fields (i.e., &lt;Action&gt;, &lt;Link Iden
tifiers&gt;, and
&lt;Wavelength Constraint&gt;, etc.) <bcp14>MAY</bcp14> appear together m
ore than
once to be able to specify multiple actions and their once to be able to specify multiple actions and their
restrictions.</t> restrictions.</t>
<t pn="section-4.3-8">
<t> IANA has allocated a new TLV type for the Wavelength Restriction
IANA is to allocate a new TLV type, Wavelength Restriction TLV (Type 9).</t>
Constraint TLV type (TBD3).</t> <t pn="section-4.3-9">The TLV data is defined as follows:</t>
<figure anchor="fig-4" align="left" suppress-title="false" pn="figure-4"
<t>The TLV data is defined as follows:</t> >
<name slugifiedName="name-wavelength-restriction-tlv-">Wavelength Rest
<figure title="Wavelength Restriction Constraint TLV Encoding" anchor="fi riction TLV Encoding</name>
g-4"><artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-4.3-10.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved | | Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers Field | | Link Identifiers |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Constraint |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~ ~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved | | Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers Field | | Link Identifiers |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Constraint |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<dl newline="true" spacing="normal" pn="section-4.3-11">
<t><list style="symbols"><t>Action (8 bits): <dt pn="section-4.3-11.1">Action (8 bits):</dt>
<dd pn="section-4.3-11.2">
<list style="symbols"><t>0 - Inclusive List indicates that one or more <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 o
r more
link identifiers are included in the Link Set. Each identifies a link identifiers are included in the Link Set. Each identifies a
separate link that is part of the set.</t> separate link that is part of the set.</dd>
<dt pn="section-4.3-11.2.1.3">1:</dt>
<t>1 - Inclusive Range indicates that the Link Set defines a <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 range of links. It contains two link identifiers. The first
identifier indicates the start of the range (inclusive). The identifier indicates the start of the range (inclusive). The
second identifier indicates the end of the range second identifier indicates the end of the range
(inclusive). All links with numeric values between the (inclusive). All links with numeric values between the
bounds are considered to be part of the set. A value of zero bounds are considered to be part of the set. A value of zero
in either position indicates that there is no bound on the in either position indicates that there is no bound on the
corresponding portion of the range.</t> corresponding portion of the range.</dd>
<dt pn="section-4.3-11.2.1.5">2-255:</dt>
<t>2-255 - For future use</t> <dd pn="section-4.3-11.2.1.6">Unassigned.</dd>
</dl>
</list> <t pn="section-4.3-11.2.2">IANA has created a new registry to manage
</t> the Action values of the
Wavelength Restriction TLV.</t>
</list> <t pn="section-4.3-11.2.3">
</t> If a PCE receives an unrecognized Action value, the PCE <bcp14>MUST</bcp14> s
end a
<t> PCEP Error (PCErr) message with a PCEP-ERROR object with Error-Type=27 and
IANA is to create a new registry to manage the Action values of the an Error-value=3. See <xref target="sect-5.2" format="default" sectionFormat=
Wavelength Restriction Constraint TLV.</t> "of" derivedContent="Section 5.2"/> for details.</t>
<t pn="section-4.3-11.2.4">
<t>
If PCE receives an unrecognized Action value, the PCE MUST send a
PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an
Error-value (Error-value=3). See <xref target="sect-5.2"/> for details.</t>
<t>
Note that "links" are assumed to be bidirectional.</t> Note that "links" are assumed to be bidirectional.</t>
</dd>
<t><list style="symbols"><t>Count (8 bits): The number of the link identi <dt pn="section-4.3-11.3">Count (8 bits):</dt>
fiers</t> <dd pn="section-4.3-11.4">
<t pn="section-4.3-11.4.1">The number of the link identifiers.</t>
</list> <t pn="section-4.3-11.4.2">
</t> Note that a PCC <bcp14>MAY</bcp14> add a Wavelength restriction that applies
to all
<t>
Note that a PCC MAY add a Wavelength restriction that applies to all
links by setting the Count field to zero and specifying just a set links by setting the Count field to zero and specifying just a set
of wavelengths.</t> of wavelengths.</t>
<t pn="section-4.3-11.4.3">
<t> Note that all link identifiers in the same list <bcp14>MUST</bcp14> be of the
Note that all link identifiers in the same list MUST be of the same same
type.</t> type.</t>
</dd>
<t><list style="hanging" hangIndent="3"> <dt pn="section-4.3-11.5">Reserved (16 bits):</dt>
<t hangText="Reserved (16 bits):"> Reserved for future use and SHOULD <dd pn="section-4.3-11.6"> Reserved for future use and <bcp14>SHOULD</
bcp14>
be zeroed and ignored on receipt. be zeroed and ignored on receipt.
</t> </dd>
<dt pn="section-4.3-11.7">Link Identifiers:</dt>
<t hangText="Link Identifiers:"> Identifies each link ID for which <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 restriction is applied. The length is dependent on the link format and
the Count field. See <xref target="sect-4.3.1"/>. for Link Identifier the Count field. See <xref target="sect-4.3.1" format="default" sectionFo
encoding. rmat="of" derivedContent="Section 4.3.1"/> for
</t> encoding of the Link Identifier field.
</dd>
<t hangText="Wavelength Restriction:"> See Section 4.3.2. for the <dt pn="section-4.3-11.9">Wavelength Constraint:</dt>
Wavelength Restriction Field encoding. <dd pn="section-4.3-11.10"> See <xref target="sect-4.3.2" format="defa
</t> ult" sectionFormat="of" derivedContent="Section 4.3.2"/> for the encoding of the
Wavelength Constraint field.
</list> </dd>
</t> </dl>
<t pn="section-4.3-12">
<t>
Various encoding errors are possible with this TLV (e.g., not Various encoding errors are possible with this TLV (e.g., not
exactly two link identifiers with the range case, unknown identifier exactly two link identifiers with the range case, unknown identifier
types, no matching link for a given identifier, etc.). To indicate types, no matching link for a given identifier, etc.).
errors associated with this encoding, a PCEP speaker MUST send a
PCErr message with Error-Type=TBD8 and Error-value=3. See <xref target="sect-
5.1"/> for the details.</t>
<section title="Link Identifier Field" anchor="sect-4.3.1"><t>
The link identifier field can be an IPv4 <xref target="RFC3630"/>, IPv6 <xref
target="RFC5329"/>
or unnumbered interface ID <xref target="RFC4203"/>.</t>
<figure><artwork><![CDATA[
<Link Identifier> ::=
<IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID>
]]></artwork>
</figure>
<t>The encoding of each case is as follows:</t>
<figure><artwork><![CDATA[
IPv4 Address Field To indicate
errors associated with this encoding, a PCEP speaker <bcp14>MUST</bcp14> send
a
PCErr message with Error-Type=27 and Error-value=3. See <xref target="sect-5.
2" format="default" sectionFormat="of" derivedContent="Section 5.2"/> for detail
s.</t>
<section 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
</name>
<t pn="section-4.3.1-1">
The Link Identifier field can be an IPv4 <xref target="RFC3630" format="defau
lt" sectionFormat="of" derivedContent="RFC3630"/>, IPv6 <xref target="RFC5329" f
ormat="default" sectionFormat="of" derivedContent="RFC5329"/>, or
unnumbered interface ID <xref target="RFC4203" format="default" sectionFormat
="of" derivedContent="RFC4203"/>.</t>
<sourcecode type="rbnf" markers="false" pn="section-4.3.1-2">
&lt;Link Identifier&gt; ::=
&lt;IPv4 Address&gt; | &lt;IPv6 Address&gt; | &lt;Unnumbered IF ID&g
t;
</sourcecode>
<t pn="section-4.3.1-3">The encoding of each case is as follows.</t>
<figure anchor="fig-4.3.1-1" align="left" suppress-title="false" pn="f
igure-5">
<name slugifiedName="name-ipv4-address-field">IPv4 Address Field</na
me>
<artwork name="" type="" align="left" alt="" pn="section-4.3.1-4.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Reserved (24 bits) | | Type = 1 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
IPv6 Address Field </figure>
<figure anchor="fig-4.3.1-2" align="left" suppress-title="false" pn="f
igure-6">
<name slugifiedName="name-ipv6-address-field">IPv6 Address Field</na
me>
<artwork name="" type="" align="left" alt="" pn="section-4.3.1-5.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Reserved (24 bits) | | Type = 2 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) | | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
Unnumbered Interface ID Address Field </figure>
<figure anchor="fig-4.3.1-3" align="left" suppress-title="false" pn="f
igure-7">
<name slugifiedName="name-unnumbered-interface-id-add">Unnumbered In
terface ID Address Field</name>
<artwork name="" type="" align="left" alt="" pn="section-4.3.1-6.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Reserved (24 bits) | | Type = 3 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Node ID (32 bits) | | TE Node ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork> </figure>
</figure> <dl newline="false" spacing="normal" indent="3" pn="section-4.3.1-7">
<dt pn="section-4.3.1-7.1">Type (8 bits):</dt>
<t><list style="hanging" hangIndent="3"> <dd pn="section-4.3.1-7.2"> Indicates the type of the link identifie
r.</dd>
<t hangText="Type (8 bits):"> It indicates the type of the link identifie <dt pn="section-4.3.1-7.3">Reserved (24 bits):</dt>
r.</t> <dd pn="section-4.3.1-7.4">Reserved for future use and <bcp14>SHOULD
</bcp14>
<t hangText="Reserved (24 bits):"> Reserved for future use and SHOULD be zeroed and ignored on receipt.</dd>
be zeroed and ignored on receipt.</t> <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, a 4-byte IPv4
<t hangText="Link Identifier:"> When Type field is 1, 4-bytes IPv4 address is encoded; when the Type field is 2, a 16-byte IPv6 address is
address is encoded; when Type field is 2, 16-bytes IPv6 address is encoded; and when the Type field is 3, a tuple of a 4-byte TE node ID and
encoded; when Type field is 3, a tuple of 4-bytes TE node ID and a 4-byte interface ID is encoded.</dd>
4-bytes interface ID is encoded.</t> </dl>
<t pn="section-4.3.1-8">
</list> The Type field is extensible and matches the "TE_LINK Object Class type
</t> name space (Value 11)" registry created for the
Link Management Protocol (LMP) <xref target="RFC4204" format="default" sectio
<t> nFormat="of" derivedContent="RFC4204"/> (see <xref target="LMP-PARAM" format="de
The Type field is extensible and matches to the IANA registry fault" sectionFormat="of" derivedContent="LMP-PARAM"/>). IANA has added
created for Link Management Protocol (LMP) <xref target="RFC4204"/> for "TE L an introductory note before the aforementioned registry stating that the valu
ink Object Class Type name space": <eref target="https://www.iana.org/assignment es
s/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15."/> See <xref target="se have additional usage for the Link Identifier Type field. See <xref target="s
ct-8.14"/> ect-8.14" format="default" sectionFormat="of" derivedContent="Section 8.14"/>.</
for the request to update the introductory text of the t>
aforementioned registry to note that the values have additional </section>
usage for the Link Identifier Type field.</t> <section anchor="sect-4.3.2" numbered="true" toc="include" removeInRFC="
false" pn="section-4.3.2">
</section> <name slugifiedName="name-wavelength-constraint-field">Wavelength Cons
traint Field</name>
<section title="Wavelength Restriction Field" anchor="sect-4.3.2"><t> <t pn="section-4.3.2-1">
The Wavelength Restriction Field of the Wavelength Restriction The Wavelength Constraint field of the Wavelength Restriction
Constraint TLV is encoded as a Label Set field as specified in TLV is encoded as a Label Set Field as specified in
Section 2.6 in <xref target="RFC7579"/> with base label encoded as a 32 bit L <xref target="RFC7579" sectionFormat="of" section="2.6" format="default" deri
SC vedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6" derivedContent="RFC7579
label, defined in <xref target="RFC6205"/>. The Label Set format is repeated "/> with the base label encoded as a 32-bit LSC
here label, as defined in <xref target="RFC6205" format="default" sectionFormat="o
f" derivedContent="RFC6205"/>. The Label Set format is repeated here
for convenience, with the base label internal structure included. for convenience, with the base label internal structure included.
See <xref target="RFC6205"/> for a description of Grid, C.S, Identifier and n See <xref target="RFC6205" format="default" sectionFormat="of" derivedContent
, as ="RFC6205"/> for a description of Grid, Channel Spacing (C.S.), Identifier, and
well as <xref target="RFC7579"/> for the details of each action.</t> n, and see <xref target="RFC7579" format="default" sectionFormat="of" derivedCon
tent="RFC7579"/> for the details of each action.</t>
<figure><artwork><![CDATA[ <figure anchor="fig-7.1" align="left" suppress-title="false" pn="figur
e-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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action| Num Labels | Length | | Action| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S | Identifier | n | |Grid | C.S. | Identifier | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action | | Additional fields as necessary per action |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork> </figure>
</figure> <dl newline="true" spacing="normal" pn="section-4.3.2-3">
<dt pn="section-4.3.2-3.1">Action (4 bits):</dt>
<t> Action (4 bits): <dd pn="section-4.3.2-3.2">
<dl newline="false" spacing="normal" pn="section-4.3.2-3.2.1">
<list> <dt pn="section-4.3.2-3.2.1.1">0:</dt>
<t>0 - Inclusive List</t> <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>
<t>1 - Exclusive List</t> <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>
<t>2 - Inclusive Range</t> <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>
<t>3 - Exclusive Range</t> <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>
<t>4 - Bitmap Set</t> <dd pn="section-4.3.2-3.2.1.10">Bitmap Set</dd>
</list> </dl>
</dd>
<list style="hanging" hangIndent="3"> <dt pn="section-4.3.2-3.3">Num Labels (12 bits):</dt>
<dd pn="section-4.3.2-3.4"> It is generally the number of
<t hangText="Num Labels (12 bits):"> It is generally the number of labels. It has a specific meaning depending on the action value.</dd>
labels. It has a specific meaning depending on the action value.</t> <dt pn="section-4.3.2-3.5">Length (16 bits):</dt>
<dd pn="section-4.3.2-3.6"> It is the length in bytes of the entire
<t hangText="Length (16 bits):"> It is the length in bytes of the entire Wavelength
Wavelength Constraint field.</dd>
Restriction field.</t> <dt pn="section-4.3.2-3.7">Identifier (9 bits):</dt>
<dd pn="section-4.3.2-3.8"> The Identifier is always set to
<t hangText="Identifier (9 bits):"> The Identifier is always set to 0. If PCC receives the value of the identifier other than 0, it will igno
0. If PCC receives the value of the identifier other than 0, it will igno re.</dd>
re.</t> </dl>
</list> <t pn="section-4.3.2-4">
</t> See Sections <xref target="RFC7579" section="2.6.1" sectionFormat="bare" form
at="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6.1" deri
<t> vedContent="RFC7579"/>-<xref target="RFC7579" section="2.6.3" sectionFormat="bar
See Sections 2.6.1 - 2.6.3 of <xref target="RFC7579"/> for details on additio e" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7579#section-2.6.
nal 3" derivedContent="RFC7579"/> of <xref target="RFC7579" format="default" section
Format="of" derivedContent="RFC7579"/> for details on additional
field discussion for each action.</t> field discussion for each action.</t>
</section>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="include" removeInRFC="fals
</section> e" pn="section-4.4">
<name slugifiedName="name-signal-processing-capabilit">Signal Processing
<section title="Signal Processing Capability Restrictions" anchor="sect-4 Capability Restrictions</name>
.4"><t> <t pn="section-4.4-1">
Path computation for WSON includes checking of signal processing Path computation for WSON includes the checking of signal processing
capabilities at each interface against requested capability; the PCE capabilities at each interface against requested capability; the PCE
MUST have mechanisms to know the signal processing capabilities at <bcp14>MUST</bcp14> have mechanisms to know the signal processing capabilitie
each interface, e.g. by means of the Traffic Engineering Database s at
(TED) either via IGP or Network Management System (NMS). Moreover, each interface, e.g., by means of
(TED) via either IGP or NMS. Moreover,
a PCC should be able to indicate additional restrictions to signal a PCC should be able to indicate additional restrictions to signal
processing compatibility, either on the endpoint or any given link.</t> processing compatibility, on either the endpoint or any given link.</t>
<t pn="section-4.4-2">
<t>
The supported signal processing capabilities considered in the RWA The supported signal processing capabilities considered in the RWA
Information Model <xref target="RFC7446"/> are: Information Model <xref target="RFC7446" format="default" sectionFormat="of"
derivedContent="RFC7446"/> are:
<list style="symbols"> </t>
<t>Optical Interface Class List</t> <ul spacing="normal" bare="false" empty="false" pn="section-4.4-3">
<li pn="section-4.4-3.1">Optical Interface Class List</li>
<t>Bit Rate</t> <li pn="section-4.4-3.2">Bit Rate</li>
<li pn="section-4.4-3.3">Client Signal</li>
<t>Client Signal</t> </ul>
<t pn="section-4.4-4">
</list> The bit rate restriction is already expressed in the BANDWIDTH object in <xre
</t> f target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8779"/
>.</t>
<t> <t pn="section-4.4-5">
The Bit Rate restriction is already expressed in <xref In order to support the optical interface class information and the client
target="PCEP-GMPLS"/> in the BANDWIDTH object.</t> signal information, new TLVs are introduced as endpoint restrictions in the
END-POINTS type Generalized Endpoint:
<t>
In order to support the Optical Interface Class information and the Client
Signal information new TLVs are introduced as endpoint-restriction in the
END-POINTS type Generalized endpoint:
<list style="symbols">
<t>Client Signal TLV</t>
<t>Optical Interface Class List TLV</t>
</list>
</t>
<t>
The END-POINTS type generalized endpoint is extended as follows:</t>
<figure><artwork><![CDATA[
<endpoint-restriction> ::=
<LABEL-REQUEST> <label-restriction-list>
<label-restriction-list> ::= <label-restriction>
[<label-restriction-list>]
<label-restriction> ::= (<LABEL-SET>|
[<Wavelength Restriction Constraint>]
[<signal-compatibility-restriction>])
Where
<signal-compatibility-restriction> ::=
[<Optical Interface Class List>] [<Client Signal>]
]]></artwork>
</figure>
<t>
The Wavelength Restriction Constraint TLV is defined in Section 4.3.</t>
<t> </t>
A new TLV for the Optical Interface Class List TLV (TBD5) is <ul spacing="normal" bare="false" empty="false" pn="section-4.4-6">
defined, and the encoding of the value part of the Optical Interface <li pn="section-4.4-6.1">Client Signal Information TLV</li>
Class List TLV is described in Section 4.1 of <xref target="RFC7581"/>.</t> <li pn="section-4.4-6.2">Optical Interface Class List TLV</li>
</ul>
<t pn="section-4.4-7">
The END-POINTS type Generalized Endpoint is extended as follows:</t>
<sourcecode type="rbnf" markers="false" pn="section-4.4-8">
&lt;endpoint-restriction&gt; ::=
&lt;LABEL-REQUEST&gt; &lt;label-restriction-list&gt;
<t> &lt;label-restriction-list&gt; ::= &lt;label-restriction&gt;
A new TLV for the Client Signal Information TLV (TBD6) is defined, [&lt;label-restriction-list&gt;]
and the encoding of the value part of the Client Signal Information
TLV is described in Section 4.2 of <xref target="RFC7581"/>.</t>
<section title="Signal Processing Exclusion" anchor="sect-4.4.1"><t> &lt;label-restriction&gt; ::= (&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; ::=
[&lt;Optical Interface Class List&gt;] [&lt;Client Signal Information&gt;]
</sourcecode>
<t pn="section-4.4-11">
The Wavelength Restriction TLV is defined in <xref target="sect-4.3" format="
default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
<t pn="section-4.4-12">
A new Optical Interface Class List TLV (Type 11) is
defined; the encoding of the value part of this TLV
is described in <xref target="RFC7581" sectionFormat="of" section="4.1" forma
t="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.1" derived
Content="RFC7581"/>.</t>
<t pn="section-4.4-13">
A new Client Signal Information TLV (Type 12) is defined;
the encoding of the value part of this
TLV is described in <xref target="RFC7581" sectionFormat="of" section="4.2" f
ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.2" der
ivedContent="RFC7581"/>.</t>
<section anchor="sect-4.4.1" numbered="true" toc="include" removeInRFC="
false" pn="section-4.4.1">
<name slugifiedName="name-signal-processing-exclusion">Signal Processi
ng Exclusion</name>
<t pn="section-4.4.1-1">
The PCC/PCE should be able to exclude particular types of signal The PCC/PCE should be able to exclude particular types of signal
processing along the path in order to handle client restriction or processing along the path in order to handle client restriction or
multi-domain path computation. <xref target="RFC5440"/> defines how Exclude R multi-domain path computation.
oute
Object (XRO) subobject is used. In this draft, we add two new XRO
Signal Processing Exclusion Subobjects.</t>
<t>
The first XRO subobject type (TBD9) is the Optical Interface Class
List Field defined as follows:</t>
<figure title="Optical Interface Class List XRO Subobject" anchor="fig-5" <xref target="RFC5521" format="default" sectionFormat="of" derivedContent="RF
><artwork><![CDATA[ C5521"/> defines how the Exclude Route
Object (XRO) subobject is used. In this document, we add two new XRO
Signal Processing Exclusion subobjects.</t>
<t pn="section-4.4.1-2">
The first XRO subobject type (8) is the Optical Interface Class
List, which is defined as follows:</t>
<figure anchor="fig-5" align="left" suppress-title="false" pn="figure-
9">
<name slugifiedName="name-optical-interface-class-lis">Optical Inter
face Class List XRO Subobject</name>
<artwork name="" type="" align="left" alt="" pn="section-4.4.1-3.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBD9 | Length | Reserved | Attribute | |X| Type=8 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optical Interface Class List // // Optical Interface Class List //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-4.4.1-4">
Refer to <xref target="RFC5521"/> for the definition of X, Length and Attribu Refer to <xref target="RFC5521" format="default" sectionFormat="of" derivedCo
te.</t> ntent="RFC5521"/> for the definitions of
X, Length, and Attribute.</t>
<t> <dl newline="false" spacing="normal" pn="section-4.4.1-5">
Type (7 bits): The Type of the Signaling Processing Exclusion Field. <dt pn="section-4.4.1-5.1">Type (7 bits):</dt>
The TLV Type value (TBD9) is to be assigned by the IANA for the <dd pn="section-4.4.1-5.2">The type of the Signaling Processing Excl
Optical Interface Class List XRO Subobject Type.</t> usion field.
IANA has assigned value 8 for the
<t> Optical Interface Class List XRO subobject type.</dd>
Reserved bits (8 bits) are for future use and SHOULD be zeroed and <dt pn="section-4.4.1-5.3">Reserved bits (8 bits):</dt>
ignored on receipt.</t> <dd pn="section-4.4.1-5.4">These are for future use and <bcp14>SHOUL
D</bcp14> be zeroed and
<t> ignored on receipt.</dd>
The Attribute field (8 bits): <xref target="RFC5521"/> defines several Attrib <dt pn="section-4.4.1-5.5">Attribute (8 bits):</dt>
ute <dd pn="section-4.4.1-5.6">
<xref target="RFC5521" format="default" sectionFormat="of" derived
Content="RFC5521"/> defines several Attribute
values; the only permitted Attribute values for this field are 0 values; the only permitted Attribute values for this field are 0
(Interface) or 1 (Node).</t> (Interface) or 1 (Node).</dd>
<dt pn="section-4.4.1-5.7">Optical Interface Class List:</dt>
<t> <dd pn="section-4.4.1-5.8">This field is encoded as
The Optical Interface Class List is encoded as described in Section described in <xref target="RFC7581" sectionFormat="of" section="4.1" format="
4.1 of <xref target="RFC7581"/>.</t> default" derivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.1" derivedCon
tent="RFC7581"/>.</dd>
<t> </dl>
The second XRO subobject type (TBD10) is the Client Signal <t pn="section-4.4.1-6">
Information defined as follows:</t> The second XRO subobject type (9) is the Client Signal
Information, which is defined as follows:</t>
<figure title="Client Signal Information XRO Subobject" anchor="fig-6"><a <figure anchor="fig-6" align="left" suppress-title="false" pn="figure-
rtwork><![CDATA[ 10">
<name slugifiedName="name-client-signal-information-x">Client Signal
Information XRO Subobject</name>
<artwork name="" type="" align="left" alt="" pn="section-4.4.1-7.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBD10 | Length | Reserved | Attribute | |X| Type=9 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Client Signal Information // // Client Signal Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-4.4.1-8">
Refer to <xref target="RFC5521"/> for the definition of X, Length and Attribu Refer to <xref target="RFC5521" format="default" sectionFormat="of" derivedCo
te.</t> ntent="RFC5521"/> for the definitions of
X, Length, and Attribute.</t>
<t>Type (7 bits): The Type of the Signaling Processing Exclusion Field. <dl newline="false" spacing="normal" pn="section-4.4.1-9">
The TLV Type value (TBD10) is to be assigned by the IANA for the Client <dt pn="section-4.4.1-9.1">Type (7 bits):</dt>
Signal Information XRO Subobject Type.</t> <dd pn="section-4.4.1-9.2">The type of the Signaling Processing Excl
usion field.
<t>Reserved bits (8 bits) are for future use and SHOULD be zeroed and IANA has assigned value 9 for the Client
ignored on receipt.</t> Signal Information XRO subobject type.</dd>
<dt pn="section-4.4.1-9.3">Reserved bits (8 bits):</dt>
<t>The Attribute field (8 bits): [RFC5521] defines several Attribute <dd pn="section-4.4.1-9.4">These are for future use and <bcp14>SHOUL
values; the only permitted Attribute values for this field are 0 D</bcp14> be zeroed and
(Interface) or 1 (Node).</t> ignored on receipt.</dd>
<dt pn="section-4.4.1-9.5">Attribute (8 bits):</dt>
<t> <dd pn="section-4.4.1-9.6">
The Client Signal Information is encoded as described in Section 4.2 <xref target="RFC5521" format="default" sectionFormat="of" derived
of <xref target="RFC7581"/>.</t> Content="RFC5521"/> defines several Attribute values; the only
permitted Attribute values for this field are 0 (Interface) or 1
<t> (Node).</dd>
<dt pn="section-4.4.1-9.7">Client Signal Information:</dt>
<dd pn="section-4.4.1-9.8">This field is encoded as described
in <xref target="RFC7581" sectionFormat="of" section="4.2" format="default" d
erivedLink="https://rfc-editor.org/rfc/rfc7581#section-4.2" derivedContent="RFC7
581"/>.</dd>
</dl>
<t pn="section-4.4.1-10">
The XRO needs to support the new Signaling Processing Exclusion XRO The XRO needs to support the new Signaling Processing Exclusion XRO
Subobject types:</t> subobject types:</t>
<ul empty="true" bare="false" spacing="normal" pn="section-4.4.1-11">
<figure><artwork><![CDATA[ <li pn="section-4.4.1-11.1">
Type XRO Subobject Type <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>
TBD9 Optical Interface Class List <dd pn="section-4.4.1-11.1.1.2">Optical Interface Class List</dd
>
TBD10 Client Signal Information <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</dd>
]]></artwork> </dl>
</figure> </li>
</ul>
</section> </section>
<section anchor="sect-4.4.2" numbered="true" toc="include" removeInRFC="
<section title="Signal Processing Inclusion" anchor="sect-4.4.2"><t> false" pn="section-4.4.2">
<name slugifiedName="name-signal-processing-inclusion">Signal Processi
ng Inclusion</name>
<t pn="section-4.4.2-1">
Similar to the XRO subobject, the PCC/PCE should be able to include Similar to the XRO subobject, the PCC/PCE should be able to include
particular types of signal processing along the path in order to particular types of signal processing along the path in order to
handle client restriction or multi-domain path computation. handle client restriction or multi-domain path computation.
<xref target="RFC5440"/> defines how Include Route Object (IRO) subobject is <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RF
used. C5440"/> defines how the Include Route Object (IRO) subobject is used.
In this draft, we add two new Signal Processing Inclusion In this document, we add two new Signal Processing Inclusion
Subobjects.</t> subobjects.</t>
<t pn="section-4.4.2-2">
<t> The IRO needs to support the new IRO subobject types (8 and
The IRO needs to support the new IRO Subobject types (TBD11 and 9) for the PCEP IRO object <xref target="RFC5440" format="default" sectionFor
TBD12) for the PCEP IRO object <xref target="RFC5440"/>:</t> mat="of" derivedContent="RFC5440"/>:</t>
<ul empty="true" bare="false" spacing="normal" pn="section-4.4.2-3">
<figure><artwork><![CDATA[ <li pn="section-4.4.2-3.1">
Type IRO Subobject Type <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>
TBD11 Optical Interface Class List <dd pn="section-4.4.2-3.1.1.2">Optical Interface Class List</dd>
<dt pn="section-4.4.2-3.1.1.3">9:</dt>
TBD12 Client Signal Information <dd pn="section-4.4.2-3.1.1.4">Client Signal Information</dd>
]]></artwork> </dl>
</figure> </li>
</ul>
<t> <t pn="section-4.4.2-4">
The encoding of the Signal Processing Inclusion subobjects is The encoding of the Signal Processing Inclusion subobjects is
similar to <xref target="sect-4.4.1"/> where the 'X' field is replaced with ' similar to the process in <xref target="sect-4.4.1" format="default" sectionF
L' ormat="of" derivedContent="Section 4.4.1"/> where the 'X' field is replaced with
field, all the other fields remains the same. The 'L' field is the 'L'
described in <xref target="RFC3209"/>.</t> field; all the other fields remain the same. The 'L' field is
described in <xref target="RFC3209" format="default" sectionFormat="of" deriv
</section> edContent="RFC3209"/>.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" p
n="section-5">
<section title="Encoding of a RWA Path Reply" anchor="sect-5"><t> <name slugifiedName="name-encoding-of-an-rwa-path-rep">Encoding of an RWA
This section provides the encoding of a RWA Path Reply for Path Reply</name>
wavelength allocation request as discussed in <xref target="sect-4"/>.</t> <t pn="section-5-1">
This section provides the encoding of an RWA Path Reply for a
<section title="Wavelength Allocation TLV" anchor="sect-5.1"><t> wavelength allocation request as discussed in <xref target="sect-4" format="d
efault" sectionFormat="of" derivedContent="Section 4"/>.</t>
<section anchor="sect-5.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-5.1">
<name slugifiedName="name-wavelength-allocation-tlv">Wavelength Allocati
on TLV</name>
<t pn="section-5.1-1">
Recall that wavelength allocation can be performed by the PCE by Recall that wavelength allocation can be performed by the PCE by
different means:</t> means of:</t>
<ol spacing="normal" type="(%c)" start="1" pn="section-5.1-2">
<t><list style="format (%c)"> <li pn="section-5.1-2.1" derivedCounter="(a)">Explicit Label Control (
ELC) where the PCE allocates
<t>By means of Explicit Label Control (ELC) where the PCE allocates which label to use for each interface/node along the path.</li>
which label to use for each interface/node along the path.</t> <li pn="section-5.1-2.2" derivedCounter="(b)">A Label Set where the PC
E provides a range of potential
<t>By means of a Label Set where the PCE provides a range of potential labels to be allocated by each node along the path.</li>
labels to allocate by each node along the path.</t> </ol>
<t pn="section-5.1-3">
</list>
</t>
<t>
Option (b) allows distributed label allocation (performed during Option (b) allows distributed label allocation (performed during
signaling) to complete wavelength allocation.</t> signaling) to complete wavelength allocation.</t>
<t pn="section-5.1-4">
<t> The type for the Wavelength Allocation TLV is 10 (see <xref target="sect-8.4"
The Wavelength Allocation TLV type is TBD4 (See <xref target="sect-8.4"/>). N format="default" sectionFormat="of" derivedContent="Section 8.4"/>). Note
ote that this TLV is used for both (a) and (b) above. The TLV data is defined
that this TLV is used for both (a) and (b). The TLV data is defined
as follows:</t> as follows:</t>
<figure anchor="fig-7.2" align="left" suppress-title="false" pn="figure-
<figure title="Wavelength Allocation TLV Encoding" anchor="fig-7"><artwor 11">
k><![CDATA[ <name slugifiedName="name-wavelength-allocation-tlv-e">Wavelength Allo
cation TLV Encoding</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-5.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flag |M| | Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier Field | | Link Identifier |
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocated Wavelength(s) | | Allocated Wavelength(s) |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<dl newline="false" spacing="normal" pn="section-5.1-6">
<t><list style="symbols"> <dt pn="section-5.1-6.1">Reserved (16 bits):</dt>
<dd pn="section-5.1-6.2">Reserved for future use.</dd>
<t>Reserved (16 bits): Reserved for future use.</t> <dt pn="section-5.1-6.3">Flags field (16 bits):</dt>
<dd pn="section-5.1-6.4">
<t>Flags (16 bits)</t> <t pn="section-5.1-6.4.1">One flag bit is allocated as follows:</t>
<dl newline="false" spacing="normal" pn="section-5.1-6.4.2">
</list> <dt pn="section-5.1-6.4.2.1">M (1 bit):</dt>
</t> <dd pn="section-5.1-6.4.2.2">
<t pn="section-5.1-6.4.2.2.1">Wavelength Allocation Mode.</t>
<t> <dl newline="false" spacing="normal" pn="section-5.1-6.4.2.2.2">
One flag bit is allocated as follows: <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 reli
<list> es on the use of Label Sets.</dd>
<t>M (Mode): 1 bit</t> <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 d
<t>0 indicates the allocation is under Explicit Label Control.</t> one using Explicit Label Control.</dd>
</dl>
<t>1 indicates the allocation is expressed in Label Sets.</t> </dd>
</dl>
</list> <t pn="section-5.1-6.4.3">IANA has created a new registry to manage
</t> the Flags field
of the Wavelength Allocation TLV.</t>
<t> </dd>
IANA is to create a new registry to manage the Flag field (TBD14) of <dt pn="section-5.1-6.5">Link Identifier:</dt>
the Wavelength Allocation TLV.</t> <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" for
<t> mat="default" sectionFormat="of" derivedContent="Section 4.3.1"/> for encoding o
Note that all link identifiers in the same list must be of the same f the Link Identifier field.</dd>
type. <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
<list style="hanging" hangIndent="3"> associated with the
<t hangText="Link Identifier:"> Identifies the interface to which link identifier. See <xref target="sect-4.3.2" format="default" sectio
assignment wavelength(s) is applied. See <xref nFormat="of" derivedContent="Section 4.3.2"/>
target="sect-4.3.1"/>. for Link Identifier encoding.</t> for encoding details.</dd>
</dl>
<t hangText="Allocated Wavelength(s):"> Indicates the allocated <t pn="section-5.1-7">
wavelength(s) to be associated with the Link Identifier. See <xref This TLV is carried in a PCRep message as an Attribute TLV <xref target="RFC5
target="sect-4.3.2"/> for encoding details.</t> 420" format="default" sectionFormat="of" derivedContent="RFC5420"/>
in the Hop Attribute subobjects <xref target="RFC7570" format="default" secti
</list> onFormat="of" derivedContent="RFC7570"/> in the Explicit Route Object (ERO) <xre
</t> f target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/
>.</t>
<t> </section>
This TLV is carried in a PCRep message as an attribute TLV <xref target="RFC5 <section anchor="sect-5.2" numbered="true" toc="include" removeInRFC="fals
420"/> e" pn="section-5.2">
in the Hop Attribute Subobjects <xref target="RFC7570"/> in the ERO <xref tar <name slugifiedName="name-error-indicator">Error Indicator</name>
get="RFC5440"/>.</t> <t pn="section-5.2-1">
To indicate errors associated with the RWA request, a new Error-Type
</section> 27 (WSON RWA Error) and subsequent Error-values are defined as follows for
inclusion in the PCEP-ERROR object:</t>
<section title="Error Indicator" anchor="sect-5.2"><t> <ul spacing="normal" bare="false" empty="false" pn="section-5.2-2">
To indicate errors associated with the RWA request, a new Error Type <li pn="section-5.2-2.1">Error-Type=27; Error-value=1: If a PCE receiv
(TBD8) and subsequent error-values are defined as follows for es an RWA request
inclusion in the PCEP-ERROR Object:</t> and the PCE is not capable of processing the request due to
insufficient memory, the PCE <bcp14>MUST</bcp14> send a PCErr
<t> message with a PCEP-ERROR object with Error-Type=27 and
A new Error-Type (TBD8) and subsequent error-values are defined as Error-value=1. The PCE stops processing the request.
follows: The corresponding RWA request <bcp14>MUST</bcp14> be canceled at the
PCC.</li>
<list style="symbols"> <li pn="section-5.2-2.2">Error-Type=27; Error-value=2: If a PCE receiv
es an RWA request and the PCE
<t>Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request and the PCE is not capable of RWA computation, the PCE <bcp14>MUST</bcp14> send a PCErr m
is not capable of processing the request due to insufficient memory, the essage
PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) with a PCEP-ERROR object with Error-Type=27 and
and an Error-value (Error- value=1). The PCE stops processing the Error-value=2. The PCE stops processing the request. The
request. The corresponding RWA request MUST be cancelled at the PCC.</t> corresponding RWA computation <bcp14>MUST</bcp14> be canceled at the PCC.</li
>
<t>Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request and the PCE <li pn="section-5.2-2.3">Error-Type=27; Error-value=3: If a PCE receiv
is not capable of RWA computation, the PCE MUST send a PCErr message es an RWA request and there
with a PCEP-ERROR Object (Error-Type=TBD8) and an Error-value
(Error-value=2). The PCE stops processing the request. The
corresponding RWA computation MUST be cancelled at the PCC.</t>
<t>Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request and there
are syntactical encoding errors (e.g., not exactly two link identifiers are syntactical encoding errors (e.g., not exactly two link identifiers
with the range case, unknown identifier types, no matching link for a with the range case, unknown identifier types, no matching link for a
given identifier, unknown Action value, etc.), the PCE MUST send a PCErr given identifier, unknown Action value, etc.), the PCE <bcp14>MUST</bcp14> se
message with a PCEP- ERROR Object (Error-Type=TBD8) and an Error-value nd a PCErr
(Error- value=3).</t> message with a PCEP-ERROR object with Error-Type=27 and Error-value=3.</li>
</list> </ul>
</t> </section>
</section> <section anchor="sect-5.3" numbered="true" toc="include" removeInRFC="fals
e" pn="section-5.3">
<section title="NO-PATH Indicator" anchor="sect-5.3"><t> <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 To communicate the reason(s) for not being able to find RWA for the
path request, the NO-PATH object can be used in the corresponding path request, the NO-PATH object can be used in the corresponding
response. The format of the NO-PATH object body is defined in response. The format of the NO-PATH object body is defined in
<xref target="RFC5440"/>. The object may contain a NO-PATH-VECTOR TLV to pro vide <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RF C5440"/>. The object may contain a NO-PATH-VECTOR TLV to provide
additional information about why a path computation has failed.</t> additional information about why a path computation has failed.</t>
<t pn="section-5.3-2">
<t> This document defines a new bit flag to be carried in the Flags field in the
One new bit flag is defined to be carried in the Flags field in the NO-PATH-VECTOR TLV, which is carried in the NO-PATH object:</t>
NO-PATH-VECTOR TLV carried in the NO-PATH Object.</t> <dl newline="false" spacing="normal" indent="3" pn="section-5.3-3">
<dt pn="section-5.3-3.1">Bit 23:</dt>
<t><list style="hanging" hangIndent="3"> <dd pn="section-5.3-3.2"> When set, the PCE indicates no feasible
<t hangText="Bit TBD7:"> When set, the PCE indicates no feasible
route was found that meets all the constraints (e.g., wavelength route was found that meets all the constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with RWA. restriction, signal compatibility, etc.) associated with RWA.
</t> </dd>
</dl>
</list> </section>
</t> </section>
<section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" p
</section> n="section-6">
<name slugifiedName="name-manageability-consideration">Manageability Consi
</section> derations</name>
<t pn="section-6-1">
<section title="Manageability Considerations" anchor="sect-6"><t> Manageability of WSON RWA with
Manageability of WSON Routing and Wavelength Assignment (RWA) with PCE must address the considerations in the following subsections.</t>
PCE must address the following considerations:</t> <section anchor="sect-6.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-6.1">
<section title="Control of Function and Policy" anchor="sect-6.1"><t> <name slugifiedName="name-control-of-function-and-pol">Control of Functi
In addition to the parameters already listed in Section 8.1 of on and Policy</name>
<xref target="RFC5440"/>, a PCEP implementation SHOULD allow configuration of <t pn="section-6.1-1">
the In addition to the parameters already listed in <xref target="RFC5440" sectio
nFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/
rfc/rfc5440#section-8.1" derivedContent="RFC5440"/>, a PCEP implementation <bcp1
4>SHOULD</bcp14> allow configuration of the
following PCEP session parameters on a PCC:</t> following PCEP session parameters on a PCC:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-6.1-2">
<t><list style="symbols"> <li pn="section-6.1-2.1">The ability to send a WSON RWA request.</li>
<t>The ability to send a WSON RWA request.</t> </ul>
<t pn="section-6.1-3">
</list> In addition to the parameters already listed in <xref target="RFC5440" sectio
</t> nFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/
rfc/rfc5440#section-8.1" derivedContent="RFC5440"/>, a PCEP implementation <bcp1
<t> 4>SHOULD</bcp14> allow configuration of the
In addition to the parameters already listed in Section 8.1 of
<xref target="RFC5440"/>, a PCEP implementation SHOULD allow configuration of
the
following PCEP session parameters on a PCE:</t> following PCEP session parameters on a PCE:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-6.1-4">
<t><list style="symbols"> <li pn="section-6.1-4.1">The support for WSON RWA.</li>
<t>The support for WSON RWA.</t> <li pn="section-6.1-4.2">A set of WSON-RWA-specific policies (authoriz
ed sender, request
<t>A set of WSON RWA specific policies (authorized sender, request rate limiter, etc).</li>
rate limiter, etc).</t> </ul>
<t pn="section-6.1-5">
</list>
</t>
<t>
These parameters may be configured as default parameters for any These parameters may be configured as default parameters for any
PCEP session the PCEP speaker participates in, or may apply to a PCEP session the PCEP speaker participates in, or they may apply to a
specific session with a given PCEP peer or a specific group of specific session with a given PCEP peer or a specific group of
sessions with a specific group of PCEP peers.</t> sessions with a specific group of PCEP peers.</t>
</section>
</section> <section anchor="sect-6.2" numbered="true" toc="include" removeInRFC="fals
e" pn="section-6.2">
<section title="Liveness Detection and Monitoring" anchor="sect-6.2"><t> <name slugifiedName="name-liveness-detection-and-moni">Liveness Detectio
n and Monitoring</name>
<t pn="section-6.2-1">
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements, aside from those already
listed in section 8.3 of <xref target="RFC5440"/>.</t> listed in <xref target="RFC5440" sectionFormat="of" section="8.3" format="def
ault" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.3" derivedConten
</section> t="RFC5440"/>.</t>
</section>
<section title="Verifying Correct Operation" anchor="sect-6.3"><t> <section anchor="sect-6.3" numbered="true" toc="include" removeInRFC="fals
e" pn="section-6.3">
<name slugifiedName="name-verifying-correct-operation">Verifying Correct
Operation</name>
<t pn="section-6.3-1">
Mechanisms defined in this document do not imply any new Mechanisms defined in this document do not imply any new
verification requirements in addition to those already listed in verification requirements, aside from those already listed in
section 8.4 of <xref target="RFC5440"/></t> <xref target="RFC5440" sectionFormat="of" section="8.4" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc5440#section-8.4" derivedContent="RFC5440
</section> "/>.</t>
</section>
<section title="Requirements on Other Protocols and Functional Components <section anchor="sect-6.4" numbered="true" toc="include" removeInRFC="fals
" anchor="sect-6.4"><t> e" pn="section-6.4">
The PCEP Link-State mechanism <xref target="PCEP-LS"/> may be used to adverti <name slugifiedName="name-requirements-on-other-proto">Requirements on O
se ther Protocols and Functional Components</name>
<t pn="section-6.4-1">
The PCEP Link-State mechanism <xref target="I-D.lee-pce-pcep-ls-optical" form
at="default" sectionFormat="of" derivedContent="PCEP-LS"/> may be used to advert
ise
WSON RWA path computation capabilities to PCCs.</t> WSON RWA path computation capabilities to PCCs.</t>
</section>
</section> <section anchor="sect-6.5" numbered="true" toc="include" removeInRFC="fals
e" pn="section-6.5">
<section title="Impact on Network Operation" anchor="sect-6.5"><t> <name slugifiedName="name-impact-on-network-operation">Impact on Network
Operation</name>
<t pn="section-6.5-1">
Mechanisms defined in this document do not imply any new network Mechanisms defined in this document do not imply any new network
operation requirements in addition to those already listed in operation requirements, aside from those already listed in
section 8.6 of <xref target="RFC5440"/>.</t> <xref target="RFC5440" sectionFormat="of" section="8.6" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc5440#section-8.6" derivedContent="RFC5440
</section> "/>.</t>
</section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="include" removeInRFC="false" p
<section title="Security Considerations" anchor="sect-7"><t> n="section-7">
The security considerations discussed in <xref target="RFC5440"/> are relevan <name slugifiedName="name-security-considerations">Security Considerations
t for </name>
this document, this document does not introduce any new security <t pn="section-7-1">
issues. If an operator wishes to keep private the information The security considerations discussed in <xref target="RFC5440" format="defau
distributed by WSON, PCEPS <xref target="RFC8253"/> SHOULD be used.</t> lt" sectionFormat="of" derivedContent="RFC5440"/> are relevant for
this document; this document does not introduce any new security
</section> issues. If an operator wishes to keep the information
distributed by WSON private, PCEPS (Usage of TLS to Provide a Secure Transpor
<section title="IANA Considerations" anchor="sect-8"><t> t for PCEP) <xref target="RFC8253" format="default" sectionFormat="of" derivedCo
ntent="RFC8253"/> <bcp14>SHOULD</bcp14> be used.</t>
</section>
<section anchor="sect-8" numbered="true" toc="include" removeInRFC="false" p
n="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 IANA maintains a registry of PCEP parameters. IANA has made
allocations from the sub-registries as described in the following allocations from the subregistries as described in the following
sections.</t> sections.</t>
<section anchor="sect-8.1" numbered="true" toc="include" removeInRFC="fals
<section title="New PCEP Object: Wavelength Assignment Object" anchor="se e" pn="section-8.1">
ct-8.1"><t> <name slugifiedName="name-new-pcep-object-wavelength-">New PCEP Object:
As described in <xref target="sect-4.1"/>, a new PCEP Object is defined to ca Wavelength Assignment Object</name>
rry <t pn="section-8.1-1">
wavelength assignment related constraints. IANA is to allocate the As described in <xref target="sect-4.1" format="default" sectionFormat="of" d
following from "PCEP Objects" sub-registry erivedContent="Section 4.1"/>, a new PCEP
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects"/ object is defined to carry wavelength-assignment-related constraints. IANA
>):</t> has allocated the following in the "PCEP Objects" subregistry <xref target="P
CEP-NUMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>
<figure><artwork><![CDATA[ :</t>
Object Class Name Object Reference <table align="left" pn="table-1">
Value Type <thead>
<tr>
TBD1 WA 1: Wavelength Assignment [This.I-D] <th align="left" colspan="1" rowspan="1">Object-Class Value</th>
]]></artwork> <th align="left" colspan="1" rowspan="1">Name</th>
</figure> <th align="left" colspan="1" rowspan="1">Object-Type</th>
</section> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
<section title="WA Object Flag Field" anchor="sect-8.2"><t> </thead>
As described in <xref target="sect-4.1"/>, IANA is to create a registry to ma <tbody>
nage <tr>
the Flag field of the WA object. New values are to be assigned by <td align="left" colspan="1" rowspan="1">42</td>
Standards Action <xref target="RFC8126"/>. Each bit should be tracked with th <td align="left" colspan="1" rowspan="1">WA</td>
e <td align="left" colspan="1" rowspan="1">0: Reserved</td>
following qualities:</t> <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
<t><list style="symbols"> <tr>
<td align="left" colspan="1" rowspan="1"/>
<t>Bit number (counting from bit 0 as the most significant bit)</t> <td align="left" colspan="1" rowspan="1"/>
<td align="left" colspan="1" rowspan="1">1: Wavelength Assignment<
<t>Capability description</t> /td>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
<t>Defining RFC</t> </tr>
</tbody>
</list> </table>
</t> </section>
<section anchor="sect-8.2" numbered="true" toc="include" removeInRFC="fals
<t> e" pn="section-8.2">
The following values are defined in this document:</t> <name slugifiedName="name-wa-object-flag-field">WA Object Flag Field</na
me>
<t> <t pn="section-8.2-1">
One bit is defined for the WA Object flag in this document:</t> As described in <xref target="sect-4.1" format="default" sectionFormat="of" d
erivedContent="Section 4.1"/>, IANA has
<t> created the "WA Object Flag Field" subregistry under the "Path Computation
Codespace of the Flag field (WA Object)</t> Element Protocol (PCEP) Numbers" registry <xref target="PCEP-NUMBERS" format=
"default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/> to
<figure><artwork><![CDATA[ manage the Flags field of the WA object. New values are to be assigned by
Bit Description Reference Standards Action <xref target="RFC8126" format="default" sectionFormat="of" d
0-14 Unassigned [This.I-D] erivedContent="RFC8126"/>. Each bit should
15 Explicit Label Control [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Selection TLV" anchor="sect-8.3"
><t>
As described in <xref target="sect-4.2"/>, a new PCEP TLV is defined to indic
ate
wavelength selection constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators"/>).</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD2 Wavelength Selection [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Restriction Constraint TLV" anch
or="sect-8.4"><t>
As described in <xref target="sect-4.3"/>, a new PCEP TLV is defined to indic
ate
wavelength restriction constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry
(<eref
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat
ors"/>).
</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD3 Wavelength Restriction [This.I-D]
Constraint
]]></artwork>
</figure>
</section>
<section title="Wavelength Restriction Constraint TLV Action Values" anch
or="sect-8.5"><t>
As described in <xref target="sect-4.3"/>, IANA is to allocate a new registry
to
manage the Action values of the Action field in the Wavelength
Restriction Constraint TLV. New values are assigned by Standards
Action <xref target="RFC8126"/>. Each value should be tracked with the follow
ing
qualities: value, meaning, and defining RFC. The following values
are defined in this document:</t>
<figure><artwork><![CDATA[
Value Meaning Reference
0 Inclusive List [This.I-D]
1 Inclusive Range [This.I-D]
2-255 Reserved [This.I-D]
]]></artwork>
</figure>
</section>
<section title="New PCEP TLV: Wavelength Allocation TLV" anchor="sect-8.6
"><t>
As described in <xref target="sect-5.1"/>, a new PCEP TLV is defined to indic
ate
the allocation of wavelength(s) by the PCE in response to a request
by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type Indicato
rs" subregistry
(<eref
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat
ors"/>).
</t>
<figure><artwork><![CDATA[
Value Description Reference
TBD4 Wavelength Allocation [This.I-D]
]]></artwork>
</figure>
</section>
<section title="Wavelength Allocation TLV Flag Field" anchor="sect-8.7"><
t>
As described in <xref target="sect-5.1"/>, IANA is to allocate a registry to
manage the Flag field of the Wavelength Allocation TLV. New values
are to be assigned by Standards Action <xref target="RFC8126"/>. Each bit sh
ould
be tracked with the following qualities:</t> be tracked with the following qualities:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.2-2">
<t><list style="symbols"> <li pn="section-8.2-2.1">Bit number (counting from bit 0 as the most s
ignificant bit)</li>
<t>Bit number (counting from bit 0 as the most significant bit)</t> <li pn="section-8.2-2.2">Capability description</li>
<li pn="section-8.2-2.3">Defining RFC</li>
<t>Capability description</t> </ul>
<t pn="section-8.2-3">The initial contents of this registry are shown be
<t>Defining RFC</t> low. One bit has been
allocated for the flag defined in this document:</t>
</list> <table align="left" pn="table-2">
</t> <thead>
<tr>
<t> <th align="left" colspan="1" rowspan="1">Bit</th>
One bit is defined for the Wavelength Allocation flag in this - <th align="left" colspan="1" rowspan="1">Description</th>
document:</t> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
<t> </thead>
Codespace of the Flag field (Wavelength Allocation TLV)</t> <tbody>
<tr>
<figure><artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">0-14</td>
Bit Description Reference <td align="left" colspan="1" rowspan="1">Unassigned</td>
0-14 Unassigned [This.I-D] <td align="left" colspan="1" rowspan="1"/>
</tr>
15 Wavelength Allocation Mode [This.I-D] <tr>
]]></artwork> <td align="left" colspan="1" rowspan="1">15</td>
</figure> <td align="left" colspan="1" rowspan="1">Wavelength Allocation Mod
e</td>
</section> <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
<section title="New PCEP TLV: Optical Interface Class List TLV" anchor="s </tbody>
ect-8.8"><t> </table>
As described in <xref target="sect-4.4"/>, a new PCEP TLV is defined to indic </section>
ate <section anchor="sect-8.3" numbered="true" toc="include" removeInRFC="fals
the optical interface class list. IANA is to allocate this new TLV e" pn="section-8.3">
from the "PCEP TLV Type Indicators" subregistry <name slugifiedName="name-new-pcep-tlv-wavelength-sel">New PCEP TLV: Wav
(<eref elength Selection TLV</name>
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat <t pn="section-8.3-1">
ors"/>). In <xref target="sect-4.2" format="default" sectionFormat="of" derivedContent
</t> ="Section 4.2"/>, a new PCEP TLV is defined to
indicate wavelength selection constraints. IANA has made the following
<figure><artwork><![CDATA[ allocation in the "PCEP TLV Type Indicators" subregistry <xref target="PCEP-N
Value Description Reference UMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:</t>
TBD5 Optical Interface [This.I-D] <table align="left" pn="table-3">
Class List <thead>
]]></artwork> <tr>
</figure> <th align="left" colspan="1" rowspan="1">Value</th>
</section> <th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
<section title="New PCEP TLV: Client Signal TLV" anchor="sect-8.9"><t> </tr>
As described in <xref target="sect-4.4"/>, a new PCEP TLV is defined to indic </thead>
ate <tbody>
the client signal information. IANA is to allocate this new TLV from <tr>
the "PCEP TLV Type Indicators" subregistry <td align="left" colspan="1" rowspan="1">8</td>
(<eref <td align="left" colspan="1" rowspan="1">Wavelength Selection</td>
target="http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicat <td align="left" colspan="1" rowspan="1">RFC 8780</td>
ors"/>). </tr>
</t> </tbody>
</table>
<figure><artwork><![CDATA[ </section>
Value Description Reference <section anchor="sect-8.4" numbered="true" toc="include" removeInRFC="fals
TBD6 Client Signal Information [This.I-D] e" pn="section-8.4">
]]></artwork> <name slugifiedName="name-new-pcep-tlv-wavelength-res">New PCEP TLV: Wav
</figure> elength Restriction TLV</name>
</section> <t pn="section-8.4-1">
In <xref target="sect-4.3" format="default" sectionFormat="of" derivedContent
<section title="New No-Path Reasons" anchor="sect-8.10"><t> ="Section 4.3"/>, a new PCEP TLV is defined to indicate
As described in <xref target="sect-5.3"/>, a new bit flag are defined to be wavelength restrictions. IANA has made the following allocation in
carried in the Flags field in the NO-PATH-VECTOR TLV carried in the the "PCEP TLV Type Indicators" subregistry <xref target="PCEP-NUMBERS" format
NO-PATH Object. This flag, when set, indicates that no feasible ="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
</t>
<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</t
d>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.5" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.5">
<name slugifiedName="name-wavelength-restriction-tlv-a">Wavelength Restr
iction TLV Action Values</name>
<t pn="section-8.5-1">
As described in <xref target="sect-4.3" format="default" sectionFormat="of" d
erivedContent="Section 4.3"/>, IANA has
created the new "Wavelength Restriction TLV Action Values"
subregistry under the "Path Computation Element Protocol (PCEP) Numbers" regi
stry
<xref target="PCEP-NUMBERS" format="default" sectionFormat="of" derivedConten
t="PCEP-NUMBERS"/> to
manage the Action values of the Action field of the Wavelength
Restriction TLV. New values are assigned by Standards
Action <xref target="RFC8126" format="default" sectionFormat="of" derivedCont
ent="RFC8126"/>. Each value should be tracked with the following
qualities: </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 registry are shown be
low:</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 anchor="sect-8.6" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.6">
<name slugifiedName="name-new-pcep-tlv-wavelength-all">New PCEP TLV: Wav
elength Allocation TLV</name>
<t pn="section-8.6-1">
In <xref 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 has made the following allocation in
"PCEP TLV Type Indicators" subregistry <xref target="PCEP-NUMBERS" format="de
fault" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
</t>
<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 anchor="sect-8.7" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.7">
<name slugifiedName="name-wavelength-allocation-tlv-f">Wavelength Alloca
tion TLV Flag Field</name>
<t pn="section-8.7-1">
As described in <xref target="sect-5.1" format="default" sectionFormat="of" d
erivedContent="Section 5.1"/>, IANA has
created a new "Wavelength Allocation TLV Flag Field" subregistry under the
"Path Computation Element Protocol (PCEP) Numbers" registry <xref target="PCE
P-NUMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/> t
o
manage the Flags field of the Wavelength Allocation TLV. New values
are to be assigned by Standards Action <xref target="RFC8126" format="default
" sectionFormat="of" derivedContent="RFC8126"/>. Each bit should
be tracked with the following qualities:</t>
<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 s
ignificant 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 flag defined in this
document. The initial contents of 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 Mod
e</td>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.8" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.8">
<name slugifiedName="name-new-pcep-tlv-optical-interf">New PCEP TLV: Opt
ical Interface Class List TLV</name>
<t pn="section-8.8-1">
In <xref 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. IANA has made the following
allocation in the "PCEP TLV Type Indicators" subregistry <xref target="PCEP-N
UMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
</t>
<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 Class L
ist</td>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.9" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.9">
<name slugifiedName="name-new-pcep-tlv-client-signal-">New PCEP TLV: Cli
ent Signal Information TLV</name>
<t pn="section-8.9-1">
In <xref target="sect-4.4" format="default" sectionFormat="of" derivedContent
="Section 4.4"/>, a new PCEP TLV is defined to
indicate the Client Signal Information. IANA has made the following
allocation in the "PCEP TLV Type Indicators" subregistry <xref target="PCEP-N
UMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
</t>
<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
</td>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-8.10" numbered="true" toc="include" removeInRFC="fal
se" 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" format="default" sectionFormat="of" derivedContent
="Section 5.3"/>, a new bit flag is defined to be
carried in the Flags field in the NO-PATH-VECTOR TLV, which is carried in the
NO-PATH object. This flag, when set, indicates that no feasible
route was found that meets all the RWA constraints (e.g., wavelength route was found that meets all the RWA constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with a RWA path restriction, signal compatibility, etc.) associated with an RWA path
computation request.</t> computation request.</t>
<t pn="section-8.10-2">
<t> IANA has made the following allocation for this new bit flag in the
IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR TLV Flag "NO-PATH-VECTOR TLV Flag Field" subregistry <xref target="PCEP-NUMBERS" forma
Field" subregistry t="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>:
(<eref target="http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector </t>
-tlv"/>).</t> <table align="left" pn="table-10">
<thead>
<figure><artwork><![CDATA[ <tr>
Bit Description Reference <th align="left" colspan="1" rowspan="1">Bit</th>
TBD7 No RWA constraints met [This.I-D] <th align="left" colspan="1" rowspan="1">Description</th>
]]></artwork> <th align="left" colspan="1" rowspan="1">Reference</th>
</figure> </tr>
</section> </thead>
<tbody>
<section title="New Error-Types and Error-Values" anchor="sect-8.11"><t> <tr>
As described in <xref target="sect-5.2"/>, new PCEP error codes are defined f <td align="left" colspan="1" rowspan="1">23</td>
or <td align="left" colspan="1" rowspan="1">No RWA constraints met</t
WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object d>
Error Types and Values" sub-registry (<eref target="http://www.iana.org/assig <td align="left" colspan="1" rowspan="1">RFC 8780</td>
nments/pcep/pcep.xhtml#pcep-error-object"/>).</t> </tr>
</tbody>
<figure><artwork><![CDATA[ </table>
Error- Meaning Error-Value Reference </section>
Type <section anchor="sect-8.11" numbered="true" toc="include" removeInRFC="fal
se" pn="section-8.11">
TBD8 WSON RWA Error 0: Unassigned [This.I-D] <name slugifiedName="name-new-error-types-and-error-v">New Error-Types a
nd Error-Values</name>
1: Insufficient [This.I-D] <t pn="section-8.11-1">
Memory In <xref target="sect-5.2" format="default" sectionFormat="of" derivedContent
="Section 5.2"/>, new PCEP error
2: RWA computation [This.I-D] codes are defined for WSON RWA errors. IANA has made the following allocation
Not supported s
in the "PCEP-ERROR Object Error Types and Values" subregistry <xref target="P
3: Syntactical [This.I-D] CEP-NUMBERS" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>
Encoding error :</t>
<table align="left" pn="table-11">
4-255: Unassigned [This.I-D] <thead>
]]></artwork> <tr>
</figure> <th align="left" colspan="1" rowspan="1">Error-Type</th>
</section> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left" colspan="1" rowspan="1">Error-value</th>
<section title="New Subobjects for the Exclude Route Object" anchor="sect <th align="left" colspan="1" rowspan="1">Reference</th>
-8.12"><t> </tr>
As described in <xref target="sect-4.4.1"/>, the "PCEP Parameters" registry </thead>
contains a subregistry "PCEP Objects" with an entry for the Exclude <tbody>
Route Object (XRO). IANA is requested to add further subobjects that <tr>
can be carried in the XRO as follows:</t> <td align="left" colspan="1" rowspan="1">27</td>
<td align="left" colspan="1" rowspan="1">WSON RWA error</td>
<figure><artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">0: Unassigned</td>
Subobject Type Reference <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
<tr>
TBD9 Optical Interface Class List [This.I-D] <td align="left" colspan="1" rowspan="1"/>
<td align="left" colspan="1" rowspan="1"/>
TBD10 Client Signal Information [This.I-D] <td align="left" colspan="1" rowspan="1">1: Insufficient memory</t
d>
]]></artwork> <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</figure> </tr>
<tr>
</section> <td align="left" colspan="1" rowspan="1"/>
<td align="left" colspan="1" rowspan="1"/>
<section title="New Subobjects for the Include Route Object" anchor="sect <td align="left" colspan="1" rowspan="1">2: RWA computation not su
-8.13"><t> pported</td>
As described in <xref target="sect-4.4.2"/>, the "PCEP Parameters" registry <td align="left" colspan="1" rowspan="1">RFC 8780</td>
contains a subregistry "PCEP Objects" with an entry for the Include </tr>
Route Object (IRO). IANA is requested to add further subobjects that <tr>
can be carried in the IRO as follows:</t> <td align="left" colspan="1" rowspan="1"/>
<td align="left" colspan="1" rowspan="1"/>
<figure><artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">3: Syntactical encoding e
Subobject Type Reference rror</td>
<td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
TBD11 Optical Interface Class List [This.I-D] <tr>
<td align="left" colspan="1" rowspan="1"/>
TBD12 Client Signal Information [This.I-D] <td align="left" colspan="1" rowspan="1"/>
]]></artwork> <td align="left" colspan="1" rowspan="1">4-255: Unassigned</td>
</figure> <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</tr>
</section> </tbody>
</table>
<section title="Request for Updated Note for LMP TE Link Object Class Typ </section>
e" anchor="sect-8.14"><t> <section anchor="sect-8.12" numbered="true" toc="include" removeInRFC="fal
As discussed in <xref target="sect-4.3.1"/>, the registry created for Link se" pn="section-8.12">
Management Protocol (LMP) <xref target="RFC4204"/> for "TE Link Object Class <name slugifiedName="name-new-subobjects-for-the-excl">New Subobjects fo
Type name space": <eref target="https://www.iana.org/assignments/lmp-parameters/ r the Exclude Route Object</name>
lmp-parameters.xhtml#lmp-parameters-15"/> is requested for the updated <t pn="section-8.12-1">The "Path Computation Element Protocol (PCEP) Num
introductory note that the values have additional usage for the Link bers" registry
Identifier Type field.</t> contains a subregistry titled "XRO Subobjects" <xref target="PCEP-NUMBER
S" format="default" sectionFormat="of" derivedContent="PCEP-NUMBERS"/>. Per <xre
</section> f target="sect-4.4.1" format="default" sectionFormat="of" derivedContent="Sectio
n 4.4.1"/>, IANA has added the following subobjects that can
</section> be carried in the XRO:</t>
<table align="left" pn="table-12">
<section title="Acknowledgments" anchor="sect-9"><t> <thead>
The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv <tr>
Dhody and Benjamin Kaduk for many helpful comments that greatly <th align="left" colspan="1" rowspan="1">Value</th>
improved the contents of this draft.</t> <th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</section> </tr>
</thead>
</middle> <tbody>
<tr>
<back> <td align="left" colspan="1" rowspan="1">8</td>
<references title="Normative References"> <td align="left" colspan="1" rowspan="1">Optical Interface Class L
&RFC2119; ist</td>
&RFC3209; <td align="left" colspan="1" rowspan="1">RFC 8780</td>
&RFC3630; </tr>
&RFC5329; <tr>
&RFC5440; <td align="left" colspan="1" rowspan="1">9</td>
&RFC6205; <td align="left" colspan="1" rowspan="1">Client Signal Information
&RFC7570; </td>
&RFC7579; <td align="left" colspan="1" rowspan="1">RFC 8780</td>
&RFC7581; </tr>
&RFC7689; </tbody>
&RFC7688; </table>
&RFC8174; </section>
&RFC8253; <section anchor="sect-8.13" numbered="true" toc="include" removeInRFC="fal
se" pn="section-8.13">
<reference anchor='PCEP-GMPLS'> <name slugifiedName="name-new-subobjects-for-the-incl">New Subobjects fo
<front> r the Include Route Object</name>
<title>PCEP extensions for GMPLS</title> <t pn="section-8.13-1">
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a
<author initials='C' surname='Margaria' fullname='Cyril Margaria'> subregistry titled "IRO Subobjects" <xref target="PCEP-NUMBERS" format="default"
<organization /> sectionFormat="of" derivedContent="PCEP-NUMBERS"/>. Per <xref target="sect-4.4
</author> .2" format="default" sectionFormat="of" derivedContent="Section 4.4.2"/>, IANA h
as added the following
<author initials='O' surname='Dios' fullname='Oscar de Dios'> subobjects that can be carried in the IRO:</t>
<organization /> <table align="left" pn="table-13">
</author> <thead>
<tr>
<author initials='F' surname='Zhang' fullname='Fatai Zhang'> <th align="left" colspan="1" rowspan="1">Value</th>
<organization /> <th align="left" colspan="1" rowspan="1">Description</th>
</author> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
<date month='December' day='12' year='2019' /> </thead>
<tbody>
<abstract><t>A Path Computation Element (PCE) provides path computation function <tr>
s for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks <td align="left" colspan="1" rowspan="1">8</td>
. Additional requirements for GMPLS are identified in RFC7025. This memo provi <td align="left" colspan="1" rowspan="1">Optical Interface Class L
des extensions to the Path Computation Element communication Protocol (PCEP) for ist</td>
the support of the GMPLS control plane to address those requirements.</t></abst <td align="left" colspan="1" rowspan="1">RFC 8780</td>
ract> </tr>
<tr>
</front> <td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">Client Signal Information
<seriesInfo name='Work in Progress,' value='draft-ietf-pce-gmpls-pcep-extensions </td>
-16' /> <td align="left" colspan="1" rowspan="1">RFC 8780</td>
</reference> </tr>
</tbody>
</references> </table>
<references title="Informative References"> </section>
&RFC3471; <section anchor="sect-8.14" numbered="true" toc="include" removeInRFC="fal
&RFC4203; se" pn="section-8.14">
&RFC4204; <name slugifiedName="name-request-for-updated-note-fo">Request for Updat
&RFC4655; ed Note for LMP TE Link Object Class Type</name>
&RFC5420; <t pn="section-8.14-1">
&RFC5521; The "TE_LINK Object Class type name space (Value 11)" registry was created
&RFC6163; for the Link Management Protocol (LMP) <xref target="RFC4204" format="default
&RFC6566; " sectionFormat="of" derivedContent="RFC4204"/>. As discussed in <xref target="s
&RFC7446; ect-4.3.1" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>,
&RFC7449; IANA has added the following note at the top of the
&RFC8126; "TE_LINK Object Class type name space (Value 11)" registry <xref target="LMP-
PARAM" format="default" sectionFormat="of" derivedContent="LMP-PARAM"/>:
<reference anchor='PCEP-LS'> </t>
<front> <ul empty="true" bare="false" spacing="normal" pn="section-8.14-2">
<title>PCEP Extension for Distribution of Link-State and TE information for Opti <li pn="section-8.14-2.1">
cal Networks</title> These values have additional usage for the Link Identifier Type field.
</li>
<author initials='Y' surname='Lee' fullname='Young Lee'> </ul>
<organization /> </section>
</author> </section>
</middle>
<author initials='H' surname='Zheng' fullname='Haomian Zheng'> <back>
<organization /> <displayreference target="I-D.lee-pce-pcep-ls-optical" to="PCEP-LS"/>
</author> <references pn="section-9">
<name slugifiedName="name-references">References</name>
<author initials='D' surname='Ceccarelli' fullname='Daniele Ceccarelli'> <references pn="section-9.1">
<organization /> <name slugifiedName="name-normative-references">Normative References</na
</author> me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<author initials='W' surname='Wang' fullname='Wei Wang'> 119" quoteTitle="true" derivedAnchor="RFC2119">
<organization /> <front>
</author> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials='P' surname='Park' fullname='Peter Park'> <author initials="S." surname="Bradner" fullname="S. Bradner">
<organization /> <organization showOnFrontPage="true"/>
</author> </author>
<date year="1997" month="March"/>
<author initials='B' surname='Yoon' fullname='Bin-Yeong Yoon'> <abstract>
<organization /> <t>In many standards track documents several words are used to sig
</author> nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
<date month='September' day='2' year='2019' /> s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
<abstract><t>In order to compute and provide optimal paths, Path Computation Ele </abstract>
ments (PCEs) require an accurate and timely Traffic Engineering Database (TED). </front>
Traditionally this Link State and TE information has been obtained from a link s <seriesInfo name="BCP" value="14"/>
tate routing protocol (supporting traffic engineering extensions). This documen <seriesInfo name="RFC" value="2119"/>
t extends the Path Communication Element Communication Protocol (PCEP) with Link <seriesInfo name="DOI" value="10.17487/RFC2119"/>
-State and TE information for optical networks.</t></abstract> </reference>
<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3
</front> 209" quoteTitle="true" derivedAnchor="RFC3209">
<front>
<seriesInfo name='Work in Progress,' value='draft-lee-pce-pcep-ls-optical-08' /> <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
</reference> <author initials="D." surname="Awduche" fullname="D. Awduche">
<organization showOnFrontPage="true"/>
</references> </author>
<section title="Contributors" anchor="sect-11"><figure><artwork><![CDATA[ <author initials="L." surname="Berger" fullname="L. Berger">
Fatai Zhang <organization showOnFrontPage="true"/>
Huawei Technologies </author>
Email: zhangfatai@huawei.com <author initials="D." surname="Gan" fullname="D. Gan">
<organization showOnFrontPage="true"/>
Cyril Margaria </author>
Nokia Siemens Networks <author initials="T." surname="Li" fullname="T. Li">
St Martin Strasse 76 <organization showOnFrontPage="true"/>
Munich, 81541 </author>
Germany <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
Phone: +49 89 5159 16934 <organization showOnFrontPage="true"/>
Email: cyril.margaria@nsn.com </author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
Oscar Gonzalez de Dios <organization showOnFrontPage="true"/>
Telefonica Investigacion y Desarrollo </author>
C/ Emilio Vargas 6 <date year="2001" month="December"/>
Madrid, 28043 <abstract>
Spain <t>This document describes the use of RSVP (Resource Reservation P
Phone: +34 91 3374013 rotocol), including all the necessary extensions, to establish label-switched pa
Email: ogondio@tid.es ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LS
P is completely identified by the label applied at the ingress node of the path,
Greg Bernstein these paths may be treated as tunnels. A key application of LSP tunnels is tra
Grotto Networking ffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
Fremont, CA, USA </abstract>
Phone: (510) 573-2237 </front>
Email: gregb@grotto-networking.com <seriesInfo name="RFC" value="3209"/>
]]></artwork> <seriesInfo name="DOI" value="10.17487/RFC3209"/>
</figure> </reference>
</section> <reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3
630" quoteTitle="true" derivedAnchor="RFC3630">
</back> <front>
<title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
</rfc> <author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization showOnFrontPage="true"/>
</author>
<author 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 Adver
tisements.</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/rfc5
329" 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="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Davey" fullname="A. Davey">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="September"/>
<abstract>
<t>This document describes extensions to OSPFv3 to support intra-a
rea Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 ne
tworks. 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/rfc5
440" 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) Comm
unication 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 stat
es 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 messag
es and objects, should further requirements be expressed in the future. [STANDA
RDS-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/rfc6
205" quoteTitle="true" derivedAnchor="RFC6205">
<front>
<title>Generalized Labels for Lambda-Switch-Capable (LSC) Label Swit
ching Routers</title>
<author initials="T." surname="Otani" fullname="T. Otani" role="edit
or">
<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, a
s a consequence, new equipment providing lambda switching capability has been de
veloped and is currently being deployed.</t>
<t>Generalized MPLS (GMPLS) is a family of protocols that can be u
sed to operate networks built from a range of technologies including wavelength
(or lambda) switching. For this purpose, GMPLS defined a wavelength label as on
ly having significance between two neighbors. Global wavelength semantics are n
ot considered.</t>
<t>In order to facilitate interoperability in a network composed o
f next generation lambda-switch-capable equipment, this document defines a stand
ard lambda label format that is compliant with the Dense Wavelength Division Mul
tiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids define
d by the International Telecommunication Union Telecommunication Standardization
Sector. The label format defined in this document can be used in GMPLS signalin
g 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/rfc7
570" quoteTitle="true" derivedAnchor="RFC7570">
<front>
<title>Label Switched Path (LSP) Attribute in the Explicit Route Obj
ect (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 attribute
s that apply to the whole of the path of a Label Switched Path (LSP). This docu
ment defines an extension to the RSVP Explicit Route Object (ERO) and Record Rou
te 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/rfc7
579" quoteTitle="true" derivedAnchor="RFC7579">
<front>
<title>General Network Element Constraint Encoding for GMPLS-Control
led Networks</title>
<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
le="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 t
o control a wide variety of technologies. In some of these technologies, networ
k elements and links may impose additional routing constraints such as asymmetri
c switch connectivity, non-local label assignment, and label range limitations o
n links.</t>
<t>This document provides efficient, protocol-agnostic encodings f
or 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 use
s.</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/rfc7
581" quoteTitle="true" derivedAnchor="RFC7581">
<front>
<title>Routing and Wavelength Assignment Information Encoding for Wa
velength Switched Optical Networks</title>
<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
le="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 k
ey information fields be made available to facilitate path computation and the e
stablishment of Label Switched Paths (LSPs). The information model described in
"Routing and Wavelength Assignment Information Model f
or Wavelength Switched Optical Networks" (RFC 7446) shows what information is re
quired at specific points in the WSON. Part of the WSON information model contai
ns aspects that may be of general applicability to other technologies, while oth
er parts are specific to WSONs.</t>
<t>This document provides efficient, protocol-agnostic encodings f
or the WSON-specific information fields. It is intended that protocol- specific
documents will reference this memo to describe how information is carried for s
pecific uses. Such encodings can be used to extend GMPLS signaling and routing
protocols. In addition, these encodings could be used by other mechanisms to co
nvey 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/rfc7
688" quoteTitle="true" derivedAnchor="RFC7688">
<front>
<title>GMPLS OSPF Enhancement for Signal and Network Element Compati
bility 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" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t>This document provides Generalized Multiprotocol Label Switchin
g (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 opt
ical or hybrid electro-optical systems such as optical-electronic-optical (OEO)
switches, regenerators, and wavelength converters, since such systems can be lim
ited 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/rfc7
689" quoteTitle="true" derivedAnchor="RFC7689">
<front>
<title>Signaling Extensions for Wavelength Switched Optical Networks
</title>
<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
le="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 Net
works (WSONs). Such extensions are applicable in WSONs under a number of condit
ions including: (a) when optional processing, such as regeneration, must be conf
igured to occur at specific nodes along a path, (b) where equipment must be conf
igured to accept an optical signal with specific attributes, or (c) where equipm
ent must be configured to output an optical signal with specific attributes. Th
is document provides mechanisms to support distributed wavelength assignment wit
h 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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/rfc8
253" quoteTitle="true" derivedAnchor="RFC8253">
<front>
<title>PCEPS: Usage of TLS to Provide a Secure Transport for the Pat
h 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. Gonzal
ez 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) defi
nes the mechanisms for the communication between a Path Computation Client (PCC)
and a Path Computation Element (PCE), or among PCEs. This document describes PC
EPS -- the usage of Transport Layer Security (TLS) to provide a secure transport
for PCEP. The additional security mechanisms are provided by the transport pro
tocol supporting PCEP; therefore, they do not affect the flexibility and extensi
bility of PCEP.</t>
<t>This document updates RFC 5440 in regards to the PCEP initializ
ation 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/rfc8
779" quoteTitle="true" derivedAnchor="RFC8779">
<front>
<title>Path Computation Element Communication Protocol (PCEP) Extens
ions for GMPLS</title>
<author initials="C" surname="Margaria" fullname="Cyril Margaria" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="O" surname="Gonzalez de Dios" fullname="Oscar Gonz
alez de Dios" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="F" surname="Zhang" fullname="Fatai Zhang" role="ed
itor">
<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/l
mp-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="P
CEP-LS">
<front>
<title>PCEP Extension for Distribution of Link-State and TE informat
ion 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 Ceccarel
li">
<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 (TE
D). Traditionally this Link State and TE information has been obtained from a li
nk state routing protocol (supporting traffic engineering extensions). This doc
ument 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-l
ee-pce-pcep-ls-optical-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="PCEP-NUMBERS" target="https://www.iana.org/assignment
s/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/rfc3
471" 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="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="January"/>
<abstract>
<t>This document describes extensions to Multi-Protocol Label Swit
ching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS e
xtends the MPLS control plane to encompass time-division (e.g., Synchronous Opti
cal Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical l
ambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or
fiber). This document presents a functional description of the extensions. Pro
tocol specific formats and mechanisms, and technology specific details are speci
fied 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/rfc4
203" quoteTitle="true" derivedAnchor="RFC4203">
<front>
<title>OSPF Extensions in Support of Generalized Multi-Protocol Labe
l 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 rout
ing 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/rfc4
204" 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 t
o form a single traffic engineering (TE) link. Furthermore, the management of T
E links is not restricted to in-band messaging, but instead can be done using ou
t-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, suppres
s downstream alarms, and localize link failures for protection/restoration purpo
ses 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/rfc4
655" 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 blo
ck for traffic engineering systems such as Multiprotocol Label Switching (MPLS)
and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computatio
n in large, multi-domain, multi-region, or multi-layer networks is complex and m
ay require special computational components and cooperation between the differen
t 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 no
t 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 Inte
rnet 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/rfc5
420" quoteTitle="true" derivedAnchor="RFC5420">
<front>
<title>Encoding of Attributes for MPLS LSP Establishment Using Resou
rce Reservation Protocol Traffic Engineering (RSVP-TE)</title>
<author initials="A." surname="Farrel" fullname="A. Farrel" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
riou">
<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 th
e 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 e
ach of the previously unused bits.</t>
<t>This document defines a new object for RSVP-TE messages that al
lows the signaling of further attribute bits and also the carriage of arbitrary
attribute parameters to make RSVP-TE easily extensible to support new requiremen
ts. 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 appl
icable 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 th
is 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/rfc5
521" quoteTitle="true" derivedAnchor="RFC5521">
<front>
<title>Extensions to the Path Computation Element Communication Prot
ocol (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 c
omputation in support of traffic engineering (TE) in Multi-Protocol Label Switch
ing (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 computatio
n, 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 communic
ation protocol between PCCs and PCEs. This document presents PCEP extensions fo
r 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/rfc6
163" quoteTitle="true" derivedAnchor="RFC6163">
<front>
<title>Framework for GMPLS and Path Computation Element (PCE) Contro
l 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" ro
le="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 Mul
ti-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) archi
tecture to the control of Wavelength Switched Optical Networks (WSONs). In part
icular, it examines Routing and Wavelength Assignment (RWA) of optical paths.</t
>
<t>This document focuses on topological elements and path selectio
n constraints that are common across different WSON environments; as such, it do
es not address optical impairments in any depth. This document is not an Interne
t 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/rfc6
566" quoteTitle="true" derivedAnchor="RFC6566">
<front>
<title>A Framework for the Control of Wavelength Switched Optical Ne
tworks (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" ro
le="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 alter
ed by the various physical processes in the optical fibers and devices it encoun
ters. When such alterations result in signal degradation, these processes are u
sually referred to as "impairments". These physical characteristics may be impo
rtant constraints to consider when using a GMPLS control plane to support path s
etup 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 netwo
rks. Specifically, this document discusses key computing constraints, scenarios
, and architectural processes: routing, wavelength assignment, and impairment va
lidation. This document does not define optical data plane aspects; impairment
parameters; or measurement of, or assessment and qualification of, a route; rath
er, it describes the architectural and information components for protocol solut
ions. This document is not an Internet Standards Track specification; it is pu
blished 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/rfc7
446" quoteTitle="true" derivedAnchor="RFC7446">
<front>
<title>Routing and Wavelength Assignment Information Model for Wavel
ength 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" ro
le="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 Rou
ting and Wavelength Assignment (RWA) process in Wavelength Switched Optical Netw
orks (WSONs). The purpose of the information described in this model is to faci
litate constrained optical path computation in WSONs. This model takes into acc
ount compatibility constraints between WSON signal attributes and network elemen
ts 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/rfc7
449" quoteTitle="true" derivedAnchor="RFC7449">
<front>
<title>Path Computation Element Communication Protocol (PCEP) Requir
ements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Ass
ignment</title>
<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
le="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. Gonzal
ez de Dios">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="February"/>
<abstract>
<t>This memo provides application-specific requirements for the Pa
th Computation Element Communication Protocol (PCEP) for the support of Waveleng
th Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires
a Routing and Wavelength Assignment (RWA) process. From a path computation persp
ective, 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 opt
ical light path computation. Requirements for PCEP extensions in support of opt
ical impairments will be addressed in a separate document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7449"/>
<seriesInfo name="DOI" value="10.17487/RFC7449"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" 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 con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations 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 des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</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 great
ly
improved the contents of this document.</t>
</section>
<section 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</organizatio
n>
<address>
<postal>
<street>St. Martin Strasse 76</street>
<city>Munich</city>
<region/>
<code>81541</code>
<country>Germany</country>
</postal>
<phone>+49 89 5159 16934</phone>
<email>cyril.margaria@nsn.com</email>
</address>
</contact>
<contact fullname="Oscar Gonzalez de Dios">
<organization showOnFrontPage="true">Telefonica Investigacion y Desarrol
lo</organization>
<address>
<postal>
<street>C/ Emilio Vargas 6</street>
<city>Madrid</city>
<region/>
<code>28043</code>
<country>Spain</country>
</postal>
<phone>+34 91 3374013</phone>
<email>ogondio@tid.es</email>
</address>
</contact>
<contact fullname="Greg Bernstein">
<organization 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>
 End of changes. 117 change blocks. 
1119 lines changed or deleted 1604 lines changed or added

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