One document matched: draft-martinelli-ccamp-opt-imp-fwk-00.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 I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC4054 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4054.xml">
<!ENTITY RFC4202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml">
<!ENTITY RFC4209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4209.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY I-D.draft-ietf-ccamp-wavelength-switched-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wavelength-switched-framework-00.xml">
<!ENTITY I-D.draft-ietf-ccamp-rwa-info SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-info-00.xml">
<!ENTITY I-D.bernstein-ccamp-wson-signaling
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bernstein-ccamp-wson-signaling-02.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 -->
<!-- end of list of popular I-D processing instructions -->
<!-- GM: Make use of editorial comments -->
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<rfc category="info" docName="draft-martinelli-ccamp-opt-imp-fwk-00" ipr="full3978">
<!-- 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="GMPLS Optical Impairments Framework">
A Framework for defining Optical Parameters to be used in WSON networks through GMPLS
</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 Systems</organization>
<address>
<postal>
<street>via Philips 12</street>
<code>20052</code>
<city>Monza</city>
<country>Italy</country>
</postal>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="David Bianchi" initials="D. B." role="editor" surname="Bianchi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>via Philips 12</street>
<code>20052</code>
<city>Monza</city>
<country>Italy</country>
</postal>
<email>davbianc@cisco.com</email>
</address>
</author>
<author fullname="Alberto Tanzi" initials="A. T." role="editor" surname="Tanzi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>via Philips 12</street>
<code>20052</code>
<city>Monza</city>
<country>Italy</country>
</postal>
<email>altanzi@cisco.com</email>
</address>
</author>
<author fullname="Ori Gerstel" initials="O. G." role="editor" surname="Gerstel">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3500 Cisco Way</street>
<code>CA 95134</code>
<city>San Jose</city>
<country>United States</country>
</postal>
<email>ogerstel@cisco.com</email>
</address>
</author>
<author fullname="Andrea Zanardi" initials="A. Z." role="editor" surname="Zanardi">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56 C, Povo</street>
<code>38100</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>andrea.zanardi@create-net.org</email>
</address>
</author>
<date month="October" year="2008" />
<!-- 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>General</area>
<workgroup>Internet Engineering Task Force</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>template</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>
In the context of Wavelength Switched Optical Networks (WSON) the problem of
selecting a lightpath might be constrained by an evaluation of the
optical impairments associated to a wavelength. This is a critical
step in a transparent dense wavelength
division multiplexing (DWDM) optical islands where a lightpath feasibility
has to be assessed between two regenerations nodes.
</t>
<t>
This memo provides a framework in which optical parameters can be
considered a control plane.
The document relies on information already present in ITU documents
and summarize in term of lightpath constraints.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Generalized Multi-Protocol Label Switching (GMPLS), <xref target="RFC3945"/>,
applied to wavelength
switched optical networks (WSON) needs to address specific issues
related to optical technologies.
The framework document
[I-D.draft-ietf-ccamp-wavelength-switched-framework]
address specific issues related to transparent optical networks and to the
routing and wavelength
assignment (RWA) problem. Optical impairments, however, are out of the scope of that
document.
</t>
<t>
One of the key aspects while dealing with transparent DWDM optical networks are the
physical impairments incurred by non-ideal optical transmission media,
and how they accumulate along an optical path.
Because of these impairments, even if there is physical connectivity
(fibers, wavelengths, and nodes) between the ingress and egress nodes,
there is no guarantee that the optical signal (light) reaches
the Egress node with acceptable signal quality in terms of
Bit Error Rate (BER) or other quality measures (e.g. Q-factor).
</t>
<t>
Scope of this framework document is to provide an overview of optical
impairments and parameters that have to be considered to assess the
feasibility of an optical path (lightpath) and provide any
useful information for an impairment-aware protocol implementation.
For this purpose a classification and properties of optical
impairment are provided along with some considerations
related to control plane.
</t>
<t>
The detailed definitions of the physical effects with related mathematical models
are, in general, already defined within ITU-T and this documents will refer to
ITU-T documentation whenever is possible. This document will only report
additional information to determine how this information must be integrated into the
control plane.
</t>
<t>
The document <xref target="RFC4054"/> is another reference targeting optical
network routing along with impairments and constrains. The goal there was to
provide a survey of all optical constrains along with possible approaches.
In this contribution the scope is much more limited, as we only
list optical impairments and their salient properties with respect to control
plane implementation.
</t>
</section> <!-- End of Introduction -->
<!-- #################################################################### -->
<section title="Motivation for an Impairment-Aware Control Plane">
<t>
GMPLS today is not aware of optical impairments in the DWDM network.
This implies that it cannot determine whether an end to end optical path is
feasible or not. While there has been much work on adding wavelength constraints
and other simple parameters to the control plane
([I-D.draft-ietf-ccamp-rwa-info] and
<xref target="I-D.bernstein-ccamp-wson-signaling"/>),
this information alone
does not help determine the feasibility of the path.
In fact, the more impairments are taken into account, the more aggressive the network
can be in terms to reach, and the lower the cost of the solution, since less regenerators
are needed. Conversely, if a limited number of optical impairments is taken into account,
the network must allow for larger margins to account for uncertainty in the missing
parameters, and will have to regenerate more frequently.
</t>
<t>
One question that arises is: why add such information into the control plane and not deal with it through planning tools that today are in charge of optical feasibility determination? The reasons for this are multi-fold:
</t>
<t>
<list style="numbers">
<t>
Issues with offline planning tools.
<vspace blankLines="0" />
Planning tools are typically off line tools and do not have accurate information as to the real impairments in the network. This adds uncertainty and requires higher margins, resulting in more regeneration and a higher cost solution. This problem is exacerbated with higher bit rates (40G+) when more accurate feasibility analysis may be needed due the higher transmission challenges. Moreover, if no feasible optical path exists between the endpoints, planning tools cannot identify the currently available regenerators if they do not have real time data from the network, and therefore require multiple tools (e.g., also an EMS) to be reconciled manually to determine the final path.
</t>
<t>
Issues with online planning tools.
<vspace blankLines="0" />
To address the above issues, the planning tool must be constantly online, however this represents another point of failure in the network and requires extra overhead, e.g., for backing it up. This is not desirable for many operators. So can the planning tool be integrated into the EMS, to reduce the overhead for a standalone tool? In certain cases it can, but many operators may prefer using a higher level generic management tool, which is not provided by the DWDM layer vendor.
</t>
<t>
Issues with pre-determining all feasible paths a-priori.
<vspace blankLines="0" />
While the above approaches assume on-demand computation of a feasible path, a different way to tackle the problem is to pre-define a small number of feasible paths between all required end-points a-priori. In this case, all the control plane needs to do is select one of the feasible paths and set up a connection. This approach will work in small networks, but the number of feasible paths that need to be maintained in a large network may be prohibitive as it requires O(N^2) paths. Another issue with this approach is that it reduces the flexibility of choosing a path as not all feasible paths can be defined a-priori (otherwise the number of paths becomes exponential). This will create artificial blocking, when an alternate non-blocking path may exist. An even worse problem is that when the optical layer evolves (e.g., a fiber added), all paths have to be re-computed which makes this set of paths operationally very hard to maintain.
</t>
</list>
</t>
<t>
In summary, while there are ways to provide a control plane for an optical network that is not aware of impairments, such a solution has various limitations that imply either high capital cost or high operational cost neither of which are acceptable in many SP networks that are under pressure to optimize both CAPEX and OPEX.
</t>
</section> <!-- End of Motivation -->
<!-- #################################################################### -->
<section title="Overview of Optical Impairment Evaluation" anchor="sec_process_flow">
<section title="Impairments Evaluation Flow" anchor="sec_eval_flow">
<t>
The aim of this section is to provide an overview of a typical
decision flow for the evaluation of the feasibility of an optical path.
The feasibility is evaluated given
the transmitter and receiver characteristics, the characteristics of
intermediate nodes, and the optical impairments along the
path from the lightpath source to its destination.
</t>
<figure align="center" anchor="Node_and_links">
<preamble></preamble>
<artwork align="center"><![CDATA[
+--------+ +--------+ +--------+
| | | | | |
| Node #-----------| Node |-----------# Node |
| | Link | | Link | |
+--------+ +--------+ +--------+
TX RX
Interface Interface
]]></artwork>
<postamble></postamble>
</figure>
<t>
<xref target="Node_and_links"/> represents DWDM transparent network can be
represented by nodes, links and interfaces.
<list style="symbols">
<t>
Node. It's an optical network element providing wavelength switching
and multiplexing functionality.
The WSON framework document [I-D.draft-ietf-ccamp-wavelength-switched-framework]
completely describes different node types with their peculiarities.
An optical node can perturb a lightpath quality
by adding impairments due to its internal components. A node may also change the
value of some parameters like the optical power.
</t>
<t>
Link. The fiber is the physical medium of a lightpath and it adds
impairments to the optical signals. In general it causes a
degradation in the signal quality.
</t>
<t>
Interface. Optical Interfaces contains both a transmitter (TX-Interface) and
a receiver (RX-Interface). Depending
on its function different parameters must be considered.
</t>
</list>
</t>
<t>
The measurement of a BER or a Q-Factor completely describes the quality of an
optical signal. However in transparent optical networks there is no direct
measurement of such information. Very often the only way is to provide
measurement of other parameter's (i.e. impairments) and provide an estimation
of the signal quality.
</t>
<t>
Following <xref target="Node_and_links"/> the signal get generated at the
TX-Interface with certain characteristics. Let's consider,
for purposes of illustration, only a couple of simple
parameters: the power of the signal and the signal to noise ratio (OSNR).
Along the lightpath, the signal goes though fiber which reduces its power
and introduces impairments that can be viewed as additional noise
added by the fiber characteristics.
Traversing an optical node the signal
might be amplified so it recover in term of power but this might cause
additional noise to the signal. Optical components (e.g. switches) within the node
are themselves source of additional noise for the signal.
When the signal reaches the RX-Interface at
the destination it must have sufficient power and sufficient OSNR to be used
by the interface.
The acceptable level of the OSNR at the destination as well as the minimum
acceptable power might depend on the
characteristics
of the receiver interface.
</t>
<t>
The next <xref target="estimation_flow"/> provides the functional overview of such
evaluation process.
</t>
<figure align="center" anchor="estimation_flow">
<preamble></preamble>
<artwork align="center"><![CDATA[
+-----------------+ +-----------------+ +------------+
| | | | | |
| Optical | | Optical | | Optical |
| Interface |------->| Path |------->| Channel |
| Characteristics | | Characteristics | | Estimation |
| | | | | |
+-----------------+ +-----------------+ +------------+
||
||
Estimation
||
\/
+------------+
| BER / |
| Q Factor |
+------------+
]]></artwork>
<postamble></postamble>
</figure>
<t>
Starting from the left the Optical Interface Characteristics represents where the
optical signal is transmitted or received and represent the properties at the
end points of a lightpath.
In principle a path computation with no impairments (RWA only) might use only a
minimum set of these parameters to assess the interface compatibility. If impairments
are considered additional parameters become interesting.
<xref target="sec_interface_param"/> details the parameters related to the interfaces.
</t>
<t>
Within the block Optical Path
Characteristics we represents all kind of impairments affecting a lightpath
while it traverse the networks through links and nodes.
<xref target="sec_impairm_list"/> reports a list of of such effects.
</t>
<t>
When reaching the destination node, an impairment-aware constrained path
computation must take a decision if the lightpath is feasible or not.
We call this operation Optical Channel Estimation because the real
signal quality must be estimated given
the impairments along the path.
<xref target="sec_optical_sig_quality"/> reports a set of parameters
that can be used to asses such signal quality.
</t>
</section>
<section title="Parameter Classification According to its Information Complexity" anchor="sec_param_classification">
<t>
As discussed in the previous section, the process of determining the feasibility
of an optical path includes constraints, impairments and other data that relates
to the transmitter (such as modulation format, optical power, supported wavelengths etc.),
data that relates to the optical nodes along the path (loss, gain etc.),
information that relates to the fiber links between the nodes (fiber loss, dispersion etc),
information that relates to other paths that interact with the new path,
and finally the capabilities of the receiver (power sensitivity, error correction etc.).
</t>
<t>
However, not all the data must be shared over the control plane as is.
We distinguish between the following cases:
<list style="symbols">
<t>
Some attributes can be kept local to the node.
For example, receiver attributes may be kept at the end node,
if this node will make the decision on path feasibility.
We call these attributes LOCAL in this document.
</t>
<t>
Other attributes can be shared in a summarized form since the impairment can be accumulated hop by hop. For example optical power can be added or reduced starting from the power at the transmitter as the signaling message traverses various gain or loss elements along the path. These attributes are termed SCALAR herein
</t>
<t>
Some attributes need to be calculated based on all the values of the specific attribute for all the hops along the path. Such values cannot be summarized and need to accumulate in a vector reflecting all the hops along the path. These attributes are termed MULTI-HOP herein (these attributes are called non-linear in the optical jargon)
</t>
<t>
Some values are impacted not just by the new path under consideration but also by other channels that interact with it along its route. The most obvious example for such an attribute is wavelength: the available wavelength is a function of other channels at nodes and links along the path. These attributes are termed MULTI-CHANNEL herein.
</t>
<t>
Finally, some attributes can be computed accurately only if values are known for every channel and every hop along the path. These attributes are termed MULTI-HOP-CHANNEL herein.
</t>
</list>
</t>
<t>
The main contribution of this document is the classification of the various attributes along these cases (LOCAL, SCALAR, MULTI-HOP, MULTI-CHANNEL and MULTI-HOP-CHANNEL). We believe that this information is crucial in order to determine the control plane mechanism needed to carry each attribute. To illustrate this let's assume a particular attribute must be carried in the path signaling message. The attribute will accumulate as follows for the different attribute classes.
</t>
<t>
<list style="symbols">
<t>
LOCAL attributes will not be carried in the message
</t>
<t>
SCALAR attributes will be carried via a single field, with agreed upon rules on how to compute the next value based on the value from the incoming message and the value for the next node and/or link
</t>
<t>
MULTI-HOP attributes must be carried in a vector that fills up in serial fashion from hop to hop, in which the value for the n-th hop is carried in v[n]
</t>
<t>
MULTI-CHANNEL attributes must be carried in a vector that contains one value per channel and in which all values are updated in parallel at every hop (a good example for this is the wavelength bitmap defined in [ref TBD], in which one bit represents the summarized information on the availability of a specific wavelength along the path), and
</t>
<t>
MULTI-HOP-CHANNEL attributes requires a matrix m[h,w] with h rows (one per hop) and w columns (one per wavelength), in which row m[n,*] represents the values for all channels for the n-th hops along the path
</t>
</list>
</t>
</section>
<section title=" Additional Parameter Sharing Properties" anchor="sec_param_properties">
<t>
For the usage in a control plane, other properties for each parameter
should also be considered. The association between each parameter and
a set of its inherent properties is defined within ITU documents.
For a
control plane usage however the following value of each property should help
in deciding the most appropriate protocol to convey the parameter
within he control plane.
</t>
<t>
<list style="symbols">
<t>
Time Dependency.
<vspace blankLines="0" />
If a parameter is static then we assume it does not change
during the life of the network. In case there is a time
dependency a minimum refresh rate shall be provided.
This may help
determine, for example whether the parameter should be considered once
during connection setup, or whether the properties should be refreshed
(e.g. via an IGP or signaling).
</t>
<t>
Wavelength Dependency.
<vspace blankLines="0" />
A parameter can be wavelength dependent if, for each wavelenght
it might have different value. On the contrary a parameter might
have a single value for all the wavelengths.
</t>
<t>
Value type (real, discrete, etc.).
<vspace blankLines="0" />
This kind of information should
help in encoding the information within the protocol. Because
some of the parameters represent physical quantities discrete values
might be used within certain approximations, in other cases real
(e.g. IEEE 754 standard) might be required.
</t>
<t>
Does the variance of the parameter need to be specified with it
(so an error may be computed along with it)?
</t>
</list>
</t>
</section>
</section> <!-- End of Section Evaluation Overview -->
<!-- #################################################################### -->
<section title="Control Plane Considerations">
<t>
[Editorial Note: This section has to be filled up. Current text only as
initial placeholder].
</t>
<t>
The use of optical impairments as path constrains would
imply the control plane (GMPLS) to be aware of some additional
information coming from the optical layer. The control plane
shall be able to convey the proper information for
an to allow the optical path feasibility calculation.
</t>
<t>
</t>
<t>
<list style="symbols">
<t>
Routing.
<vspace blankLines="0" />
Routing extensions to support GMPLS are defined in <xref target="RFC4202"/>.
Needs additional information to defines routing metrics with a certain
level of optical-impairment awareness.
</t>
<t>
Signaling.
<vspace blankLines="0" />
Optical constrains can be verified along the signaling phase. Different
options might be foreseen:
<list style="symbols">
<t>
Full optical impairment verification. If the routing phase
has no awareness of any optical impairments, the signaling
phase can verify all of them.
</t>
<t>
Partial optical impairment verification. It might be possible
that a certain set of optical impairment are verified during
the routing phase while the remaining set can be performed
during the signaling phase.
</t>
</list>
</t>
<t>
PCE Architecture <xref target="RFC4655"/>.
<vspace blankLines="0" />
In case a PCE is used to support path computation, an additional solution
might foresee a PCE capable of supporting an impairment-aware path
computation. Need to evaluate the information to convey to the PCE
for such computation.
</t>
</list>
</t>
</section>
<!-- #################################################################### -->
<section title="Optical Interface Characteristics" anchor="sec_interface_param">
<t>
Placeholder for details optical parameters that specifically refer to
the physical interface. Their knowledge is necessary to evaluate the
path feasibility in term of optical impairments.
</t>
<t>
They can be classified for what related to transmitter
(e.g. bit rate, modulation format, FEC etc.) and receiver (e.g. stability, CD robustness)
interface. The document <xref target="ITU.G698.2"/> provide a detailed list of parameteres
with their values.
</t>
</section>
<!-- #################################################################### -->
<section title="Optical Path Characteristics" anchor="sec_impairm_list">
<t>
This section describes the optical impairments associated to the path
optical elements defined in <xref target="sec_process_flow" />.
For each impairment, the following information is provided:
<list style="symbols">
<t>
A minimum impairment description with a reference to the related ITU-T document
where available.
</t>
<t>
the impairment classification and properties as defined within
<xref target="sec_param_classification"/> and
<xref target="sec_param_properties"/>.
</t>
<t>
the impairment evaluation/handling techniques.
</t>
<t>
the impairment impact on the channel quality estimation as defined by
parameters in Section 3.3.
</t>
</list>
</t>
<section title="Linear Impairments">
<section title="Fiber Losses">
<t>
It's the optical power loss caused by a fiber span [ITU-T ref ?].
It's measured as the ratio (dB) between the input and the output optical power.
</t>
<t>
The loss introduced by each fiber span depends on:
<list style="symbols">
<t>
fiber attenuation coefficient (dB/Km)
</t>
<t>
fiber length (Km). Note that this value is one of the
link characteristics defined in <xref target="RFC4209"/> (section 2.3.5).
</t>
</list>
</t>
<t>
The fiber losses directly affect the signal optical power at the receiver interface:
losses are accumulated along the path and compensated by Optical Amplifiers.
</t>
<t>
The fiber loss can be computed from the fiber nominal values
(length and attenuation coefficient),
measured by the node (using a probe signal) or provisioned as a link parameter.
</t>
<t>
The impairment is SCALAR, wavelength independent, time independed
(apart from fiber aging but only on long period of times).
</t>
</section>
<section title="Insertion Losses (Optical components looses)">
<t>
It's the optical power loss caused by the optical elements crossed by the channel in a node.
It's measured as the ratio (dB) between the optical power at the input and output port
(see <xref target="ITU.G671" /> Section 3.2.9).
The possible channel paths in a node are (see <xref target="ITU.G680" /> Section 3.2.1):
<list style="symbols">
<t>
from the input port to the output port for through channels
</t>
<t>
from the input port to the drop port for dropped channels
</t>
<t>
form the add port to the output port for added channels
</t>
</list>
</t>
<t>
This classification applies to any type of node: PXC, ROADM, etc.
The loss value for each path is dependent on the internal node architecture
and vendor device characteristics and could be different for each different port pair.
</t>
<t>
The insertion losses directly affect the signal optical power at the receiver interface:
losses are accumulated along the path and compensated by Optical Amplifiers.
</t>
<t>
The impairment is SCALAR, wavelength independent and time independent.
</t>
</section>
<section title="Amplifier Spontaneous Emission (ASE)">
<t>
It's the noise introduced by the node optical amplifiers spontaneous emission
that propagates with the amplified signal and is further amplified along the path
(see <xref target="ITU.G663" /> Section II.6.1).
The impairment is considered an OSNR contribution (dB) and directly affects the
signal SNR at the receiver interface (see <xref target="ITU.G663" /> Section II.6.2).
</t>
<t>
The ASE noise contribution can be evaluated from the amplifier parameters and the
input signal characteristics (signal optical power).
</t>
<t>
The impairment is SCALAR and wavelength independent. Regarding time-dependency ASE
depends on amplifier gain and this may change depending on network stability.
</t>
</section>
<section title="Crosstalk">
<t>
It's the effect of signal power leakage from other channels inside the node
optical elements (multiplexer, de-multiplexer, optical switches, etc.) and is
measured as the ratio of the disturbing power and the signal power (dB)
(see <xref target="ITU.G692" /> Section 6.7.1).
</t>
<t>
The crosstalk value is dependent on the device characteristics and the ratio of the
optical power of involved channels.
The device characteristics can be considered constant in time, while the
channels configuration depends on the network status.
</t>
<t>
The crosstalk impairment affects the signal SNR and optical power at the receiver
interface: the accumulated crosstalk can be converted to an SNR and power penalty.
</t>
<t>
The impairment is MULTI-CHANNEL (depends on existings active channels) and
wavelength independent.
</t>
</section>
<section title="Fiber Chromatic Dispersion">
<t>
It's the degradation of the optical signal due to the different propagation
delay of the various spectral components causing the broadening of the pulse and
is defined by the slope of the delay with respect to the wavelength (ps/nm)
(see <xref target="ITU.G650" /> Section 1.5).
The effect can be compensated by means of fiber spans with an inverse dispersion
(DCF - Dispersion Compensation Fiber) usually deployed in modules with
pre-configured characteristics (DCU - Dispersion Compensation Unit).
</t>
<t>
The chromatic dispersion introduced by each fiber span is dependent on:
<list style="symbols">
<t>
fiber chromatic dispersion coefficient (ps/(nm * Km))
This coefficient depends on the channel wavelength (it's usually
defined as the value for a reference wavelength and a slope coefficient).
</t>
<t>
fiber length (Km).
</t>
</list>
</t>
<t>
The chromatic dispersion of each fiber span can be evaluated from the
fiber characteristics and the channel wavelength.
</t>
<t>
The chromatic dispersion accumulates along the path compensated by the DCU
modules obtaining a residual chromatic dispersion at the receiver interface
the affects the signal SNR.
</t>
<t>
The impairment is SCALAR, Wavelength-Dependent and time-independent
(apart from ageing effects over long period of times).
</t>
</section>
<section title="Polarization Mode Dispersion (PMD)">
<t>
It's the degradation of the optical signal due to the different propagation
delay of the two principal states of polarization (DGD - Differential Group Delay)
causing the pulse distortion in shape and width
(see <xref target="ITU.G663"/> Section II.4.1 and <xref target="ITU.G661"/> Section 5.1.36)
and is measured in ps.
</t>
<t>
The PMD introduced by a fiber span depends on:
<list style="symbols">
<t>
the square root of the fiber length (Km)
</t>
<t>
the fiber PMD coefficient (ps/sqrt(Km))
</t>
</list>
</t>
<t>
The PMD introduced by other components (e.g. amplifiers, DCU modules, etc.) is
provided as a device parameter.
</t>
<t>
The PMD coefficient may depend on temperature and operating conditions and can be very variable.
</t>
<t>
The PMD can be evaluated from the fiber or device parameters; due to the high
variability, an upper bound value is usually considered.
</t>
<t>
The PMD accumulates along the path and affects the signal SNR at the receiver interface.
</t>
<t>
The impairment is SCALAR.
</t>
</section>
<section title="Polarization Dependent Loss (PDL)">
<t>
It's the difference in the signal power among different polarization states
caused by the medium irregularities (see <xref target="ITU.G663"/> Section II.4.1
and <xref target="ITU.G671"/> Section 3.2.23) and is defined as the ratio (dB)
of the maximum and minimum peak transmission power with respect to all polarization states.
On amplifiers the same effect is called Polarization Dependent Gain (PDG)
(see <xref target="ITU.G661"/> Section 5.1.11).
</t>
<t>
The PDL introduced by a device appears as a random variation of the signal power
and can be managed as a statistical value (function of the number of
optical elements traversed) (see <xref target="ITU.G680"/> Section 9.3.2).
</t>
<t>
The PDL accumulates along the path and affects the signal SNR and power
at the receiver interface.
</t>
<t>
The impairment is and SCALAR wavelength independent.
</t>
</section>
</section> <!-- Linear Impairments -->
<section title="Fiber Optical Non-Linearities">
<t>
In this section provide information about optical impairments called Non-Linear.
In general
they will need a control plane able to exploit multi-channel and multi-hop
attibutes. Due to this complexity leave this placeholder for further
updates.
</t>
<t>
<list style="symbols">
<t>
Self Phase Modulation (SPM) (see <xref target="ITU.G663"/> Section II.3.1).
<vspace blankLines="0" />
It's the degradation of the optical signal due to the time varying
fiber refraction index (the higher intensity portion of the pulse is
subject to a higher refractive index than the lower intensity portion)
causing the pulse broadening in the frequency domain.
</t>
<t>
Cross Phase Modulation (XPM) (see <xref target="ITU.G663"/> Section II.3.3).
<vspace blankLines="0" />
It's the degradation of the optical signal due to the time varying fiber
refraction index induced by the adjacent channels intensity fluctuations.
</t>
<t>
Four Wave Mixing (FWM) (see <xref target="ITU.G663"/> Section II.3.5).
<vspace blankLines="0" />
It's the degradation of the optical signal due to the interaction with the
spurious optical wavelengths generated by three optical channels that co-propagate
inside a fiber.
</t>
<t>
Stimulated Brillouin Scattering (SBS) (see <xref target="ITU.G663"/> Section II.3.6).
<vspace blankLines="0" />
It's the degradation of the optical signal due to the signal scattering
caused by the fiber medium when the input power is above the SBS threshold.
</t>
<t>
Stimulated Raman Scattering (SRS) (see <xref target="ITU.G663"/> Section II.3.6).
<vspace blankLines="0" />
It's the degradation of the optical signal due to the signal scattering
caused by the fiber medium when the input power is above the SBS threshold.
</t>
</list>
</t>
</section> <!-- End Of Section: Fiber Optical Non Linearities -->
</section> <!-- Endofsection: Path Optical Impairments -->
<!-- ################################################################### -->
<section title="Optical Channel Estimation" anchor="sec_optical_sig_quality">
<t>
The lightpath quality defines the ability of the receiver to correctly decode
the signal within a defined error rate (BER).
The BER depends on the signal encoding (e.g. FEC, modulation format, etc.),
the signal optical characteristics (optical power, OSNR, etc.)
and the receiver characteristics.
</t>
<t>
The goal of this section is to define the set of parameters that need to be
evaluated in order to get a direct estimation of the lightpath quality at the
receiver node; all the above described impairments can be considered as an effect
on these parameters.
</t>
<t>
These optical parameters shall be considered together with their statistical values:
average and variance. This information helps in understanding the error accumulated
along with parameter evaluation.
</t>
<section title="Optical Power">
<t>
The signal optical power must be within the dynamic range of the receiver and
above the receiver minimum power (receiver sensitivity).
The receiver minimum power is a receiver characteristic and depends also on
the signal characteristics as the used forward error correction (FEC), [others ? mod-format ?]
</t>
<t>
<cref anchor="Q3" source="GM"> Need to add a formal definition with the ITU reference </cref>
</t>
</section>
<section title="Optical Signal to Noise Ratio">
<t>
The optical signal-to-noise ratio (OSNR) is the ratio of the signal power
in the wanted channel to the highest noise power density (referred to 0.1 nm)
within the channel frequency range
(see <xref target="ITU.G661"/> Section 5.1.19).
The signal OSNR must be above a receiver minimum threshold (receiver sensitivity);
the threshold is a receiver characteristic and depends also
on the signal characteristics ([which ones ?]).
</t>
</section>
<section title="Residual Chromatic Dispersion">
<t>
The residual chromatic dispersion is the signal chromatic
dispersion at the receiver interface (the accumulated and
compensated dispersion along).
The signal dispersion value must be within a receiver threshold
for the signal to be correctly decoded.
</t>
<t>
The chromatic dispersion effects on the signal quality can
be managed as an OSNR or/and an optical power penalty.
</t>
</section>
<section title="Residual Differtial Group Delay (DGD)">
<t>
[Editoral Note: TO BE FILLED]
</t>
</section>
<section title="Q-Factor" >
<t>
The Q-factor is a synthetic measure of the signal quality defined
as a function of the mean values of the '0' and '1' signal levels
and their standard deviation
(see <xref target="ITU.G976"/> Section A.1).
</t>
<t>
The Q-factor is dependent on the signal OSNR and is
directly related to the BER.
</t>
<t>
The evaluation of the Q-factory requires the estimation
of the signal waveform at the receiver interface.
</t>
</section>
</section> <!-- Endofsection: sec_optical_sig_quality -->
<!-- ################################################################### -->
<!-- ############################## -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Authors would like to thanks Adrian Farrel for all suggestions and
reviews of this work.
</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[
Gabriele Maria Galimberti
Cisco Systems
via Philips 12
Monza 20052
Italy
Email: ggalimbe@cisco.com
Domenico La Fauci Maurizio Gazzola
Cisco Systems Cisco Systems
via Philips 12 via Philips 12
Monza 20052 Monza 20052
Italy Italy
Email: dlafauci@cisco.com Email: mgazzola@cisco.com
Roberto Cassata Zafar Ali
Cisco Systems Cisco Systems
via Philips 12 3000 Innovation Drive
Monza 20052 Kanata , ONTARIO K2K 3E8
Italy Canada
Email: rcassata@cisco.com Email: zali@cisco.com
Elio Salvadori Yabin Ye
CREATE-NET CREATE-NET
via alla Cascata 56 C, Povo via alla Cascata 56 C, Povo
Trento 38100 Trento 38100
Italy Italy
Email: elio.salvadori@create-net.org Email: yabin.ye@create-net.org
Chava Vijaya Saradhi
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100
Italy
Email: saradhi.chava@create-net.org
Ernesto Damiani
University of Milan, Department of Information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: damiani@dti.unimi.it
Valerio Bellandi
University of Milan, Department of Information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: bellandi@dti.unimi.it
Marco Anisetti
University of Milan, Department of Information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: anisetti@dti.unimi.it
]]></artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.</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">
&RFC3945;
&RFC4202;
&RFC4209;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.draft-ietf-ccamp-wavelength-switched-framework;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3552;
&RFC4054;
&RFC4655;
&I-D.draft-ietf-ccamp-rwa-info;
&I-D.bernstein-ccamp-wson-signaling;
<reference anchor="ITU.G650">
<front>
<title>
Definition and test methods for the relevant parameters of single-mode fibres
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="March" year="1993"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.650"/>
</reference>
<reference anchor="ITU.G661">
<front>
<title>
Definitions and test methods for the relevant
generic parameters of optical amplifier devices
and subsystems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.661"/>
</reference>
<reference anchor="ITU.G663">
<front>
<title>
Application related aspects of optical amplifier
devices and sub-systems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="April" year="2000"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.663"/>
</reference>
<reference anchor="ITU.G671">
<front>
<title>
Transmission characteristics of optical
components and subsystems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="Jannuary" year="2005"/>
</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.G692">
<front>
<title>
Optical interfaces for multichannel systems
with optical amplifiers
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="October" year="1998"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.692"/>
</reference>
<reference anchor="ITU.G697">
<front>
<title>
Optical monitoring for DWDM systems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="June" year="2004"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.697"/>
</reference>
<reference anchor="ITU.G698.2">
<front>
<title>
Amplified multichannel DWDM applications with
single channel optical interfaces
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.697"/>
</reference>
<reference anchor="ITU.G976">
<front>
<title>
Test methods applicable to optical fibre
submarine cable systems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.976"/>
</reference>
&I-D.narten-iana-considerations-rfc2434bis;
</references>
<section anchor="app-ITU-communication" title="ITU Parameters Missing Information">
<t>
In this appendix we need to collects all information about optical
parameters that need to be verified with / requested from ITU.
</t>
</section>
<!-- Change Log
v00 2008-09-08 GM Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:17:36 |