One document matched: draft-martinelli-ccamp-wson-iv-info-03.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 I-D.ietf-ccamp-rwa-info SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-info-19.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-13.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-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-martinelli-ccamp-wson-iv-info-03" 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 Philips 12</street>
<city>Monza</city>
<region></region>
<code>20900</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 Philips,12</street>
<city>Monza</city>
<code>20900</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>
<date month="february" year="2014" />
<!-- 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) function. This operation might be required in
Wavelength Switched Optical Networks (WSON) that already support RWA and the information model defined
here goes in addition and it is fully compatible with the already defined information model for
impairment-free RWA process in WSON.
</t>
<t>
This information model shall support all control plane architectural options defined for WSON with
impairment validation.
</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="I-D.ietf-ccamp-rwa-info"/> defines all information/parameters
required by an RWA process.
</t>
<t>
There are cases of WSON where optical impairments plays a significant role and
are considered as important
constraints. The framework document <xref target="RFC6566"/> defines problem scope
and related control plane
architectural options for the Impairment Aware Routing and Wavelength Assignment (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>
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="I-D.ietf-ccamp-rwa-info"/> and
it 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 control plane
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 concepts used
along the document and to make a clear sepration about what coming
from data plane definitions (ITU-T G recomandations) and are taken as input for this Information Model.
The first sub-section provides raw definitions while the Applicability sections reuses
the defined concepts 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 looks for models that
are able to compute optical impairments for a give lightpath.
</t>
<t>
Information Model.<vspace blankLines="0" />
It is defined by IETF (this draft) and provide the set of information
required by the Computational Model to be applied.
</t>
<t>
Level of Approximation.<vspace blankLines="0" />
This concept refer 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"/> make a rough
classification about it.
</t>
<t>
Feasible Path.<vspace blankLines="0" />
It is the output of the CSPF with RWA-IV capability. It's a path that
satisfies the constraints in particular the optical impairment contraints.
The path, instantiated through wavelength, may actually work or not work depending
of the level of approximation.
</t>
<t>
Existing Service Disruption.<vspace blankLines="0" />
A known effect to optical network designers is the cross-interaction among adjacent (specrum)
wavelengths, e,g,,a wavelength may exeperience some increased BER due to the setting up of
an adjacent wavelength. Solving this problem is a typical optical network design activity.
Just as an example a simple method is adding optical margings (e.g., additional OSNR),
other complex and detailed methods exist.
</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 cover information
mainly provided by
the <xref target="ITU.G680"/> Computational Model.
</t>
<t>
Computational models having no approximation, referred as IV-Detailed in the <xref target="RFC6566"/>,
currently does not exist in term of ITU-T recomandation. They generally refer to non-linear
optical impairment and they are usually vendor specific.
</t>
<t>
The current information model
does not speculate about mathematical formula used to fill up information model parameters hence,
it does not preclude changing the computational model. At the same time authors does not belive this
Information Model is exhaustive and if necessary further documents will cover additional
models as long as they become available.
</t>
<t>
The result of RWA-IV process implementing this Information Model will result in a path (a wavelength in
the data plane) that have 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 network designers: this model
does not replace by any means the optical network design
phase. The Information Model targets,
the GMPLS context with the releated relationship between data plane(s)
and control plane.
</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 behavior 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 does 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 cosider this kind of property.
</t>
</list>
</t>
<t>
The following table summarize 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>
[EDITOR NOTE: To better integrate material coming from ITU
WD06-31 October 2013 and future liasons]
</t>
<t>
As stated by <xref target="sec_applicability"/> this
Information Model does not intend to be exaustive and targets
an approximate computational model although not precluding
future evolutions towards more detailed impairments estimation
methods.
</t>
<t>
On the same
line, ITU SG15/Q6 provides a list of optitical 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 and <xref target="ITU.G697"/>
contains information
on which parameters can be monitored in an optical network.
</t>
<t>
<xref target="ITU.G671"/> contains some additional parameters
defintions required by here above recomandation.
</t>
<t>
The list of optical parameters starts from <xref
target="ITU.G680"/> Section 9 which provides the optical computational models
for the following:
<list style="format P%d" counter="par_count">
<t>OSNR. Section 9.1</t>
<t>Optical Power. As per Section 9.1, required by Optical Computation Model for OSNR calculation.</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 ITU SG15/Q6.
<list style="format P%d" counter="par_count">
<t> Channel Frequency Range <xref target="ITU.G671"/>.
</t>
<t> Ripple
</t>
<t> Channel Signal-Spontaneous noise figure. This is
considered within OSNR computational model above.
</t>
<t> Differential Group Delay <xref
target="ITU.G671"/>. Required for PMD above.
</t>
<t> Reflectance.
</t>
<t> Isolation.
</t>
<t> Channel extintion.
</t>
<t> Non-Linear Coefficient (for a fibre segment). Needed for non-linear impairment
</t>
</list>
</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="I-D.ietf-ccamp-rwa-info"/> and <xref target="I-D.ietf-ccamp-general-constraint-encode"/>.
The purpose is to provide essential information
that will be reused or extended for the impairment case.
</t>
<t>
In particular <xref target="I-D.ietf-ccamp-rwa-info"/> defines the connectivity matrix as the following:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
ConnectivityMatrix ::= <MatrixID> <ConnType> <Matrix>
]]>
</artwork>
</figure>
<t>
According to <xref target="I-D.ietf-ccamp-general-constraint-encode"/>, 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 connectivity matrix 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, connectivity matrix belongs to node information and is purely static.
Dynamic information related to the actual usage of the connections is
available through specific extension to link information.
</t>
<t>
Furthermore <xref target="I-D.ietf-ccamp-rwa-info"/> define
the resource block as follow:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
ResourceBlockInfo ::= <ResourceBlockSet> [<InputConstraints>]
[<ProcessingCapabilities>] [<OutputConstraints>]
]]>
</artwork>
</figure>
<t>
Which is an efficient way to model constrains of 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 node gets 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="I-D.ietf-ccamp-general-constraint-encode"/>.
</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="I-D.ietf-ccamp-rwa-info"/>
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="I-D.ietf-ccamp-general-constraint-encode"/>.
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="I-D.ietf-ccamp-general-constraint-encode"/>
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="Impariment Resource Block Information">
<t>
This information model reuse 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="I-D.ietf-ccamp-rwa-info"/>.
</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="I-D.ietf-ccamp-rwa-info"/> 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="I-D.ietf-ccamp-rwa-info"/> 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 could be useful to un 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>
[EDITOR NOTE: to be completed]
</t>
</section>
<section title="IV-Distributed ">
<t>
For the distributed IV process, common computational models are needed together with
the information model defined in this document. Computational models for the optical impairments
are defined by ITU standard body. The currently available computation models are reported
in <xref target="ITU.G680"/> and only cover the linear impairment case. This does not require
the distribution of impairment information since they can be collected hop-by-hop using a control
plane signaling protocol.
</t>
<t>
[EDITOR NOTE: to be completed]
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Authors would like to thank ITU SG15/Q6 and in particular Pete
Anslow for providing text and information to CCAMP through
join meetings and liasons.
</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>
<figure align='left'>
<artwork align="left">
<![CDATA[
Moustafa Kattan
Cisco
DUBAI, 500321
UNITED ARAB EMIRATES
Email: mkattan@cisco.com
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
Email: ylee@huawei.com
Greg M. Bernstein
Grotto Networking
Fremont, CA
USA
Phone: +1 510 573 2237
Email: gregb@grotto-networking.com
Fatai Zhang
Huawei
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
P.R. China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Federico Pederzolli
CREATE-NET
via alla Cascata 56/D, Povo
Trento 38123
Italy
Email: federico.pederzolli@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.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>
</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;
&I-D.ietf-ccamp-rwa-info;
&I-D.ietf-ccamp-general-constraint-encode;
&I-D.martinelli-ccamp-wson-iv-encode;
</references>
<section anchor="app-additional" title="ITU-T Liason Tracking">
<t>
[EDITOR NOTE: appendix reserved to track liason to/from ITU
related to this draft]
</t>
</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 07:33:58 |