<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">

<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC6566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6566.xml">
<!ENTITY RFC7446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7446.xml">
<!ENTITY RFC7579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7579.xml">

<!-- ENTITY I-D.ietf-ccamp-general-constraint-encode SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-general-constraint-encode-20.xml"
-->

<!ENTITY I-D.ietf-ccamp-wson-iv-encode SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-iv-encode-02.xml">


<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>

<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-ccamp-wson-iv-info-12" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="WSON Impairments Information Model">
      Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation
    </title>
    
    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Giovanni Martinelli" initials="G.M." role="editor"
            surname="Martinelli">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>via Santa Maria Molgora, 48/C</street>
          <city>Vimercate</city>
          <region>MB</region>
          <code>20871</code>
          <country>Italy</country>
        </postal>
        <phone>+39 039 2092044</phone>
        <email>giomarti@cisco.com</email>
      </address>
    </author>

    <author fullname="Haomian Zheng" initials="H.Z." role="editor"
            surname="Zheng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <phone>+8613066975206</phone>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>


    <author fullname="Gabriele M. Galimberti" initials="G.M.G."
            surname="Galimberti">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>Via Santa Maria Molgora, 48/C</street>
          <city>Vimercate</city>
          <region>MB</region>
          <code>20871</code>
          <country>Italy</country>
        </postal>

        <phone>+39 039 2091462</phone>
        <email>ggalimbe@cisco.com</email>
      </address>
    </author>

    <author fullname="Young Lee" initials="Y.L." 
            surname="Lee">
      <organization>Samsung</organization>

      <address>
        <postal>
          <street></street>
          <city>Seoul</city>
          <region></region>
          <code></code>
          <country>South Korea</country>
        </postal>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>

    <author fullname="Fatai Zhang" initials="F.Z." 
            surname="Zhang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>zhangfatai@huawei.com</email>
      </address>
    </author>


    <date  month="September" day="08" year="2020" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Routing</area>

    <workgroup>CCAMP</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>GMPLS WSON Optical Impairments</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
	This document defines an information model to support Impairment-Aware (IA) Routing and Wavelength
	Assignment (RWA) functionality. 
	This information model extends  the information model for 
	impairment-free RWA process in WSON
	to facilitate computation of paths where optical impairment constraints need to considered.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	In the context of Wavelength Switched Optical Network (WSON), <xref target="RFC6163"/> describes the 
	basic framework for a GMPLS and PCE-based Routing and Wavelength Assignment (RWA) control plane. 
	The associated information model
	<xref target="RFC7446"/> defines information/parameters
	required by an RWA process without optical impairment considerations.
      </t>
      <t>
	There are cases of WSON where optical impairments play a significant role and 
	are considered as important constraints. The framework document <xref target="RFC6566"/>
	defines the problem scope and related control plane architectural options for the Impairment Aware RWA (IA-RWA) 
	operation. Options include different combinations of Impairment Validation (IV) 
	and RWA functions in term of different combination of control plane functions  
	(i.e., PCE, Routing, Signaling).
      </t>
      <t>
	A Control Plane with RWA-IA will not be able to solve the optical impairment problem 
	in a detailed
	and exhaustive way, however, it may take advantage of some data plane knowledge to make better
	decisions during its path computing phase. 
	The final outcome will be a path, 
	instantiated
	through a wavelength in the data plane, that has a "better chance" to work than that
	path were calculated without IA information. 
	"Better chance" means that path setup may still fail and the GMPLS
	control plane will follow its usual procedures upon errors and failures. 
	A control plane
	will not replace a the network design phase that remains a
	fundamental step for DWDM Optical Networks.
	As the non-linear impairments which need to be considered in the 
	calculation of an optical path will be vendor-dependent, the parameters considered 
	in this document is not an exhaustive list.
      </t>
      <t>
	This document provides an information model for the impairment aware case to allow the impairment 
	validation function implemented in the control plane or enabled by control plane available information. 
	This model goes in addition to <xref target="RFC7446"/> and  
	shall support any control plane architectural option described by the framework document
	(see sections 4.2 and 4.3 of <xref target="RFC6566"/>) where a set of combinations of control 
	plane functions vs. IV function is provided. 
      </t>
   
    </section>

    <section title="Definitions, Applicability and Properties">

      <t>
	This section provides some concepts to help understand the model and to make a clear separation 
	from data plane definitions (ITU-T recommendations).  The first sub-section provides
	definitions while the Applicability sections uses the defined
	definitions to scope this document.
      </t>

      <section title="Definitions">
	<t>
	  <list style="symbols">
	    <t>
	      Computational Model / Optical Computational Model.
	      <vspace blankLines="0" />
	      Defined by ITU standard documents (e.g. <xref target="ITU.G680"/>). In this context we look for models able to compute optical
		  impairments for a given lightpath.
	    </t>
	    <t>
	      Information Model.<vspace blankLines="0" />
	      Defined by IETF (this document) and provides the set of information
	      required by control plane to apply the Computational Model.
	    </t>
	    <t>
	      Level of Approximation.<vspace blankLines="0" />
	      This concept refers to the Computational Model as it may compute optical impairment with
	      a certain level of uncertainty. This level is generally not measured but 
	      <xref target="RFC6566"/> Section 4.1.1 provides a rough classification about it.
	    </t>
	    <t>
	      Feasible Path.<vspace blankLines="0" />
	      It is the output of the C-SPF with RWA-IV capability. It's an optical path that
	      satisfies optical impairment constraints. 
	      The path, instantiated through wavelength(s), may actually work or not work depending 
	      of the level of approximation.
	    </t>
	    <t>
	      Existing Service Disruption.
	      <vspace blankLines="0" />
	      An effect known to optical network designers is the cross-interaction among spectrally
	      adjacent wavelengths: an existing wavelength may experience increased BER due to the setup of
	      an adjacent wavelength.  Solving this problem is a typical optical network design activity.  
		  Just as an example, a simple solution is adding optical margins (e.g., additional OSNR), although
	      complex and detailed methods exist.
	    </t>
	    <t>
	      DWDM Line Segments.
	      <vspace blankLines="0"/>
	      <xref target="ITU.G680"/> provides definition  and picture for the "Situation 1" DWDM Line segments: "
	      Situation 1 - The optical path between two consecutive 3R regenerators is composed of DWDM line segments 
	      from a single vendor and OADMs and PXCs from another vendor".
	      Document <xref target="RFC6566"/> Figure 1 shows an LSP composed by two DWDM line segments according to
	      <xref target="ITU.G680"/> definition.
	    </t>
	  </list>
	</t>
      </section> <!-- ENDOFSECTION Definitions -->

      <section title="Applicability" anchor="sec_applicability">
	<t>
	  This document targets at Scenario C defined in <xref target="RFC6566"/> section 4.1.1.
	  as approximate impairment estimation.
	  The Approximate concept refer to the fact that this Information Model covers information 
	  mainly provided by <xref target="ITU.G680"/> Computational Model.
	</t>
	<t>
	  Computational models having no or little approximation, referred as IV-Detailed in the <xref target="RFC6566"/>,
	  currently does not exist in term of ITU-T recommendation. They generally deal with non-linear
	  optical impairment and are usually vendor specific. 
	</t>
	<t>
	  The Information Model defined in this document does not speculate about the mathematical
	  formulas used to fill up information model parameters, hence it does not preclude changing the computational model. 
	  At the same time, the authors do not believe this Information Model is exhaustive and if
	  necessary further documents will cover additional models after they become available.
	</t>
	<t>
	  The result of RWA-IV process implementing this Information Model is a path (and a wavelength in 
	  the data plane) that has better chance to be feasible than if it was computed without any
	  IV function. The Existing Service Disruption, as per the definition above, would still be a problem 
	  left to a network design phase.
	</t>
      </section> <!-- ENDOFSECTION Applicability -->

    <section title="Properties">
      <t>
	An information model may have several attributes or properties that
	need to be defined for each optical parameter made available to the
	control plane. The properties will help to determine how the control
	plane can deal with a specific impairment parameter, depending on architectural 
	options chosen within the overall impairment framework <xref target="RFC6566"/>.
	In some case, properties value will help to identify the level of approximation
	supported by the IV process.
      </t>
      
      <t>
	<list style="symbols">
	  <t>
	    Time Dependency <vspace blankLines="0" /> 
	    This identifies how an impairment parameter may vary
	    with time. There could be cases where there is no time dependency,
	    while in other cases there may be need of re-evaluation after a certain time.
	    In this category, variations in impairments due to environmental factors 
	    such as those discussed in <xref target="ITU.GSUP47"/> are considered. In some cases, an 
	    impairment parameter that has time dependency may be considered as a constant 
	    for approximation. In this information model, we do neglect this property.
	  </t>

	  <t>
	    Wavelength Dependency <vspace blankLines="0" />
	    This property identifies if an impairment parameter can be considered 
	    as constant over all the wavelength spectrum of interest or not.
	    Also in this case a detailed impairment evaluation might lead to
	    consider the exact value while an approximation IV might take a
	    constant value for all wavelengths.
	    In this information model, we consider both case: dependency / no dependency
	    on a specific wavelength. This property appears directly in the 
	    information model definitions and related encoding.
	  </t>
	  
	  <t>
	    Linearity <vspace blankLines="0" /> 
	    As impairments are representation of physical effects,
	    there are some that have a linear behaviour while other are 
	    non-linear. Linear approximation is in scope of Scenario C
	    of <xref target="RFC6566"/>. 
	    During the impairment validation process, this property implies that the optical effect
	    (or quantity)
	    satisfies the superposition principle, thus a final result can be calculated by the sum of each
	    component. The linearity implies the
	    additivity of optical quantities considered during an impairment validation process.
	    <vspace blankLines="0" /> 
	    The non-linear effects in general do not satisfy this property. The information model 
	    presented in this
	    document however, easily allow introduction of non-linear optical effects with
	    a linear approximated contribution 
	    to the linear ones.	
	  </t>
	  
	  <t>
	    Multi-Channel<vspace blankLines="0" />
	    There are cases where a channel's impairments take
	    different values depending on the aside wavelengths already in
	    place, this is mostly due to non-linear impairments. 
	    The result would be a dependency among different LSPs sharing the same path.
	    This information model do not consider this kind of property.
	  </t>
	</list>
      </t>

      <t>
	The following table summarise the above considerations where in the first column reports
	the list of properties to be considered for each optical parameter, while the second column
	states if this property	is taken into account or not by this information model.
      </t>
      <texttable anchor="table_optical_properties" title="Optical Impairment Properties">
	<preamble></preamble>

	<ttcol align="center">Property</ttcol>
	
	<ttcol align="center">Info Model Awareness</ttcol>
	
	<!-- First row -->
	<c>Time Dependency</c>

	<c>no</c>
	
	<!-- Second row -->
	<c>Wavelength Dependency</c>
	
	<c>yes</c>

	<!-- Third row -->
	<c>Linearity</c>
	
	<c>yes</c>

	<!-- Forth row -->
	<c>Multi-channel</c>
	
	<c>no</c>
	
	<postamble></postamble>
      </texttable>


    </section> <!-- END OF "properties of an impairment information model -->
    
    </section> <!-- ENDOFSECTION Definitions, Applicability and Properties -->

    <section title="ITU-T List of Optical Parameters">
      <t>
	As stated by <xref target="sec_applicability"/> this
	Information Model does not intend to be exhaustive and targets
	an approximate computational model although not precluding
	future evolutions towards more detailed or different impairments estimation
	methods.
      </t>
      <t>
	On the same line, ITU SG15/Q6 provides (through <xref target="LS78"/>) a list of optical parameters with
	following observations:
	<list style="format (%c)">
	  <t>
	    the problem of calculating the non-linear impairments in
	    a multi-vendor environment is not solved. The 
	    transfer functions works only for the so called <xref target="ITU.G680"/>
	    "Situation 1".
	  </t>
	  <t>
	    The generated list of parameters is not
	    exhaustive however provide a guideline for control plane
	    optical impairment awareness.
	  </t>
	</list>
	In particular, <xref target="ITU.G680"/> contains many
	parameters that would be required 
	to estimate linear impairments. Some of the Computational Models defined within  <xref
	target="ITU.G680"/>  requires parameters defined in other documents like 
	<xref target="ITU.G671"/>. The purpose of the list here below makes this match between the
	two documents.
      </t>
      <t>
	<xref target="ITU.G697"/>
	defines parameters can be monitored in an optical network. This Information Model and
	associated encoding document will reuse
	<xref target="ITU.G697"/>  parameters identifiers and encoding for the purpose of path
	computation. 
      </t>
      
      <t>
	The list of optical parameters starts from <xref
	target="ITU.G680"/> Section 9 which provides the optical computational models 
	for the following p:
	<list style="format G-%d" counter="par_1_count">
	  <t>OSNR. Section 9.1</t>
	  <t>Chromatic Dispersion (CD). Section 9.2</t>
	  <t>Polarization Mode Dispersion (PMD). Section 9.3</t>
	  <t>Polarization Dependent Loss (PDL). Section 9.3 </t>
	</list>
      </t>

      <t>
	In addition to the above, the following list of parameters has
	been mentioned by <xref target="LS78"/>:
	<list style="format L-%d" counter="par_2_count">
	  <t>
	    "Channel frequency range", <xref target="ITU.G671"/>.
	    This parameter is part of the application code and encoded through Optical Interface Class
	    as defined in <xref target="RFC7446"/>.
	  </t>
	  <t>
	    "Modulation format and rate".
	    This parameter is part of the application code and encoded through Optical Interface Class
	    as defined in <xref target="RFC7446"/>.
	  </t>
	  <t>
	    "Channel power".
	    Required by G-1.
	  </t>
	  <t>
	    "Ripple".
	    According to <xref target="ITU.G680"/>, this parameter can be taken into account as additional OSNR
	    penalty. 
	  </t>
	  <t>
	    "Channel signal-spontaneous noise figure", [ITU.G680].
	    Required by OSNR calculation (see G-1) above.
	  </t>
	  <t>
	    "Channel chromatic dispersion (for fibre segment or network element)".
	    Already in G-2 above.
	  </t>
	  <t>
	    "Channel local chromatic dispersion (for a fibre segment)".
	    Already in G-2 above (since consider both local and fiber dispersions).
	  </t>
	  <t>
	    "Differential group delay (for a network element)", <xref target="ITU.G671"/>.
	    Required by G-3.
	  </t>
	  <t>
	    "Polarisation mode dispersion (for a fibre segment)",
	    <xref target="ITU.G650.2"/>, <xref target="ITU.G680"/>.
	    Defined above as G-3.
	  </t>
	  <t>
	    "Polarization dependent loss (for a network element)",
	    <xref target="ITU.G671"/> and <xref target="ITU.G680"/>.
	    Defined above as G-4.
	  </t>
	  <t>
	    "Reflectance". From <xref target="ITU.G671"/> Section
	    3.2.2.37 is the ratio of reflected power Pr to incident
	    power Pi at a given port of a passive component,
	    for given conditions of spectral composition, polarization
	    and geometrical distribution. Generally expressed in dB.
	    Might be monitored in some critical cases. We neglect this
	    effect as first approximation.
	  </t>
	  <t>
	    "Channel Isolation". From <xref target="ITU.G671"/> Section 3.2.2.2
	    (Adjacent Channel Isolation) and Section 3.2.2.29 (Non Adjacent
	    Channel Isolation). Document <xref target="ITU.GSUP39"/> provide the formula for
	    calculation as channel cross-talk and measure it in dB.
	    This parameterer shall be considered for path computation.
	  </t>
	  <t>
	    "Channel extinction". From <xref target="ITU.G671"/> Section 3.2.2.9
	    needed for Interferometric Crosstalk. Document <xref target="ITU.GSUP39"/> has the
	    formula for penalty computation. Unit of measurement is dB. 
	  </t>
	  <t>
	    "Attenuation coefficient (for a fibre segment)". Document
	    <xref target="ITU.G650.1"/> Section 3.6.2. The unit of measure is dB. This is a
	    typical link parameter (as associated to a fiber).
	  </t>
	  <t>
	    "Non-linear coefficient (for a fibre segment)", <xref target="ITU.G650.2"/>.
	    Required for Non-Linear Optical Impairment Computational
	    Models. Neglected by this document.
	  </t>
	</list>
      </t>
      <t>
	The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4,
	L-5, L-8, L-12, L-13, L-14.
      </t>
    </section> <!-- ENDOFSECTION Set of Optical Parameters -->


    <section title="Background from WSON-RWA Information Model">
      <t>
	In this section we report terms already defined for the WSON-RWA (impairment free) 
	as in <xref target="RFC7446"/> and <xref target="RFC7579"/>. 
	The purpose is to provide essential information that will be reused or extended for the impairment case.
      </t>
      
      <t>
	In particular <xref target="RFC7446"/> Section 4.1 defines the
	ConnectivityMatrix and states that such matrix does not represent any particular
	internal blocking behaviour but indicates which input ports and
	wavelengths could possibly be connected to a particular output port.
      </t>
      <figure align='left'>
	<artwork align="left"><![CDATA[
<ConnectivityMatrix> ::= <MatrixID> <ConnType> <Matrix>
]]></artwork>
</figure>
          
      <t>
	 According to <xref target="RFC7579"/>, this definition is further detailed
	as:
      </t>
 <figure align='left'>
	<artwork align="left"><![CDATA[
<ConnectivityMatrix> ::= 
      <MatrixID> <ConnType> ((<LinkSet> <LinkSet>) ...)
]]></artwork>
 </figure>
      <t>
	This second formula highlights how the ConnectivityMatrix is built by pairs of LinkSet
	objects identifying the internal connectivity capability due to internal optical node 
	constraint(s). It's essentially binary information and tell if a wavelength or a set
	of wavelengths can go from an input port to an output port.
      </t>
      <t>
	As an additional note, ConnectivityMatrix belongs to node
	information, is uniquely identified by advertising node and
	is a static information.
	Dynamic information related to the actual state of connections is 
	available through specific extension to link information.
      </t>
      <t>
	The <xref target="RFC7446"/> introduces the concept of
	ResourceBlockInfo and ResourcePool for the WSON nodes.
	The resource block is a collection of resources behaving in
	the same way and having
	similar characteristics. The ResourceBlockInfo is defined as follow:
      </t>
      <figure align='left'>
	<artwork align="left"><![CDATA[
<ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] 
      [<ProcessingCapabilities>] [<OutputConstraints>]
]]></artwork>
      </figure>
      <t>
	The usage of resource block and resource pool is an efficient way to model constrains within a WSON node. 
      </t>

    </section> <!-- END OF "Background from WSON Information Model" -->


    <section title="Optical Impairment Information Model">
      <t>
	The idea behind this document is to put optical impairment
	parameters into categories
	and extend the information model already defined for impairment-free WSONs. 
	The three categories are:
	<list style="symbols">
	  <t>Node Information. The concept of connectivity matrix is reused and extended to 
	  introduce an impairment matrix, which represents the impairments suffered on the internal path between two ports.
	  In addition, the concept of Resource Block is also reused
	  and extended 
	  to provide an efficient representation of per-port impairment.</t>
	  <t>Link Information representing impairment information related to a specific link or hop.</t>
	  <t>Path Information representing the impairment information related to the whole path.</t>
	</list>
	All the above three categories will make use of a generic container, the Impairment Vector, 
	to transport optical impairment information. 
      </t>
      <t>
	This information model however will allow however to add additional parameters beyond the
	one defined by <xref target="ITU.G680"/> in order to support additional computational 
	models. This mechanism could eventually applicable to both linear and non-linear 
	parameters.
      </t>

<!--
      <t>
	Another recomandation useful to for this Information model is the <xref target="ITU.G697"/>  defines 
	an encoding for all above parameters.  and in
	<xref target="encoding_considerations"/> we report some encoding consideration. The <xref target="ITU.G697"/> is 
	mainly oriented for monitoring so the purpose is only reuse parameter definitions for those parameters required 
	by Impairment Validation process.
      </t>
-->
      <t>
	This information model makes the assumption that the each optical node in the network is able to provide 
	the control plane protocols with its own parameter values.  However, no assumption is made on how the optical 
	nodes get those value information (e.g., internally computed, provisioned by a network management system, etc.). 
	To this extent, the information model intentionally ignores all
	internal detailed parameters that are used by the formulas of the Optical Computational Model 
	(i.e., "transfer function") and simply provides the object containers to carry results of the formulas.
      </t>
<!--
      <t>
	As an additional note, as reported in <xref target="ITU.G680"/> Section 10, 
	each parameter can be reported as an OSNR contribution, in such way the Optical Node not necessarily embed 
	optical computational capability but can provide an approximated contribution to optical impairments.
      </t>
	  <t>
	[Xian's note]: i do not understand what the above is trying to say. Section 10 of ITU G.680, describes from an
	end-to-end point of view and it seems needs a node to have computational capability at least for OSNR?
	  </t>
-->
 
      <section title="The Optical Impairment Vector">
	<t>
	  Optical Impairment Vector (OIV) is defined as a list of optical parameters to be associated to a WSON node or 
	  a WSON link. It is defined as:
	</t>
	<figure align='left'>
	  <artwork align="left"><![CDATA[
<OIV> ::= ([<LabelSet>] <OPTICAL_PARAM>) ...
]]></artwork>
	</figure>
<!--
    GIOVANNI: not sure what does this comment refer to. Link set goes into matrix, label set into vector
	<t>
	[Xian's note: You meant LabelSet instead of LinkSet?]
	</t>	
-->
	<t>
	  The optional LabelSet object enables wavelength dependency property as per
	  <xref target="table_optical_properties"/>. LabelSet has its definition in
	  <xref target="RFC7579"/>.
	</t>
	<t>
	  OPTICAL_PARAM. This object represents an optical parameter. The Impairment
	  vector can contain a set of parameters as identified by <xref target="ITU.G697"/> 
	  since those parameters match the terms of the linear impairments 
	  computational models provided by <xref target="ITU.G680"/>. 
	  This information model does not speculate about the set of parameters 
	  (since defined elsewhere, e.g. ITU-T), however it does not preclude 
	  extensions by adding new parameters.
	</t>
	
      </section> <!-- END OF SECTION: Optical Impairment Vector --> 

      <section title="Node Information">
	
	<section title="Impairment Matrix">

	<t>
	  Impairment matrix describes a list of the optical parameters that applies to a network element as a whole or
	  ingress/egress port pairs of a network element. Wavelength dependency property of optical parameters 
	  is also considered.
	</t>
	<figure align='left'>
	  <artwork align="left"><![CDATA[
ImpairmentMatrix ::=  <MatrixID> <ConnType> 
      ((<LinkSet> <LinkSet> <OIV>) ...)
]]></artwork>
	</figure>
      
	<t>
	  Where:
	  <list style="empty">
	    <t>
	      MatrixID. This ID is a unique identifier for the matrix. It shall be unique in scope
	      among connectivity matrices defined in <xref target="RFC7446"/>
	      and impairment matrices defined here.
	    </t>
	    <t>
	      ConnType. This number identifies the type of matrix and it shall be unique in scope with
	      other values defined by impairment-free WSON documents. 
	    </t>
	    <t>
	      LinkSet. Same object definition and usage as <xref target="RFC7579"/>.
	      The pairs of LinkSet identify one or more internal node constrain.
	    </t>
	    <t>
	      OIV. The Optical Impairment Vector defined above.
	    </t>
	  </list>
	</t>
	<t>	
	The model can be represented as a multidimensional matrix shown in the following picture
		</t>
	         <figure align="left">
	   <artwork align="left"><![CDATA[
 
 
                       _________________________________________
                      /        /       /       /       /       /|
                     /        /       /       /       /       / |
                    /________/_______/_______/_______/_______/  |
                   /        /       /       /       /       /| /|
                  /        /       /       /       /       / |  |    
                 /________/_______/_______/_______/_______/  | /|
                /        /       /       /       /       /| /|  |
               /        /       /       /       /       / |  | /|   
              /________/_______/_______/_______/_______/  | /|  |
             /        /       /       /       /       /| /|  | /|
            /        /       /       /       /       / |  | /|  |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | /|  | / PDL
<LinkSet#1> |   -   |       |       |       |       | /|  | /|/
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | /|  /
<linkSet#2> |       |   -   |       |       |       | /|  | / PND
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | /|/
<linkSet#3> |       |       |   -   |       |       | /|  /
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | / Chr.Disp.
<linkSet#4> |       |       |       |   -   |       | /|/
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  /
<linkSet#5> |       |       |       |       |   -   | / OSNR
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             <LS#1>  <LS#2>  <LS#3>  <LS#4>  <LS#5>

]]></artwork>
	 </figure>

	 <t>
	   The connectivity matrix from <xref target="RFC7579"/> 
	   is only a two dimensional matrix, containing only binary information, 
	   through the LinkSet pairs.
	   In this model, a third dimension is added by generalizing the binary information through 
	   the Optical Impairment Vector associated with each LinkSet pair. 
	   Optical parameters in the picture are reported just
	   as an example: proper list and encoding shall be defined
	   by other documents.
	 </t>
	 <t>
	   This representation shows the most general case however, 
	   the total amount of information transported by control plane
	   protocols can be greatly reduced by proper encoding 
	   when the same set of values apply to all LinkSet pairs.
	 </t>

	 <!--
	 <t>
	   [EDITOR NODE: first run of the information model does looks for generality not for optimizing
	   the quantity of information. We'll deal with optimization in a further step.]
	 </t>
    GIOVANNI: adding an editor node for help readers.  
	 <t>
	 [Xian's note]: if the same value applies to all the LinkSet pairs, what the information model
	 should look like in order to reduce the amount of information transported? Should we mention 
	 it here?]
	 </t>
	 -->
	
      </section>  <!-- End of Impairment Matrix -->

      <section title="Impairment Resource Block Information">
	<t>
	  This information model reuses the definition of Resource Block Information adding the associated impairment vector.
	</t>
      <figure align='left'>
	<artwork align="left"> <![CDATA[
ResourceBlockInfo ::= <ResourceBlockSet> [<InputConstraints>]
    [<ProcessingCapabilities>] [<OutputConstraints>] [<OIV>]
]]></artwork>
      </figure>

      <t>
	The object ResourceBlockInfo is than used as specified within <xref	target="RFC7446"/>. 
      </t>

      </section>


      </section> <!-- "Node Information" -->

      <section title="Link Information">
	<t>
	 For the list of optical parameters associated to the link, the same approach used for the 
	 node-specific impairment information can be applied. The link-specific impairment information is
	 extended from <xref target="RFC7446"/> as the following:
	</t>
      <figure align='left'>
	<artwork align="left"> <![CDATA[
<DynamicLinkInfo> ::=  <LinkID> <AvailableLabels>
        [<SharedBackupLabels>] [<OIV>]
]]></artwork>
      </figure>
	<t>
	  DynamicLinkInfo is already defined in <xref target="RFC7446"/> while 
	  OIV is the Optical Impairment Vector is defined in the previous section. 
	</t>
      </section> <!-- "Link Information" -->

      <section title="Path Information">
	<t>
	  There are cases where the optical impairments can only be described as a constrains on 
	  the overall end to end path. In such case, the optical impairment and/or parameter, cannot
	  be derived (using a simple function) from the set of node / link contributions. 
	</t>
	<t>
	  An equivalent case is the option reported by <xref target="RFC6566"/> on IV-Candidate paths  where,
	  the control plane knows a list of optically feasible paths so a new path setup can be selected 
	  among that list. Independent from the protocols and functions  combination (i.e. RWA vs. Routing vs. PCE), 
	  the IV-Candidates imply a path property stating that a path is optically feasible.
	</t>
	<t>
	  The concept of Optical Impairment Vector (OIV) might be used or extended to report optical impairment
	  information at path level however this is case is letf for future studies.
	</t>
    </section> <!-- "Path Information" -->

    </section> <!-- END OF "Optical Impairment Information Model" -->

 
    <section anchor="encoding_considerations" title="Encoding Considerations">
      <t>
	Details about encoding will be defined in a separate document 
	<xref target="I-D.ietf-ccamp-wson-iv-encode"/> however worth remembering that, 
	within <xref target="ITU.G697"/> Appending V,
	ITU already provides a guideline for encoding some optical parameters. 
      </t>
      <t>
	In particular <xref target="ITU.G697"/> indicates that each parameter shall be represented by 
	a 32 bit floating point number.
      </t>
      <t>
	Values for optical parameters are provided by optical node and it could provide by direct measurement or from some 
	internal computation starting from indirect measurement. In such cases, it could be useful to understand the variance
	associated with the value of the optical parameter hence, the encoding shall provide the possibility to include
	a variance as well.
      </t>
      <t>
	This kind of information will enable IA-RWA process to make some
	additional considerations on wavelength feasibility. <xref target="RFC6566"/> 
	Section 4.1.3 reports some considerations regarding this degree of confidence 
	during the impairment validation process.
      </t>

    </section> <!-- END OF "Encoding Considerations" -->

    <section title="Control Plane Architectures">
      <t>
	This section briefly describes how the definitions contained in this 
	information model will match the architectural options 
	described by  <xref target="RFC6566"/>.
	This section does not suggest suggested any specific protocol option.
      </t>
      <t>
	The assumption is that WSON GMPLS extensions are available and operational. 
	To such extent, the WSON-RWA will provide the following information through its
	path computation (and RWA process):
	<list style="symbols">
	  <t> 
	    The wavelengths connectivity, considering also the connectivity constraints 
	    limited by reconfigurable optics, and wavelengths availability. 
	  </t>
	  <t>
	    The interface compatibility at the physical level.
	  </t>
	  <t>
	    The Optical-Elettro-Optical (OEO) availability within the network (and related 
	    physical interface compatibility). As already stated by the framework this information
	    it's very important for impairment validation:
	    <list style="letters">
	      <t>
		If the IV functions fail (path optically infeasible), the path computation function
		may use an available OEO point to find a feasible path. In normally operated networks
		OEO are mainly uses to support optically unfeasible path than mere wavelength 
		conversion.
	      </t>
	      <t>
		The OEO points reset the optical impairment information since a new light
		is generated.
	      </t>
	    </list>
	  </t>
	</list>
      </t>
      
      
      <section title="IV-Centralized ">
       <t>
	 Centralized IV process is performed by a single entity (e.g. a PCE or other external entities). Given sufficient 
	 impairment information, it can either be used to provide a list of paths between two nodes, which
	 are valid in terms of optical impairments. Alternatively, it can help validate whether a particular
	 selected path and wavelength is feasible or not. 
       </t>
       <t>
	 Centralized IV functions requires exchange of impairment information
	 to the entity performing the IV process from network nodes. This information exchange may requires
	 implementation of this information model within an exsting protocol (i.e. routing procol vs PCEP vs BGP-LS vs
	 others).
       </t>
      
      </section>
      
      <section title="IV-Distributed ">
	<t>
	  Assuming the information model is implemented through a routing protocol, every node in the WSON
	  network shall be able to perform an RWA-IV function.
	</t>
	<t>
	   The signalling phase may provide additional checking as others traffic engineering parameters.
	</t>
      </section>	
   
    </section>
    

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
	Authors would like to acknoledge Greg Bernstein and Moustafa
	Kattan as authors of a previous similar draft whose content 
	partially converged here.
      </t>
      <t>
	Authors would like to thank ITU SG15/Q6 and in particular
	Peter Stassar and Pete
	Anslow for providing useful information and text to CCAMP through
	join meetings and liaisons.
      </t>

    </section>

    <!-- Possibly a 'Contributors' section ... -->
    
    <section anchor="Contributors" title="Contributing Authors">
      <t>
	This document was the collective work of several authors.  The text
	and content of this document was contributed by the editors and the
	co-authors listed below:
      </t>
      <figure>
	<artwork><![CDATA[
   Xian Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzen  518129
   P.R. China

   Phone: +86 755 28972913
   Email: zhang.xian@huawei.com

   Domenico Siracusa
   CREATE-NET
   via alla Cascata 56/D, Povo
   Trento  38123
   Italy

   Email: domenico.siracusa@create-net.org

   
   Andrea Zanardi
   CREATE-NET
   via alla Cascata 56/D, Povo
   Trento  38123
   Italy

   Email: andrea.zanardi@create-net.org


   Federico Pederzolli
   CREATE-NET
   via alla Cascata 56/D, Povo
   Trento  38123
   Italy

   Email: federico.perderzolli@create-net.org

   
   ]]></artwork>
      </figure>

    </section>
   

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not contain any IANA requirement.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
	  This document defines an information model for impairments in
   optical networks. If such a model is put into use within a network
   it will by its nature contain details of the physical
   characteristics of an optical network. Such information would need
   to be protected from intentional or unintentional disclosure.
   </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <!-- &RFC2119; -->

      <reference anchor="ITU.G650.1">
	<front>
	  <title>
	    Transmission media and optical systems characteristics - Optical fibre cable
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="July" year="2010"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G.650.1"/>
      </reference>

      <reference anchor="ITU.G650.2">
	<front>
	  <title>
	    Definitions and test methods for statistical and non-linear related attributes of single-mode fibre and cable
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="August" year="2015"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G.650.2"/>
      </reference>

      <reference anchor="ITU.G671">
	<front>
	  <title>
	    Transmission characteristics of optical components and subsystems
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="February" year="2012"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G.671"/>
      </reference>

      <reference anchor="ITU.G680">
	<front>
	  <title>
	    Physical transfer functions of optical network
	    elements
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="July" year="2007"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G.680"/>
      </reference>

      <reference anchor="ITU.G697">
	<front>
	  <title>
	    Optical monitoring for dense wavelength division multiplexing systems
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="February" year="2012"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G.697"/>
      </reference>

      <reference anchor="ITU.GSUP39">
	<front>
	  <title>
	    Optical System Design and Engineering Considerations
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="September" year="2012"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G. Supplement 39"/>
      </reference>

      <reference anchor="ITU.GSUP47">
	<front>
	  <title>
	    General aspects of optical fibres and cables
	  </title>
	      <author>
		<organization>International Telecommunications Union</organization>
	      </author>
	      <date month="September" year="2012"/>
	</front>
        <seriesInfo name="ITU-T" value="Recommendation G. Supplement 47"/>
      </reference>


    </references>

    <references title="Informative References">
      <!-- 
	   Here we use entities that we defined at the beginning.
	   
	   &RFC2629;
	   
	   &RFC3552;
	   
	   &I-D.narten-iana-considerations-rfc2434bis;
	   
	   A reference written by by an organization not a person. 
	   -->

      &RFC6163;
      &RFC6566;
      &RFC7446;
      &RFC7579;
      &I-D.ietf-ccamp-wson-iv-encode;

      <reference anchor="LS78">
	<front>
	  <title>
	    LS/s on CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON
	  </title>
	      <author>
		<organization>International Telecommunications Union SG15/Q6</organization>
	      </author>
	      <date month="October" year="2013"/>
	</front>
	<seriesInfo name="LS" value="https://datatracker.ietf.org/liaison/1288/" />
      </reference>


    </references>

    <section anchor="app-question" title="FAQ">
      <section title="Why the Application Code does not suffice for Optical Impairment Validation?">
	<t>
	  Application Codes are encoded within GMPLS WSON protocol through the Optical Interface
	  Class as defined in <xref target="RFC7446"/>.
 	</t>
	<t>
	  The purpose of the Application Code in RWA is simply to assess the interface
	  compatibility: same Application Code means that two interfaces can have an LSP connecting
	  the two.
	</t>
	<t>
	  Application Codes contain other information useful for IV process (e.g., see the list of parameters) 
	  so they are required however Computational Models requires more parameteres to assess the path feasibility.
	</t>
      </section>
      <section title="Are DWDM network multivendor?">
	<t>
	  According to <xref target="ITU.G680"/> "Situation 1" the DWDM line segments are single are single vendor but 
	  an LSP can make use of different data planes entities from different vendors. For example: DWDM interfaces
	  (represented in the control plane through the Optical Interface Class) from a vendor and network elements described by
	  Stutation 1 from another vendor.
	</t>
      </section>
    </section>



    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>
