One document matched: draft-ietf-ccamp-wson-iv-info-02.xml
<?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.martinelli-ccamp-wson-iv-encode SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-martinelli-ccamp-wson-iv-encode-05.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-02" 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></region>
<code>20871</code>
<country>Italy</country>
</postal>
<phone>+39 039 2092044</phone>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Xian Zhang" initials="X.Z." role="editor"
surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>F3-5-B R<![CDATA[&]]>D Center, Huawei Base</street>
<street>Bantian, Longgang District</street>
<city>Shenzen</city>
<region></region>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone>+86 755 28972465</phone>
<email>zhang.xian@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>
<code>20871</code>
<country>Italy</country>
</postal>
<phone>+39 039 2091462</phone>
<email>ggalimbe@cisco.com</email>
</address>
</author>
<author fullname="Andrea Zanardi" initials="A. Z." surname="Zanardi">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56/D, Povo</street>
<code>38123</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>andrea.zanardi@create-net.org</email>
</address>
</author>
<author fullname="Domenico Siracusa" initials="D. S." surname="Siracusa">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56/D, Povo</street>
<code>38123</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>domenico.siracusa@create-net.org</email>
</address>
</author>
<author fullname="Federico Pederzolli" initials="F.P." surname="Pederzolli">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56/D, Povo</street>
<code>38123</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>federico.perdezolli@create-net.org</email>
</address>
</author>
<author fullname="Young Lee" initials="Y.L."
surname="Lee">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 100</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>U.S.A</country>
</postal>
<email>ylee@huawei.com</email>
</address>
</author>
<author fullname="Fatai Zhang" initials="F.Z."
surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>F3-5-B R<![CDATA[&]]>D Center, Huawei Base</street>
<street>Bantian, Longgang District</street>
<city>Shenzen</city>
<region></region>
<code>518129</code>
<country>P.R. China</country>
</postal>
<email>zhang.fatai@huawei.com</email>
</address>
</author>
<date month="October" year="2015" />
<!-- 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
foundamental 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. 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 [G.sup47] 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 definitive or
exaustive.
</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)", [ITU.G650.2, 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 paramterer 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)", [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 explaing that it does not represent any particular
internal blocking behavior 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 adverstising 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 resorurce 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 information model is to categorize the impairment parameters into three types
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 modelization 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
extentions 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 paramters
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 examples while details go into specific
encoding draft <xref target="I-D.martinelli-ccamp-wson-iv-encode"/>.
</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 impariments can only be described as a contrains on
the overall end to end path. In such case, the optical impariment 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>
<!--
GIOVANNI: try to rephrase ... anyway a really open chapter here....
<t>
[Xian's note]: I did not find related description about this in Section 4.2.2. Could you explain the
rationale behind this category? I think it might also be a good idea to rearrange the sections to put
the ImpairmentVector as a fundemental object and then introduce node/link/path level since all of them
use it as a basis. Another comment about the following format: where should be an identifier needed
for the path before the impairment information?]
</t>
-->
<figure align='left'>
<artwork align="left">
<![CDATA[
<PathInfo> ::= <OIV>
]]>
</artwork>
</figure>
<t>
[EDITOR NOTE: section to be completed, especially to evaluate protocol implications. Likely resemble to
RSVP ADSPEC].
</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.martinelli-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 parmater 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 defintions contained in this
information model will match the architectural options
described by <xref target="RFC6566"/>.
</t>
<t>
The first assumption is that the WSON GMPLS extentions 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). 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 feasiable or not. This requires distribution of impairment information
to the entity performing the IV process.
</t>
<t>
This Informaton Model doesn't make any hypotesys on distribution method for optical parameters but only defines the
essential build blocks. A centralized entity may get knowledge of required informaton through
routing protocools or other mechanism such as BGP-LS.
</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 (the contact information for the editors
appears in appropriate section and is not repeated below):
</t>
</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.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>
</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.martinelli-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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:52:37 |