CCAMP G. Martinelli, Ed.
Internet-Draft Cisco
Intended status: Informational X. Zhang, Ed.
Expires: January 4, 2018 Huawei Technologies
G. Galimberti
A. Zanardi
D. Siracusa
F. Pederzolli
Y. Lee
F. Zhang
Huawei Technologies
July 3, 2017

Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 4, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

In the context of Wavelength Switched Optical Network (WSON), [RFC6163] describes the basic framework for a GMPLS and PCE-based Routing and Wavelength Assignment (RWA) control plane. The associated information model [RFC7446] defines information/parameters required by an RWA process without optical impairment considerations.

There are cases of WSON where optical impairments play a significant role and are considered as important constraints. The framework document [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).

A Control Plane with RWA-IA will not be able to solve the optical impairment problem in a detailed and exhaustive way, however, it may take advantage of some data plane knowledge to make better decisions during its path computing phase. The final outcome will be a path, instantiated through a wavelength in the data plane, that has a "better chance" to work than that path were calculated without IA information. "Better chance" means that path setup may still fail and the GMPLS control plane will follow its usual procedures upon errors and failures. A control plane will not replace a the network design phase that remains a fundamental step for DWDM Optical Networks. As the non-linear impairments which need to be considered in the calculation of an optical path will be vendor-dependent, the parameters considered in this document is not an exhaustive list.

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 [RFC7446] and shall support any control plane architectural option described by the framework document (see sections 4.2 and 4.3 of [RFC6566]) where a set of combinations of control plane functions vs. IV function is provided.

2. Definitions, Applicability and Properties

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.

2.1. Definitions

2.2. Applicability

This document targets at Scenario C defined in [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 [ITU.G680] Computational Model.

Computational models having no or little approximation, referred as IV-Detailed in the [RFC6566], currently does not exist in term of ITU-T recommendation. They generally deal with non-linear optical impairment and are usually vendor specific.

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.

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.

2.3. Properties

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 [RFC6566]. In some case, properties value will help to identify the level of approximation supported by the IV process.

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.

Optical Impairment Properties
Property Info Model Awareness
Time Dependency no
Wavelength Dependency yes
Linearity yes
Multi-channel no

3. ITU-T List of Optical Parameters

As stated by Section 2.2 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.

On the same line, ITU SG15/Q6 provides (through [LS78]) a list of optical parameters with following observations: [ITU.G680] contains many parameters that would be required to estimate linear impairments. Some of the Computational Models defined within [ITU.G680] requires parameters defined in other documents like [ITU.G671]. The purpose of the list here below makes this match between the two documents.

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 [ITU.G680] "Situation 1".
The generated list of parameters is not exhaustive however provide a guideline for control plane optical impairment awareness.

In particular,

[ITU.G697] defines parameters can be monitored in an optical network. This Information Model and associated encoding document will reuse [ITU.G697] parameters identifiers and encoding for the purpose of path computation.

The list of optical parameters starts from [ITU.G680] Section 9 which provides the optical computational models for the following p:

OSNR. Section 9.1
Chromatic Dispersion (CD). Section 9.2
Polarization Mode Dispersion (PMD). Section 9.3
Polarization Dependent Loss (PDL). Section 9.3

In addition to the above, the following list of parameters has been mentioned by [LS78]:

"Channel frequency range", [ITU.G671]. This parameter is part of the application code and encoded through Optical Interface Class as defined in [RFC7446].
"Modulation format and rate". This parameter is part of the application code and encoded through Optical Interface Class as defined in [RFC7446].
"Channel power". Required by G-1.
"Ripple". According to [ITU.G680], this parameter can be taken into account as additional OSNR penalty.
"Channel signal-spontaneous noise figure", [ITU.G680]. Required by OSNR calculation (see G-1) above.
"Channel chromatic dispersion (for fibre segment or network element)". Already in G-2 above.
"Channel local chromatic dispersion (for a fibre segment)". Already in G-2 above (since consider both local and fiber dispersions).
"Differential group delay (for a network element)", [ITU.G671]. Required by G-3.
"Polarisation mode dispersion (for a fibre segment)", [ITU.G650.2], [ITU.G680]. Defined above as G-3.
"Polarization dependent loss (for a network element)", [ITU.G671] and [ITU.G680]. Defined above as G-4.
"Reflectance". From [ITU.G671] Section 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.
"Channel Isolation". From [ITU.G671] Section (Adjacent Channel Isolation) and Section (Non Adjacent Channel Isolation). Document [ITU.GSUP39] provide the formula for calculation as channel cross-talk and measure it in dB. This parameterer shall be considered for path computation.
"Channel extinction". From [ITU.G671] Section needed for Interferometric Crosstalk. Document [ITU.GSUP39] has the formula for penalty computation. Unit of measurement is dB.
"Attenuation coefficient (for a fibre segment)". Document [ITU.G650.1] Section 3.6.2. The unit of measure is dB. This is a typical link parameter (as associated to a fiber).
"Non-linear coefficient (for a fibre segment)", [ITU.G650.2]. Required for Non-Linear Optical Impairment Computational Models. Neglected by this document.

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.

4. Background from WSON-RWA Information Model

In this section we report terms already defined for the WSON-RWA (impairment free) as in [RFC7446] and [RFC7579]. The purpose is to provide essential information that will be reused or extended for the impairment case.

In particular [RFC7446] Section 4.1 defines the ConnectivityMatrix and states that such matrix does not represent any particular internal blocking behaviour but indicates which input ports and wavelengths could possibly be connected to a particular output port.

<ConnectivityMatrix> ::= <MatrixID> <ConnType> <Matrix>

According to [RFC7579], this definition is further detailed as:

<ConnectivityMatrix> ::= 
      <MatrixID> <ConnType> ((<LinkSet> <LinkSet>) ...)

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.

As an additional note, ConnectivityMatrix belongs to node information, is uniquely identified by advertising node and is a static information. Dynamic information related to the actual state of connections is available through specific extension to link information.

The [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:

 <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>]
   [<ProcessingCapabilities>] [<OutputConstraints>]

The usage of resource block and resource pool is an efficient way to model constrains within a WSON node.

5. Optical Impairment Information Model

The idea behind this document is to put optical impairment parameters into categories and extend the information model already defined for impairment-free WSONs. The three categories are:

All the above three categories will make use of a generic container, the Impairment Vector, to transport optical impairment information.

This information model however will allow however to add additional parameters beyond the one defined by [ITU.G680] in order to support additional computational models. This mechanism could eventually applicable to both linear and non-linear parameters.

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.

5.1. The Optical Impairment Vector

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:

<OIV> ::= ([<LabelSet>] <OPTICAL_PARAM>) ...

The optional LabelSet object enables wavelength dependency property as per Table 1. LabelSet has its definition in [RFC7579].

OPTICAL_PARAM. This object represents an optical parameter. The Impairment vector can contain a set of parameters as identified by [ITU.G697] since those parameters match the terms of the linear impairments computational models provided by [ITU.G680]. This information model does not speculate about the set of parameters (since defined elsewhere, e.g. ITU-T), however it does not preclude extensions by adding new parameters.

5.2. Node Information

5.2.1. Impairment Matrix

Impairment matrix describes a list of the optical parameters that applies to a network element as a whole or ingress/egress port pairs of a network element. Wavelength dependency property of optical parameters is also considered.

ImpairmentMatrix ::=  <MatrixID> <ConnType> 
      ((<LinkSet> <LinkSet> <OIV>) ...)


The model can be represented as a multidimensional matrix shown in the following picture

                      /        /       /       /       /       /|
                     /        /       /       /       /       / |
                    /________/_______/_______/_______/_______/  |
                   /        /       /       /       /       /| /|
                  /        /       /       /       /       / |  |    
                 /________/_______/_______/_______/_______/  | /|
                /        /       /       /       /       /| /|  |
               /        /       /       /       /       / |  | /|   
              /________/_______/_______/_______/_______/  | /|  |
             /        /       /       /       /       /| /|  | /|
            /        /       /       /       /       / |  | /|  |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | /|  | / 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>

The connectivity matrix from [RFC7579] is only a two dimensional matrix, containing only binary information, through the LinkSet pairs. In this model, a third dimension is added by generalizing the binary information through the Optical Impairment Vector associated with each LinkSet pair. Optical parameters in the picture are reported just as an example: proper list and encoding shall be defined by other documents.

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.

5.2.2. Impairment Resource Block Information

This information model reuses the definition of Resource Block Information adding the associated impairment vector.

 ResourceBlockInfo ::= <ResourceBlockSet> [<InputConstraints>]
   [<ProcessingCapabilities>] [<OutputConstraints>] [<OIV>]

The object ResourceBlockInfo is than used as specified within [RFC7446].

5.3. Link Information

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 [RFC7446] as the following:

<DynamicLinkInfo> ::=  <LinkID> <AvailableLabels>
        [<SharedBackupLabels>] [<OIV>]

DynamicLinkInfo is already defined in [RFC7446] while OIV is the Optical Impairment Vector is defined in the previous section.

5.4. Path Information

There are cases where the optical impairments can only be described as a constrains on the overall end to end path. In such case, the optical impairment and/or parameter, cannot be derived (using a simple function) from the set of node / link contributions.

An equivalent case is the option reported by [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.

<PathInfo> ::=  <OIV>

[EDITOR NOTE: section to be completed, especially to evaluate protocol implications. Likely resemble to RSVP ADSPEC].

6. Encoding Considerations

Details about encoding will be defined in a separate document [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, within [ITU.G697] Appending V, ITU already provides a guideline for encoding some optical parameters.

In particular [ITU.G697] indicates that each parameter shall be represented by a 32 bit floating point number.

Values for optical parameters are provided by optical node and it could provide by direct measurement or from some internal computation starting from indirect measurement. In such cases, it could be useful to understand the variance associated with the value of the optical parameter hence, the encoding shall provide the possibility to include a variance as well.

This kind of information will enable IA-RWA process to make some additional considerations on wavelength feasibility. [RFC6566] Section 4.1.3 reports some considerations regarding this degree of confidence during the impairment validation process.

7. Control Plane Architectures

This section briefly describes how the definitions contained in this information model will match the architectural options described by [RFC6566].

The first assumption is that the WSON GMPLS extensions are available and operational. To such extent, the WSON-RWA will provide the following information through its path computation (and RWA process):

7.1. IV-Centralized

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 feasible or not. This requires distribution of impairment information to the entity performing the IV process.

This Information Model doesn't make any hypothesis on distribution method for optical parameters but only defines the essential build blocks. A centralized entity may get knowledge of required information through routing protocols or other mechanism such as BGP-LS.

7.2. IV-Distributed

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.

The signalling phase may provide additional checking as others traffic engineering parameters.

8. Acknowledgements

Authors would like to acknoledge Greg Bernstein and Moustafa Kattan as authors of a previous similar draft whose content partially converged here.

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.

9. IANA Considerations

This document does not contain any IANA requirement.

10. Security Considerations

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.

11. References

11.1. Normative References

[ITU.G650.1] International Telecommunications Union, "Transmission media and optical systems characteristics - Optical fibre cable", ITU-T Recommendation G.650.1, July 2010.
[ITU.G650.2] International Telecommunications Union, "Definitions and test methods for statistical and non-linear related attributes of single-mode fibre and cable", ITU-T Recommendation G.650.2, August 2015.
[ITU.G671] International Telecommunications Union, "Transmission characteristics of optical components and subsystems", ITU-T Recommendation G.671, February 2012.
[ITU.G680] International Telecommunications Union, "Physical transfer functions of optical network elements", ITU-T Recommendation G.680, July 2007.
[ITU.G697] International Telecommunications Union, "Optical monitoring for dense wavelength division multiplexing systems", ITU-T Recommendation G.697, February 2012.
[ITU.GSUP39] International Telecommunications Union, "Optical System Design and Engineering Considerations", ITU-T Recommendation G. Supplement 39, September 2012.
[ITU.GSUP47] International Telecommunications Union, "General aspects of optical fibres and cables", ITU-T Recommendation G. Supplement 47, September 2012.

11.2. Informative References

[I-D.martinelli-ccamp-wson-iv-encode] Martinelli, G., Zhang, X., Galimberti, G., Siracusa, D., Zanardi, A., Pederzolli, F., Lee, Y. and F. Zhang, "Information Encoding for WSON with Impairments Validation", Internet-Draft draft-martinelli-ccamp-wson-iv-encode-07, October 2016.
[LS78] International Telecommunications Union SG15/Q6, "LS/s on CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", LS, October 2013.
[RFC6163] Lee, Y., Bernstein, G. and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011.
[RFC6566] Lee, Y., Bernstein, G., Li, D. and G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments", RFC 6566, DOI 10.17487/RFC6566, March 2012.
[RFC7446] Lee, Y., Bernstein, G., Li, D. and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, February 2015.
[RFC7579] Bernstein, G., Lee, Y., Li, D., Imajuku, W. and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015.

Appendix A. FAQ

A.1. Why the Application Code does not suffice for Optical Impairment Validation?

Application Codes are encoded within GMPLS WSON protocol through the Optical Interface Class as defined in [RFC7446].

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.

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.

A.2. Are DWDM network multivendor?

According to [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.

Authors' Addresses

Giovanni Martinelli (editor) Cisco via Santa Maria Molgora, 48/C Vimercate, MB 20871 Italy Phone: +39 039 2092044 EMail:
Xian Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzen, 518129 P.R. China Phone: +86 755 28972465 EMail:
Gabriele M. Galimberti Cisco Via Santa Maria Molgora, 48/C Vimercate, MB 20871 Italy Phone: +39 039 2091462 EMail:
Andrea Zanardi CREATE-NET via alla Cascata 56/D, Povo Trento, 38123 Italy EMail:
Domenico Siracusa CREATE-NET via alla Cascata 56/D, Povo Trento, 38123 Italy EMail:
Federico Pederzolli CREATE-NET via alla Cascata 56/D, Povo Trento, 38123 Italy EMail:
Young Lee Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075 U.S.A EMail:
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzen, 518129 P.R. China EMail: