[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bernstein-ccamp-wson-impairments) 00 01 02 03 04 05 06 07 08 09 10 RFC 6566

Network Working Group                                            Y. Lee
                                                                 Huawei
                                                           G. Bernstein
                                                      Grotto Networking
                                                                  D. Li
                                                                 Huawei
                                                          G. Martinelli
                                                                  Cisco

Internet Draft
Intended status: Informational                          January 5, 2012
Expires: July 2012



    A Framework for the Control of Wavelength Switched Optical Networks
                          (WSON) with Impairments
                 draft-ietf-ccamp-wson-impairments-10.txt


Abstract

   As an optical signal progresses along its path, it may be altered by
   the various physical processes in the optical fibers and devices it
   encounters. When such alterations result in signal degradation,
   these processes are usually referred to as "impairments". These
   physical characteristics may be important constraints to consider
   when using a GMPLS control plane to support path setup and
   maintenance in wavelength switched optical networks.

   This document provides a framework for applying GMPLS protocols and
   the PCE architecture to support Impairment Aware Routing and
   Wavelength Assignment (IA-RWA) in wavelength switched optical
   networks. Specifically, this document discusses key computing
   constraints, scenarios and architectural processes: Routing,
   Wavelength Assignment, and Impairment Validation. This document does
   not define optical data plane aspects; impairment parameters,
   measurement of, or assessment and qualification of a route, but
   rather it describes the architectural and information components for
   protocol solutions.



Status of this Memo

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




Lee & Bernstein          Expires July 5, 2012                  [Page 1]

Internet-Draft    Framework for Optical Impairments        January 2012


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 5, 2012.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) 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...................................................3
   2. Terminology....................................................4
   3. Applicability..................................................6
   4. Impairment Aware Optical Path Computation......................7
      4.1. Optical Network Requirements and Constraints..............8
         4.1.1. Impairment Aware Computation Scenarios...............8
         4.1.2. Impairment Computation and Information Sharing
         Constraints.................................................9


Lee & Bernstein          Expires July 5, 2012                  [Page 2]

Internet-Draft    Framework for Optical Impairments        January 2012


         4.1.3. Impairment Estimation Process.......................11
      4.2. IA-RWA Computation and Control Plane Architectures.......12
         4.2.1. Combined Routing, WA, and IV........................14
         4.2.2. Separate Routing, WA, or IV.........................14
         4.2.3. Distributed WA and/or IV............................15
      4.3. Mapping Network Requirements to Architectures............16
   5. Protocol Implications.........................................18
      5.1. Information Model for Impairments........................19
      5.2. Routing..................................................20
      5.3. Signaling................................................20
      5.4. PCE......................................................21
         5.4.1. Combined IV & RWA...................................21
         5.4.2. IV-Candidates + RWA.................................21
         5.4.3. Approximate IA-RWA + Separate Detailed IV...........23
   6. Manageability and Operations..................................25
   7. Security Considerations.......................................26
   8. IANA Considerations...........................................27
   9. References....................................................27
      9.1. Normative References.....................................27
      9.2. Informative References...................................27
   10. Acknowledgments..............................................28

1. Introduction

   Wavelength Switched Optical Networks (WSONs) are constructed from
   subsystems that may include Wavelength Division Multiplexed (WDM)
   links, tunable transmitters and receivers, Reconfigurable Optical
   Add/Drop Multiplexers (ROADM), wavelength converters, and electro-
   optical network elements.  A WSON is a wavelength division
   multiplexed (WDM)-based optical network in which switching is
   performed selectively based on the center wavelength of an optical
   signal.

   As an optical signal progresses along its path, it may be altered by
   the various physical processes in the optical fibers and devices it
   encounters. When such alterations result in signal degradation,
   these processes are usually referred to as "impairments". Optical
   impairments accumulate along the path (without 3R regeneration)
   traversed by the signal. They are influenced by the type of fiber
   used, the types and placement of various optical devices, and the
   presence of other optical signals that may share a fiber segment
   along the signal's path. The degradation of the optical signals due
   to impairments can result in unacceptable bit error rates or even a
   complete failure to demodulate and/or detect the received signal.

   In order to provision an optical connection (an optical path)
   through a WSON, a combination of path continuity, resource
   availability, and impairments constraints must be met to determine

Lee & Bernstein          Expires July 5, 2012                  [Page 3]

Internet-Draft    Framework for Optical Impairments        January 2012


   viable and optimal paths through the network. The determination of
   appropriate paths is known as Impairment Aware Routing and
   Wavelength Assignment (IA-RWA).

   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945]
   provides a set of control plane protocols that can be used to
   operate networks ranging from packet switch capable networks,
   through those networks that use time division multiplexing and WDM.
   The Path Computation Element (PCE) architecture [RFC4655] defines
   functional computation components that can be used in cooperation
   with the GMPLS control plane to compute and suggest appropriate
   paths. [RFC4054] provides an overview of optical impairments and
   their routing (path selection) implications for GMPLS. This document
   uses as reference [G.680] and other ITU-T Recommendations for the
   optical data plane aspects.

   This document provides a framework for applying GMPLS protocols and
   the PCE architecture to the control and operation of IA-RWA for
   WSONs.  To aid in this evaluation, this document provides an
   overview of the subsystems and processes that comprise WSONs and
   describes IA-RWA models based on the corresponding ITU-T
   Recommendations, so that the information requirements for use by
   GMPLS and PCE systems can be identified. This work will facilitate
   the development of protocol extensions in support of IA-RWA within
   the GMPLS and PCE protocol families.



2. Terminology

   ADM: Add/Drop Multiplexers - An optical device used in WDM networks
   composed of one or more line side ports and typically many tributary
   ports.

   Black links: Black links refer to tributary interfaces where only
   link characteristics are defined. This approach enables transverse
   compatibility at the single-channel point using a direct wavelength-
   multiplexing configuration.



   CWDM: Coarse Wavelength Division Multiplexing

   DGD: Differential Group Delay

   DWDM: Dense Wavelength Division Multiplexing

   FOADM: Fixed Optical Add/Drop Multiplexer

Lee & Bernstein          Expires July 5, 2012                  [Page 4]

Internet-Draft    Framework for Optical Impairments        January 2012


   GMPLS: Generalized Multi-Protocol Label Switching

   IA-RWA: Impairment Aware Routing and Wavelength Assignment

   Line side: In WDM system line side ports and links typically can
   carry the full multiplex of wavelength signals, as compared to
   tributary (add or drop ports) that typically carry a few (typically
   one) wavelength signals.

   NEs: Network Elements

   OADMs: Optical Add Drop Multiplexers

   OSNR: Optical Signal to Noise Ratio

   OXC: Optical cross connect - An optical switching element in which a
   signal on any input port can reach any output port.

   PCC: Path Computation Client - Any client application requesting a
   path computation to be performed by the Path Computation Element.

   PCE: Path Computation Element -  An entity (component, application,
   or network node) that is capable of computing a network path or
   route based on a network graph and applying computational
   constraints.

   PCEP: PCE Communication Protocol -  The communication protocol
   between a Path Computation Client and Path Computation Element.

   PXC: Photonic Cross Connects

   Q-factor: The Q-factor provides a qualitative description of the
   receiver performance. It is a function of the signal to optical
   noise ratio. The Q-factor suggests the minimum SNR (Signal Noise
   Ratio) required to obtain a specific BER for a given signal.

   ROADM: Reconfigurable Optical Add/Drop Multiplexer -  A wavelength
   selective switching element featuring input and output line side
   ports as well as add/drop tributary ports.

   RWA: Routing and Wavelength Assignment

   Transparent Network: A wavelength switched optical network that does
   not contain regenerators or wavelength converters.

   Translucent Network:  A wavelength switched optical network that is
   predominantly transparent but may also contain limited numbers of
   regenerators and/or wavelength converters.

Lee & Bernstein          Expires July 5, 2012                  [Page 5]

Internet-Draft    Framework for Optical Impairments        January 2012


   Tributary: A link or port on a WDM system that can carry
   significantly less than the full multiplex of wavelength signals
   found on the line side links/ports. Typical tributary ports are the
   add and drop ports on an ADM and these support only a single
   wavelength channel.

   Wavelength Conversion/Converters: The process of converting
   information bearing optical signal centered at a given wavelength to
   one with "equivalent" content centered at a different wavelength.
   Wavelength conversion can be implemented via an optical-electronic-
   optical (OEO) process or via a strictly optical process.

   WDM: Wavelength Division Multiplexing

   Wavelength Switched Optical Networks (WSONs): WDM based optical
   networks in which switching is performed selectively based on the
   center wavelength of an optical signal.

3. Applicability

   There are deployment scenarios for WSON networks where not all
   possible paths will yield suitable signal quality. There are
   multiple reasons; below is a non-exhaustive list of examples:

   o  WSON is evolving using multi-degree optical cross connects in a
      way that network topologies are changing from rings (and
      interconnected rings) to general mesh. Adding network equipment
      such as amplifiers or regenerators, to ensure all paths are
      feasible, leads to an over-provisioned network. Indeed, even with
      over provisioning, the network could still have some infeasible
      paths.

   o  Within a given network, the optical physical interface may change
      over the network life, e.g., the optical interfaces might be
      upgraded to higher bit-rates. Such changes could result in paths
      being unsuitable for the optical signal. Moreover, the optical
      physical interfaces are typically provisioned at various stages
      of the network's life span as needed by traffic demands.

   o  There are cases where a network is upgraded by adding new optical
      cross connects to increase network flexibility. In such cases,
      existing paths will have their feasibility modified while new
      paths will need to have their feasibility assessed.






Lee & Bernstein          Expires July 5, 2012                  [Page 6]

Internet-Draft    Framework for Optical Impairments        January 2012


   o  With the recent bit rate increases from 10G to 40G and 100G over
      a single wavelength, WSON networks will likely be operated with a
      mix of wavelengths at different bit rates. This operational
      scenario will impose impairment constraints due to different
      physical behavior of different bit rates and associated
      modulation formats.

   Not having an impairment aware control plane for such networks will
   require a more complex network design phase that needs to take into
   account the evolving network status in term of equipments and
   traffic at the beginning stage. In addition, network operations such
   as path establishment, will require significant pre-design via non-
   control plane processes resulting in significantly slower network
   provisioning.

   It should be highlighted that the impact of impairments and use in
   determination of path viability is not sufficiently well established
   for general applicability [G.680]; it will depend on network
   implementations. The use of an impairment aware control plane and
   set of information distributed will need to be evaluated on a case
   by case scenario.



4. Impairment Aware Optical Path Computation

   The basic criteria for path selection is whether one can
   successfully transmit the signal from a transmitter to a receiver
   within a prescribed error tolerance, usually specified as a maximum
   permissible bit error ratio (BER). This generally depends on the
   nature of the signal transmitted between the sender and receiver and
   the nature of the communications channel between the sender and
   receiver. The optical path utilized (along with the wavelength)
   determines the communications channel.

   The optical impairments incurred by the signal along the fiber and
   at each optical network element along the path determine whether the
   BER performance or any other measure of signal quality can be met
   for a signal on a particular end-to-end path.

   Impairment-aware path calculation also needs to take into account
   when regeneration is used along the path. [RFC6163] provides
   background on the concept of optical translucent networks which
   contains transparent elements and electro-optical elements such as
   OEO regenerations. In such networks, a generic light path can go
   through a number of regeneration points.

   Regeneration points could happen for two reasons:

Lee & Bernstein          Expires July 5, 2012                  [Page 7]

Internet-Draft    Framework for Optical Impairments        January 2012


  (i)  Due to wavelength conversion to assist RWA to avoid wavelength
     blocking. This is the impairment free case covered by [RFC6163].

  (ii)  The optical signal without regeneration would be too degraded
     to meet end to end BER requirements. This is the case when RWA
     takes into consideration impairment estimation covered by this
     document.

   In the latter case, an optical path can be seen as a set of
   transparent segments. The optical impairments calculation needs to
   be reset at each regeneration point so each transparent segment will
   have its own impairment evaluation.

   +---+    +----+   +----+     +-----+     +----+    +---+
   | I |----| N1 |---| N2 |-----| REG |-----| N3 |----| E |
   +---+    +----+   +----+     +-----+     +----+    +---+

   |<----------------------------->|<-------------------->|
           Segment 1                      Segment 2

          Figure 1 Optical path as a set of transparent segments

   For example, Figure 1 represents an optical path from node I to node
   E with a regeneration point REG in between. It is feasible from an
   impairment validation perspective if both segments (I, N1, N2, REG)
   and (REG, N3, E) are feasible.

4.1. Optical Network Requirements and Constraints

   This section examines the various optical network requirements and
   constraints under which an impairment aware optical control plane
   may have to operate under. These requirements and constraints
   motivate the IA-RWA architectural alternatives to be presented in
   the following section. Different optical networks contexts can be
   broken into two main criteria: (a) the accuracy required in the
   estimation of impairment effects, and (b) the constraints on the
   impairment estimation computation and/or sharing of impairment
   information.

4.1.1. Impairment Aware Computation Scenarios

   A. No concern for impairments or Wavelength Continuity Constraints

   This situation is covered by existing GMPLS with local wavelength
   (label) assignment.

   B. No concern for impairments but Wavelength Continuity Constraints


Lee & Bernstein          Expires July 5, 2012                  [Page 8]

Internet-Draft    Framework for Optical Impairments        January 2012


   This situation is applicable to networks designed such that every
   possible path is valid for the signal types permitted on the
   network. In this case, impairments are only taken into account
   during network design and after that, for example during optical
   path computation, they can be ignored. This is the case discussed in
   [RFC6163] where impairments may be ignored by the control plane and
   only optical parameters related to signal compatibility are
   considered.

   C. Approximated Impairment Estimation

   This situation is applicable to networks in which impairment effects
   need to be considered but there is sufficient margin such that they
   can be estimated via approximation techniques such as link budgets
   and dispersion [G.680],[G.sup39]. The viability of optical paths for
   a particular class of signals can be estimated using well defined
   approximation techniques [G.680], [G.sup39]. This is the generally
   known as linear case where only linear effects are taken into
   account. Note that adding or removing an optical signal on the path
   should not render any of the existing signals in the network as non-
   viable.  For example, one form of non-viability is the occurrence of
   transients in existing links of sufficient magnitude to impact the
   BER of existing signals.

   Much work at ITU-T has gone into developing impairment models at
   this and more detailed levels. Impairment characterization of
   network elements may be used to calculate which paths are conformant
   with a specified BER for a particular signal type. In such a case,
   the impairment aware (IA) path computation can be combined with the
   RWA process to permit more optimal IA-RWA computations. Note that
   the IA path computation may also take place in a separate entity,
   i.e., a PCE.

   D. Accurate Impairment Computation

   This situation is applicable to networks in which impairment effects
   must be more accurately computed. For these networks, a full
   computation and evaluation of the impact to any existing paths needs
   to be performed prior to the addition of a new path. Currently no
   impairment models are available from ITU-T and this scenario is
   outside the scope of this document.



4.1.2. Impairment Computation and Information Sharing Constraints

   In GMPLS, information used for path computation is standardized for
   distribution amongst the elements participating in the control plane

Lee & Bernstein          Expires July 5, 2012                  [Page 9]

Internet-Draft    Framework for Optical Impairments        January 2012


   and any appropriately equipped PCE can perform path computation. For
   optical systems this may not be possible. This is typically due to
   only portions of an optical system being subject to standardization.
   In ITU-T recommendations [G.698.1] and [G.698.2] which specify
   single channel interfaces to multi-channel DWDM systems, only the
   single channel interfaces (transmit and receive) are specified while
   the multi-channel links are not standardized. These DWDM links are
   referred to as "black links" since their details are not generally
   available. However, note that the overall impact of a black link at
   the single channel interface points is limited by [G.698.1] and
   [G.698.2].

   Typically a vendor might use proprietary impairment models for DWDM
   spans in order to estimate the validity of optical paths. For
   example, models of optical nonlinearities are not currently
   standardized. Vendors may also choose not to publish impairment
   details for links or a set of network elements in order not to
   divulge their optical system designs.

   In general, the impairment estimation/validation of an optical path
   for optical networks with "black links" in the path could not be
   performed by a general purpose impairment aware (IA) computation
   entity since it would not have access to or understand the "black
   link" impairment parameters. However, impairment estimation (optical
   path validation) could be performed by a vendor specific impairment
   aware computation entity. Such a vendor specific IA computation
   could utilize standardized impairment information imported from
   other network elements in these proprietary computations.

   In the following, the term "black links" will be used to describe
   these computation and information sharing constraints in optical
   networks. From the control plane perspective the following options
   are considered:

   1. The authority in control of the "black links" can furnish a list
      of all viable paths between all viable node pairs to a
      computational entity. This information would be particularly
      useful as an input to RWA optimization to be performed by another
      computation entity. The difficulty here is that such a list of
      paths along with any wavelength constraints could get
      unmanageably large as the size of the network increases.








Lee & Bernstein          Expires July 5, 2012                 [Page 10]

Internet-Draft    Framework for Optical Impairments        January 2012


   2. The authority in control of the "black links" could provide a
      PCE-like entity a list of viable paths/wavelengths between two
      requested nodes. This is useful as an input to RWA optimizations
      and can reduce the scaling issue previously mentioned. Such a
      PCE-like entity would not need to perform a full RWA computation,
      i.e., it would not need to take into account current wavelength
      availability on links. Such an approach may require PCEP
      extensions for both the request and response information.

   3. The authority in control of the "black links" provides a PCE that
      performs full IA-RWA services. The difficulty is this requires
      the one authority to also become the sole source of all RWA
      optimization algorithms.

   In all the above cases it would be the responsibility of the
   authority in control of the "black links" to import the shared
   impairment information from the other NEs via the control plane or
   other means as necessary.

4.1.3. Impairment Estimation Process

   The Impairment Estimation Process can be modeled through the
   following functional blocks. These blocks are independent of any
   Control Plane architecture, that is, they can be implemented by the
   same or by different control plane functions as detailed in
   following sections.

                                              +-----------------+
       +------------+        +-----------+    |  +------------+ |
       |            |        |           |    |  |            | |
       | Optical    |        | Optical   |    |  | Optical    | |
       | Interface  |------->| Impairment|--->|  | Channel    | |
       | (Transmit/ |        | Path      |    |  | Estimation | |
       |  Receive)  |        |           |    |  |            | |
       +------------+        +-----------+    |  +------------+ |
                                              |        ||       |
                                              |        ||       |
                                              |    Estimation   |
                                              |        ||       |
                                              |        \/       |
                                              |  +------------+ |
                                              |  |  BER /     | |
                                              |  |  Q Factor  | |
                                              |  +------------+ |
                                              +-----------------+




Lee & Bernstein          Expires July 5, 2012                 [Page 11]

Internet-Draft    Framework for Optical Impairments        January 2012


   Starting from functional block on the left, the Optical Interface
   represents where the optical signal is transmitted or received and
   defines the properties at the path end points. Even the impairment-
   free case, like scenario B in section 4.1.1, needs to consider a
   minimum set of interface characteristics. In such case, only a few
   parameters used to assess the signal compatibility will be taken
   into account (see [RFC6163]). For the impairment-aware case, these
   parameters may be sufficient or not depending on the accepted level
   of approximation (scenarios C and D). This functional block
   highlights the need to consider a set of interface parameters during
   the Impairment Validation Process.

   The block "Optical Impairment Path" represents the types of
   impairments affecting a wavelength as it traverses the networks
   through links and nodes. In the case of a network where there are no
   impairments (Scenario A), this block will not be present. Otherwise,
   this function must be implemented in some way via the control plane.
   Architectural alternatives to accomplish this are provided in
   section 4.2. This block implementation (e.g., through routing,
   signaling, or PCE) may influence the way the control plane
   distributes impairment information within the network.

   The last block implements the decision function for path
   feasibility. Depending on the IA level of approximation, this
   function can be more or less complex. For example in case of no IA
   only the signal class compatibility will be verified. In addition to
   feasible/not-feasible result, it may be worthwhile for decision
   functions to consider the case in which paths can be likely-to-be-
   feasible within some degree of confidence. The optical impairments
   are usually not fixed values as they may vary within ranges of
   values according to the approach taken in the physical modeling
   (worst-case, statistical, or based on typical values). For example,
   the utilization of the worst-case value for each parameter within
   impairment validation process may lead to marking some paths as not-
   feasible while they are very likely to be, in reality, feasible.

4.2. IA-RWA Computation and Control Plane Architectures

   From a control plane point of view, optical impairments are
   additional constraints to the impairment-free RWA process described
   in [RFC6163]. In impairment aware routing and wavelength assignment
   (IA-RWA), there are conceptually three general classes of processes
   to be considered: Routing (R), Wavelength Assignment (WA), and
   Impairment Validation (IV), i.e., estimation.

   Impairment validation may come in many forms, and may be invoked at
   different levels of detail in the IA-RWA process. All the variations
   of impairment validation discussed in this section is based on

Lee & Bernstein          Expires July 5, 2012                 [Page 12]

Internet-Draft    Framework for Optical Impairments        January 2012


   Scenario C (Approximated Impairment Estimation) as discussed in
   Section 4.1.1. From a process point of view, the following three
   forms of impairment validation will be considered:

   o  IV-Candidates

   In this case, an Impairment Validation (IV) process furnishes a set
   of paths between two nodes along with any wavelength restrictions
   such that the paths are valid with respect to optical impairments.
   These paths and wavelengths may not be actually available in the
   network due to its current usage state. This set of paths could be
   returned in response to a request for a set of at most K valid paths
   between two specified nodes. Note that such a process never directly
   discloses optical impairment information. Note that that this case
   includes any paths between source and destination that may have been
   "pre-validated".

   In this case, the control plane simply makes use of candidate paths
   but does not know any optical impairment information. Another option
   is when the path validity is assessed within the control plane. The
   following cases highlight this situation.



   o  IV-Approximate Verification

   Here approximation methods are used to estimate the impairments
   experienced by a signal. Impairments are typically approximated by
   linear and/or statistical characteristics of individual or combined
   components and fibers along the signal path.

   o  IV-Detailed Verification

   In this case, an IV process is given a particular path and
   wavelength through an optical network and is asked to verify whether
   the overall quality objectives for the signal over this path can be
   met. Note that such a process never directly discloses optical
   impairment information.

   The next two cases refer to the way an impairment validation
   computation can be performed.

   o  IV-Centralized

   In this case, impairments to a path are computed at a single entity.
   The information concerning impairments, however, may still be
   gathered from network elements. Depending how information is


Lee & Bernstein          Expires July 5, 2012                 [Page 13]

Internet-Draft    Framework for Optical Impairments        January 2012


   gathered, this may put additional requirements on routing protocols.
   This will be detailed in later sections.

   o  IV-Distributed

   In the distributed IV process, approximate degradation measures such
   as OSNR, dispersion, DGD, etc., may be accumulated along the path
   via signaling. Each node on the path may already perform some part
   of the impairment computation (i.e. distributed). When the
   accumulated measures reach the destination node, a decision on the
   impairment validity of the path can be made. Note that such a
   process would entail revealing an individual network element's
   impairment information but it does not generally require
   distributing optical parameters to the entire network.

   The Control Plane must not preclude the possibility to concurrently
   perform one or all the above cases in the same network. For example,
   there could be cases where a certain number of paths are already
   pre-validated (IV-Candidates) so the control plane may setup one of
   those paths without requesting any impairment validation procedure.
   On the same network, however, the control plane may compute a path
   outside the set of IV-Candidates for which an impairment evaluation
   can be necessary.

   The following subsections present three major classes of IA-RWA path
   computation architectures and reviews some of their respective
   advantages and disadvantages.

4.2.1. Combined Routing, WA, and IV

   From the point of view of optimality, reasonably good IA-RWA
   solutions can be achieved if the path computation entity (PCE) can
   conceptually/algorithmically combine the processes of routing,
   wavelength assignment and impairment validation.

   Such a combination can take place if the PCE is given: (a) the
   impairment-free WSON network information as discussed in [RFC6163]
   and (b) impairment information to validate potential paths.

4.2.2. Separate Routing, WA, or IV

   Separating the processes of routing, WA, and/or IV can reduce the
   need for sharing of different types of information used in path
   computation. This was discussed for routing separate from WA in
   [RFC6163]. In addition, as was discussed, some impairment
   information may not be shared and this may lead to the need to
   separate IV from RWA.  In addition, if IV needs to be done at a high


Lee & Bernstein          Expires July 5, 2012                 [Page 14]

Internet-Draft    Framework for Optical Impairments        January 2012


   level of precision, it may be advantageous to offload this
   computation to a specialized server.

   The following conceptual architectures belong in this general
   category:

   o  R+WA+IV -- separate routing, wavelength assignment, and
      impairment validation.

   o  R + (WA & IV) -- routing separate from a combined wavelength
      assignment and impairment validation process. Note that
      impairment validation is typically wavelength dependent. Hence
      combining WA with IV can lead to efficiencies.

   o  (RWA)+IV - combined routing and wavelength assignment with a
      separate impairment validation process.

   Note that the IV process may come before or after the RWA processes.
   If RWA comes first, then IV is just rendering a yes/no decision on
   the selected path and wavelength. If IV comes first it would need to
   furnish a list of possible (valid with respect to impairments)
   routes and wavelengths to the RWA processes.

4.2.3. Distributed WA and/or IV

   In the non-impairment RWA situation [RFC6163], it was shown that a
   distributed wavelength assignment (WA) process carried out via
   signaling can eliminate the need to distribute wavelength
   availability information via an interior gateway protocol (IGP). A
   similar approach can allow for the distributed computation of
   impairment effects and avoid the need to distribute impairment
   characteristics of network elements and links by routing protocols
   or by other means. So the following conceptual options belong to
   this category:

   o  RWA + D(IV) - Combined routing and wavelength assignment and
      distributed impairment validation.

   o  R + D(WA & IV) -- routing separate from a distributed wavelength
      assignment and impairment validation process.

   Distributed impairment validation for a prescribed network path
   requires that the effects of impairments be calculated by
   approximate models with cumulative quality measures such as those
   given in [G.680]. The protocol encoding of the impairment related
   information from [G.680] would need to be agreed upon.



Lee & Bernstein          Expires July 5, 2012                 [Page 15]

Internet-Draft    Framework for Optical Impairments        January 2012


   If distributed WA is being done at the same time as distributed IV
   then it is necessary to accumulate impairment related information
   for all wavelengths that could be used. The amount of information is
   reduced somewhat as potential wavelengths are discovered to be in
   use, but could be a significant burden for lightly loaded high
   channel count networks.

4.3. Mapping Network Requirements to Architectures

   Figure 2 shows process flows for the three main architectural
   alternatives to IA-RWA when approximate impairment validation is
   sufficient. Figure 3 shows process flows for the two main
   architectural alternatives when detailed impairment verification is
   required.


                  +-----------------------------------+
                  |   +--+     +-------+     +--+     |
                  |   |IV|     |Routing|     |WA|     |
                  |   +--+     +-------+     +--+     |
                  |                                   |
                  |        Combined Processes         |
                  +-----------------------------------+
                                  (a)

           +--------------+      +----------------------+
           | +----------+ |      | +-------+    +--+    |
           | |    IV    | |      | |Routing|    |WA|    |
           | |candidates| |----->| +-------+    +--+    |
           | +----------+ |      |  Combined Processes  |
           +--------------+      +----------------------+
                                  (b)

            +-----------+        +----------------------+
            | +-------+ |        |    +--+    +--+      |
            | |Routing| |------->|    |WA|    |IV|      |
            | +-------+ |        |    +--+    +--+      |
            +-----------+        | Distributed Processes|
                                 +----------------------+
                                  (c)
     Figure 2 Process flows for the three main approximate impairment
                        architectural alternatives.

   The advantages, requirements, and suitability of these options are
   as follows:

   o  Combined IV & RWA process


Lee & Bernstein          Expires July 5, 2012                 [Page 16]

Internet-Draft    Framework for Optical Impairments        January 2012


   This alternative combines RWA and IV within a single computation
   entity enabling highest potential optimality and efficiency in IA-
   RWA. This alternative requires that the computational entity knows
   impairment information as well as non-impairment RWA information.
   This alternative can be used with "black links", but would then need
   to be provided by the authority controlling the "black links".

   o  IV-Candidates + RWA process

   This alternative allows separation of impairment information into
   two computational entities while still maintaining a high degree of
   potential optimality and efficiency in IA-RWA. The candidates IV
   process needs to know impairment information from all optical
   network elements, while the RWA process needs to know non-impairment
   RWA information from the network elements. This alternative can be
   used with "black links", but the authority in control of the "black
   links" would need to provide the functionality of the IV-candidates
   process. Note that this is still very useful since the algorithmic
   areas of IV and RWA are very different and conducive to
   specialization.

   o  Routing + Distributed WA and IV

   In this alternative, a signaling protocol may be extended and
   leveraged in the wavelength assignment and impairment validation
   processes. Although this doesn't enable as high a potential degree
   of optimality as (a) or (b), it does not require distribution of
   either link wavelength usage or link/node impairment information.
   Note that this is most likely not suitable for "black links".




















Lee & Bernstein          Expires July 5, 2012                 [Page 17]

Internet-Draft    Framework for Optical Impairments        January 2012


          +-----------------------------------+     +------------+
          | +-----------+  +-------+    +--+  |     | +--------+ |
          | |    IV     |  |Routing|    |WA|  |     | |  IV    | |
          | |approximate|  +-------+    +--+  |---->| |Detailed| |
          | +-----------+                     |     | +--------+ |
          |        Combined Processes         |     |            |
          +-----------------------------------+     +------------+
                                   (a)

    +--------------+      +----------------------+     +------------+
    | +----------+ |      | +-------+    +--+    |     | +--------+ |
    | |    IV    | |      | |Routing|    |WA|    |---->| |  IV    | |
    | |candidates| |----->| +-------+    +--+    |     | |Detailed| |
    | +----------+ |      |  Combined Processes  |     | +--------+ |
    +--------------+      +----------------------+     |            |
                                   (b)                 +------------+
        Figure 3 Process flows for the two main detailed impairment
                     validation architectural options.

   The advantages, requirements, and suitability of these detailed
   validation options are as follows:

   o  Combined Approximate IV & RWA + Detailed-IV

   This alternative combines RWA and approximate IV within a single
   computation entity enabling the highest potential optimality and
   efficiency in IA-RWA while keeping a separate entity performing
   detailed impairment validation. In the case of "black links" the
   authority controlling the "black links" would need to provide all
   functionality.

   o  Candidates-IV + RWA + Detailed-IV

   This alternative allows separation of approximate impairment
   information into a computational entity while still maintaining a
   high degree of potential optimality and efficiency in IA-RWA; then a
   separate computation entity performs detailed impairment validation.
   Note that detailed impairment estimation is not standardized.

5. Protocol Implications

   The previous IA-RWA architectural alternatives and process flows
   make differing demands on a GMPLS/PCE based control plane. This
   section discusses the use of (a) an impairment information model,
   (b) PCE as computational entity assuming the various process roles
   and consequences for PCEP, (c) possible extensions to signaling, and
   (d) possible extensions to routing. This document is providing this
   evaluation to aid protocol solutions work. The protocol

Lee & Bernstein          Expires July 5, 2012                 [Page 18]

Internet-Draft    Framework for Optical Impairments        January 2012


   specifications may deviate from this assessment. The assessment of
   the impacts to the control plane for IA-RWA is summarized in Figure
   4.



        +-------------------+----+----+----------+--------+
        | IA-RWA Option     |PCE |Sig |Info Model| Routing|
        +-------------------+----+----+----------+--------+
        |          Combined |Yes | No |  Yes     |  Yes   |
        |          IV & RWA |    |    |          |        |
        +-------------------+----+----+----------+--------+-
        |     IV-Candidates |Yes | No |  Yes     |  Yes   |
        |         + RWA     |    |    |          |        |
        +-------------------+----+----+----------+--------+
        |    Routing +      |No  | Yes|  Yes     |  No    |
        |Distributed IV, RWA|    |    |          |        |
        +-------------------+----+----+----------+--------+

     Figure 4 IA-RWA architectural options and control plane impacts.



5.1. Information Model for Impairments

   As previously discussed, most IA-RWA scenarios rely, to a greater or
   lesser extent, on a common impairment information model. A number of
   ITU-T recommendations cover detailed, as well as, approximate
   impairment characteristics of fibers, and a variety of devices, and
   subsystems. An impairment model which can be used as a guideline for
   optical network elements and assessment of path viability is given
   in [G.680].

   It should be noted that the current version of [G.680] is limited to
   networks composed of a single WDM line system vendor combined with
   OADMs and/or PXCs from potentially multiple other vendors. This is
   known as situation 1 and is shown in Figure 1-1 of [G.680]. It is
   planned in the future that [G.680] will include networks
   incorporating line systems from multiple vendors, as well as, OADMs
   and/or PXCs from potentially multiple other vendors. This is known
   as situation 2 and is shown in Figure 1-2 of [G.680].

   For the case of distributed impairment validation (distributed IV),
   this would require more than an impairment information model. It
   would need a common impairment "computation" model. In the
   distributed IV case, one needs to standardize the accumulated
   impairment measures that will be conveyed and updated at each node.
   Section 9 of [G.680] provides guidance in this area with specific

Lee & Bernstein          Expires July 5, 2012                 [Page 19]

Internet-Draft    Framework for Optical Impairments        January 2012


   formulas given for OSNR, residual dispersion, polarization mode
   dispersion/polarization dependent loss, and effects of channel
   uniformity. However, specifics of what intermediate results are kept
   and in what form would need to be standardized for interoperability.
   As noted in [G.680], this information may possibly not be
   sufficient, and in such case the applicability would be network
   dependent.



5.2. Routing

   Different approaches to path/wavelength impairment validation give
   rise to different demands placed on GMPLS routing protocols. In the
   case where approximate impairment information is used to validate
   paths, GMPLS routing may be used to distribute the impairment
   characteristics of the network elements and links based on the
   impairment information model previously discussed.

   Depending on the computational alternative, the routing protocol may
   need to advertise information necessary to the impairment validation
   process. This can potentially cause scalability issues due to the
   high volume of data that need to be advertised. Such issue can be
   addressed separating data that need to be advertised rarely from
   data that need to be advertised more frequently or adopting other
   form of awareness solutions described in previous sections (e.g.,
   centralized and/or external IV entity).

   In term of approximated scenario (see Section 4.1.1.), the model
   defined by [G.680] will apply and the routing protocol will need to
   gather information required for such computation.

   In the case of distributed-IV, no new demands would be placed on the
   routing protocol.

5.3. Signaling

   The largest impacts on signaling occur in the cases where
   distributed impairment validation is performed. In this case, it is
   necessary to accumulate impairment information as previously
   discussed. In addition, since the characteristics of the signal
   itself, such as modulation type, can play a major role in the
   tolerance of impairments, this type of information will need to be
   implicitly or explicitly signaled so that an impairment validation
   decision can be made at the destination node.

   It remains for further study if it may be beneficial to include
   additional information to a connection request such as desired

Lee & Bernstein          Expires July 5, 2012                 [Page 20]

Internet-Draft    Framework for Optical Impairments        January 2012


   egress signal quality (defined in some appropriate sense) in non-
   distributed IV scenarios.

5.4. PCE

   In section 4.3. a number of computation architectural alternatives
   were given that could be used to meet the various requirements and
   constraints of section 4.1.  Here the focus is how these
   alternatives could be implemented via either a single PCE or a set
   of two or more cooperating PCEs, and the impacts on the PCEP. This
   document provides this evaluation to aid solutions work. The
   protocol specifications may deviate from this assessment.



5.4.1. Combined IV & RWA

   In this situation, shown in Figure 2(a), a single PCE performs all
   the computations needed for IA-RWA.

   o  TE Database Requirements: WSON Topology and switching
      capabilities, WSON WDM link wavelength utilization, and WSON
      impairment information

   o  PCC to PCE Request Information: Signal characteristics/type,
      required quality, source node, destination node

   o  PCE to PCC Reply Information: If the computations completed
      successfully then the PCE returns the path and its assigned
      wavelength. If the computations could not complete successfully,
      it would be potentially useful to know the reason why. At a
      minimum, it is of interest to know if this was due to lack of
      wavelength availability, impairment considerations, or both. The
      information to be conveyed is for further study.

5.4.2. IV-Candidates + RWA

   In this situation, as shown in Figure 2(b), two separate processes
   are involved in the IA-RWA computation. This requires two
   cooperating path computation entities: one for the Candidates-IV
   process and another for the RWA process. In addition, the overall
   process needs to be coordinated. This could be done with yet another
   PCE or this functionality could be added to one of previously
   defined entities. This later option requires the RWA entity to also
   act as the overall process coordinator. The roles, responsibilities,
   and information requirements for these two entities when
   instantiated as PCEs are given below.


Lee & Bernstein          Expires July 5, 2012                 [Page 21]

Internet-Draft    Framework for Optical Impairments        January 2012


   RWA and Coordinator PCE (RWA-Coord-PCE):

   Responsible for interacting with PCC and for utilizing Candidates-
   PCE as needed during RWA computations. In particular, it needs to
   know to use the Candidates-PCE to obtain potential set of routes and
   wavelengths.

   o  TE Database Requirements: WSON Topology and switching
      capabilities and WSON WDM link wavelength utilization (no
      impairment information).

   o  PCC to RWA-PCE request: same as in the combined case.

   o  RWA-PCE to PCC reply: same as in the combined case.

   o  RWA-PCE to IV-Candidates-PCE request: The RWA-PCE asks for a set
      of at most K routes along with acceptable wavelengths between
      nodes specified in the original PCC request.

   o  IV-Candidates-PCE reply to RWA-PCE: The Candidates-PCE returns a
      set of at most K routes along with acceptable wavelengths between
      nodes specified in the RWA-PCE request.

  IV-Candidates-PCE:

   The IV-Candidates PCE is responsible for impairment aware path
   computation. It need not take into account current link wavelength
   utilization, but this is not prohibited. The Candidates-PCE is only
   required to interact with the RWA-PCE as indicated above and not the
   initiating PCC. Note: RWA-Coord PCE is also a PCC with respect to
   the IV-Candidate.

   o  TE Database Requirements: WSON Topology and switching
      capabilities and WSON impairment information (no information link
      wavelength utilization required).

   Figure 5 shows a sequence diagram for the possible interactions
   between the PCC, RWA-Coord PCE, and IV-Candidates PCE.











Lee & Bernstein          Expires July 5, 2012                 [Page 22]

Internet-Draft    Framework for Optical Impairments        January 2012



    +---+                +-------------+          +-----------------+
    |PCC|                |RWA-Coord PCE|          |IV-Candidates PCE|
    +-+-+                +------+------+          +---------+-------+
       ...___     (a)            |                           |
       |     ````---...____      |                           |
       |                   ```-->|                           |
       |                         |                           |
       |                         |--..___    (b)             |
       |                         |       ```---...___        |
       |                         |                   ```---->|
       |                         |                           |
       |                         |                           |
       |                         |           (c)       ___...|
       |                         |       ___....---''''      |
       |                         |<--''''                    |
       |                         |                           |
       |                         |                           |
       |          (d)      ___...|                           |
       |      ___....---'''      |                           |
       |<--'''                   |                           |
       |                         |                           |
       |                         |                           |

     Figure 5 Sequence diagram for the interactions between PCC, RWA-
               Coordinating-PCE, and the IV-Candidates-PCE.

   In step (a), the PCC requests a path meeting specified quality
   constraints between two nodes (A and Z) for a given signal
   represented either by a specific type or a general class with
   associated parameters. In step (b), the RWA-Coordinating-PCE
   requests up to K candidate paths between nodes A and Z and
   associated acceptable wavelengths. The term "K candidate paths" is
   associated with K-shortest path algorithm. It refers to an algorithm
   that finds multiple K short paths connecting the source and the
   destination in a graph allowing repeated vertices and edges in the
   paths. See details in [Eppstein].

   In step (c), The IV-Candidates PCE returns this list to the RWA-
   Coordinating PCE which then uses this set of paths and wavelengths
   as input (e.g., a constraint) to its RWA computation. In step (d)
   the RWA-Coordinating PCE returns the overall IA-RWA computation
   results to the PCC.

5.4.3. Approximate IA-RWA + Separate Detailed IV

   Previously, Figure 3 showed two cases where a separate detailed
   impairment validation process could be utilized. It is possible to

Lee & Bernstein          Expires July 5, 2012                 [Page 23]

Internet-Draft    Framework for Optical Impairments        January 2012


   place the detailed validation process into a separate PCE. Assuming
   that a different PCE assumes a coordinating role and interacts with
   the PCC, it is possible to keep the interactions with this separate
   IV-Detailed-PCE very simple. Please note that there is some
   inefficiency by separating the IV-Candidates-PCE from the IV-
   Detailed-PCE from a message flow perspective in order to achieve a
   high degree of potential optimality.

   IV-Detailed-PCE:

   o  TE Database Requirements: The IV-Detailed-PCE will need optical
      impairment information, WSON topology, and possibly WDM link
      wavelength usage information. This document puts no restrictions
      on the type of information that may be used in these
      computations.

   o  Coordinating-PCE to IV-Detailed-PCE request: The coordinating-PCE
      will furnish signal characteristics, quality requirements, path,
      and wavelength to the IV-Detailed-PCE.

   o  IV-Detailed-PCE to Coordinating-PCE reply: The reply is
      essentially a yes/no decision as to whether the requirements
      could actually be met. In the case where the impairment
      validation fails, it would be helpful to convey information
      related to cause or quantify the failure, e.g., so that a
      judgment can be made whether to try a different signal or adjust
      signal parameters.

   Figure 6 shows a sequence diagram for the interactions corresponding
   to the process shown in Figure 3(b). This involves interactions
   between the PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE,
   and the IV-Detailed-PCE.

   In step (a), the PCC requests a path meeting specified quality
   constraints between two nodes (A and Z) for a given signal
   represented either by a specific type or a general class with
   associated parameters. In step (b), the RWA-Coordinating-PCE
   requests up to K candidate paths between nodes A and Z and
   associated acceptable wavelengths. In step (c), The IV-Candidates-
   PCE returns this list to the RWA-Coordinating PCE which then uses
   this set of paths and wavelengths as input (e.g., a constraint) to
   its RWA computation. In step (d), the RWA-Coordinating-PCE request a
   detailed verification of the path and wavelength that it has
   computed. In step (e), the IV-Detailed-PCE returns the results of
   the validation to the RWA-Coordinating-PCE. Finally in step (f), the
   IA-RWA-Coordinating PCE returns the final results (either a path and
   wavelength or cause for the failure to compute a path and
   wavelength) to the PCC.

Lee & Bernstein          Expires July 5, 2012                 [Page 24]

Internet-Draft    Framework for Optical Impairments        January 2012


                +----------+      +--------------+      +------------+
    +---+       |RWA-Coord |      |IV-Candidates |      |IV-Detailed |
    |PCC|       |   PCE    |      |     PCE      |      |    PCE     |
    +-+-+       +----+-----+      +------+-------+      +-----+------+
      |.._   (a)     |                   |                    |
      |   ``--.__    |                   |                    |
      |          `-->|                   |                    |
      |              |        (b)        |                    |
      |              |--....____         |                    |
      |              |          ````---.>|                    |
      |              |                   |                    |
      |              |         (c)  __..-|                    |
      |              |     __..---''     |                    |
      |              |<--''              |                    |
      |              |                                        |
      |              |...._____          (d)                  |
      |              |         `````-----....._____           |
      |              |                             `````----->|
      |              |                                        |
      |              |                 (e)          _____.....+
      |              |          _____.....-----'''''          |
      |              |<----'''''                              |
      |     (f)   __.|                                        |
      |    __.--''   |
      |<-''          |
      |              |


   Figure 6 Sequence diagram for the interactions between PCC, RWA-
   Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE.

6. Manageability and Operations

   The issues concerning manageability and operations are beyond the
   scope of this document. The details of manageability and operational
   issues will have to be deferred to future protocol implementation.

   On a high-level, the GMPLS-routing based architecture discussed in
   Section 5.2. may have to deal with how to resolve potential scaling
   issues associated with disseminating a large amount of impairment
   characteristics of the network elements and links.

   From a scaling point of view, the GMPLS-signaling based architecture
   discussed in Section 5.3. would be more scalable than other
   alternatives as this architecture would avoid the dissemination of a
   large amount of data to the networks. This benefit may come,
   however, at the expense of potentially inefficient use of network
   resources.

Lee & Bernstein          Expires July 5, 2012                 [Page 25]

Internet-Draft    Framework for Optical Impairments        January 2012


   The PCE-based architectures discussed in Section 5.4. would have to
   consider operational complexity when implementing options that
   require the use of multiple PCE servers. The most serious case is
   the option discussed in Section 5.4.3., namely, "Approximate IA-RWA
   + Separate Detailed IV".  The combined IV & RWA option (which was
   discussed on Section 5.4.1.), on the other hand, is simpler than
   other alternatives to operate as one PCE server handles all
   functionality; however, this option may suffer from a heavy
   computation and processing burden compared to other alternatives.

   Interoperability may be a hurdle to overcome when trying to agree on
   some impairment parameters especially those which are associated
   with the black links. This work has been in progress in ITU-T and
   needs some more time to mature.

7. Security Considerations

   This document discusses a number of control plane architectures that
   incorporate knowledge of impairments in optical networks. If such
   architecture 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 similar to other network
   information used within intra-domain protocols.


   This document does not require changes to the security models within
   GMPLS and associated protocols.  That is, the OSPF-TE, RSVP-TE, and
   PCEP security models could be operated unchanged. However,
   satisfying the requirements for impairment information dissemination
   using the existing protocols may significantly affect the loading of
   those protocols.

   This may make the operation of the network more vulnerable to active
   attacks such as injections, impersonation, and MITMs. Therefore,
   additional care may be required to ensure that the protocols are
   secure in the impairment-aware WSON environment.

   Furthermore, the additional information distributed in order to
   address impairment information represents a disclosure of network
   capabilities that an operator may wish to keep private.
   Consideration should be given to securing this information.  For a
   general discussion on MPLS- and GMPLS-related security issues, see
   the MPLS/GMPLS security framework [RFC5920] and, in particular, text
   detailing security issues when Control Plane is physically separated
   from Data Plane.



Lee & Bernstein          Expires July 5, 2012                 [Page 26]

Internet-Draft    Framework for Optical Impairments        January 2012


8. IANA Considerations

   This draft does not currently require any consideration from IANA.

9. References

9.1. Normative References

   [G.680]  ITU-T Recommendation G.680, Physical transfer functions of
             optical network elements, July 2007.

   [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
             Computation Element (PCE)-Based Architecture", RFC 4655,
             August 2006.

9.2. Informative References

   [G.Sup39] ITU-T Series G Supplement 39, Optical system design and
             engineering considerations, February 2006.

   [G.698.1] ITU-T Recommendation G.698.1, Multichannel DWDM
             applications with Single-Channel optical interface,
             December 2006.

   [G.698.2] ITU-T Recommendation G.698.2, Amplified multichannel DWDM
             applications with Single-Channel optical interface, July
             2007.

   [RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and Other
             Constraints on Optical Layer Routing", RFC 4054, May 2005.

   [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010.

   [RFC6163] Lee, Y., Ed., G. Bernstein, Ed., and W. Imajuku,
             "Framework for GMPLS and PCE Control of Wavelength
             Switched Optical Networks", RFC 6163, April 2011.

   [Eppstein] Eppstein, D., "Finding the k shortest paths", 35th IEEE
             Symp. Foundations of Comp. Sci., Santa Fe, pp. 154-165,
             1994.





Lee & Bernstein          Expires July 5, 2012                 [Page 27]

Internet-Draft    Framework for Optical Impairments        January 2012


10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

   Copyright (c) 2012 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior
      written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
   FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
   COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
   INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
   BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
   LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
   CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
   LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
   ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
   POSSIBILITY OF SUCH DAMAGE.













Lee & Bernstein          Expires July 5, 2012                 [Page 28]

Internet-Draft    Framework for Optical Impairments        January 2012


Authors' Addresses


   Young Lee (ed.)
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: (972) 509-5599 (x2240)
   Email: ylee@huawei.com


   Greg M. Bernstein (ed.)
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com


   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: danli@huawei.com


   Giovanni Martinelli
   Cisco
   Via Philips 12
   20052 Monza, Italy

   Phone: +39 039 2092044
   Email: giomarti@cisco.com


Contributor's Addresses


   Ming Chen
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

Lee & Bernstein          Expires July 5, 2012                 [Page 29]

Internet-Draft    Framework for Optical Impairments        January 2012



   Phone: +86-755-28973237
   Email: mchen@huawei.com

   Rebecca Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: hanjianrui@huawei.com

   Gabriele Galimberti
   Cisco
   Via Philips 12,
   20052 Monza, Italy

   Phone: +39 039 2091462
   Email: ggalimbe@cisco.com

   Alberto Tanzi
   Cisco
   Via Philips 12,
   20052 Monza, Italy

   Phone: +39 039 2091469
   Email: altanzi@cisco.com

   David Bianchi
   Cisco
   Via Philips 12,
   20052 Monza, Italy

   Email: davbianc@cisco.com

   Moustafa Kattan
   Cisco
   Dubai  500321
   United Arab Emirates

   Email: mkattan@cisco.com

   Dirk Schroetter
   Cisco

   Email: dschroet@cisco.com


Lee & Bernstein          Expires July 5, 2012                 [Page 30]

Internet-Draft    Framework for Optical Impairments        January 2012


   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com

   Elisa Bellagamba
   Ericsson
   Farogatan 6,
   Kista   164 40
   Sweeden

   Email: elisa.bellagamba@ericcson.com

   Diego Caviglia
   Ericsson
   Via A. negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: diego.caviglia@ericcson.com


























Lee & Bernstein          Expires July 5, 2012                 [Page 31]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/