Network Working Group                                            Y. Lee
Internet Draft                                                   Huawei
Intended status: Informational                             G. Bernstein
Expires: March August 2011                                  Grotto Networking
                                                                  D. Li
                                                             W. Imajuku

                                                      September 3, 2010

                                                      February 28, 2011

    Routing and Wavelength Assignment Information Model for Wavelength
                         Switched Optical Networks



Status of this Memo

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

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 3, August 28, 2011.

Copyright Notice

   Copyright (c) 2010 2011 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.


   This document provides a model of information needed by the routing
   and wavelength assignment (RWA) process in wavelength switched
   optical networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath computation in
   WSONs. This model takes into account compatibility constraints
   between WSON signal attributes and network elements but does not
   include constraints due to optical impairments. Aspects of this
   information that may be of use to other technologies utilizing a
   GMPLS control plane are discussed.

Table of Contents

   1. Introduction...................................................3
      1.1. Revision History..........................................4
         1.1.1. Changes from 01......................................4
         1.1.2. Changes from 02......................................4
         1.1.3. Changes from 03......................................4
         1.1.4. Changes from 04......................................5
         1.1.5. Changes from 05......................................5
         1.1.6. Changes from 06......................................5
         1.1.7. Changes from 07......................................5
         1.1.8. Changes from 08......................................5
         1.1.9. Changes from 09......................................5
   2. Terminology....................................................5 Terminology....................................................6
   3. Routing and Wavelength Assignment Information Model............6
      3.1. Dynamic and Relatively Static Information.................6 Information.................7
   4. Node Information (General).....................................7
      4.1. Connectivity Matrix.......................................7
      4.2. Shared Risk Node Group....................................8
   5. Node Information (WSON specific)...............................8 specific)...............................9
      5.1. Resource Accessibility/Availability.......................9 Accessibility/Availability......................10
      5.2. Resource Signal Constraints and Processing Capabilities..13
      5.3. Compatibility and Capability Details.....................14
         5.3.1. Shared Ingress or Egress Indication.................14
         5.3.2. Modulation Type List................................14
         5.3.3. FEC Type List.......................................14
         5.3.4. Bit Rate Range List.................................14
         5.3.5. Acceptable Client Signal List.......................15
         5.3.6. Processing Capability List..........................15
   6. Link Information (General)....................................15
      6.1. Administrative Group.....................................16
      6.2. Interface Switching Capability Descriptor................16
      6.3. Link Protection Type (for this link).....................16
      6.4. Shared Risk Link Group Information.......................16
      6.5. Traffic Engineering Metric...............................16
      6.6. Port Label (Wavelength) Restrictions.....................16
         6.6.1. Port-Wavelength Exclusivity Example.................18
   7. Dynamic Components of the Information Model...................19
      7.1. Dynamic Link Information (General).......................20
      7.2. Dynamic Node Information (WSON Specific).................20
   8. Security Considerations.......................................20
   9. IANA Considerations...........................................21
   10. Acknowledgments..............................................21
   11. References...................................................22
      11.1. Normative References....................................22
      11.2. Informative References..................................23
   12. Contributors.................................................24
   Author's Addresses...............................................24
   Intellectual Property Statement..................................25
   Disclaimer of Validity...........................................26

1. Introduction

   The purpose of the following information model for WSONs is to
   facilitate constrained lightpath computation and as such is not a
   general purpose network management information model. This constraint
   is frequently referred to as the "wavelength continuity" constraint,
   and the corresponding constrained lightpath computation is known as
   the routing and wavelength assignment (RWA) problem. Hence the
   information model must provide sufficient topology and wavelength
   restriction and availability information to support this computation.
   More details on the RWA process and WSON subsystems and their
   properties can be found in [WSON-Frame]. The model defined here
   includes constraints between WSON signal attributes and network
   elements, but does not include optical impairments.

   In addition to presenting an information model suitable for path
   computation in WSON, this document also highlights model aspects that
   may have general applicability to other technologies utilizing a
   GMPLS control plane. We refer to the information model applicable to
   other technologies beyond WSON as "general" to distinguish from the
   "WSON-specific" model that is applicable only to WSON technology.

   1.1. Revision History

   1.1.1. Changes from 01

   Added text on multiple fixed and switched connectivity matrices.

   Added text on the relationship between SRNG and SRLG and encoding

   Added clarifying text on the meaning and use of port/wavelength

   Added clarifying text on wavelength availability information and how
   to derive wavelengths currently in use.

   1.1.2. Changes from 02

   Integrated switched and fixed connectivity matrices into a single
   "connectivity matrix" model. Added numbering of matrices to allow for
   wavelength (time slot, label) dependence of the connectivity.
   Discussed general use of this node parameter beyond WSON.

   Integrated switched and fixed port wavelength restrictions into a
   single port wavelength restriction of which there can be more than
   one and added a reference to the corresponding connectivity matrix if
   there is one. Also took into account port wavelength restrictions in
   the case of symmetric switches, developed a uniform model and
   specified how general label restrictions could be taken into account
   with this model.

   Removed the Shared Risk Node Group parameter from the node info, but
   left explanation of how the same functionality can be achieved with
   existing GMPLS SRLG constructs.

   Removed Maximum bandwidth per channel parameter from link

   1.1.3. Changes from 03

   Removed signal related text from section 3.2.4 as signal related
   information is deferred to a new signal compatibility draft.

   Removed encoding specific text from Section 3.3.1 of version 03.

   1.1.4. Changes from 04

   Removed encoding specific text from Section 4.1.

   Removed encoding specific text from Section 3.4.

   1.1.5. Changes from 05

   Renumbered sections for clarity.

   Updated abstract and introduction to encompass signal

   Generalized Section on wavelength converter pools to include electro
   optical subsystems in general.  This is where we added signal
   compatibility modeling.

   1.1.6. Changes from 06

   Simplified information model for WSON specifics, by combining similar
   fields and introducing simpler aggregate information elements.

   1.1.7. Changes from 07

   Added shared fiber connectivity to resource pool modeling. This
   includes information for determining wavelength collision on an
   internal fiber providing access to resource blocks.

   1.1.8. Changes from 08

   Added PORT_WAVELENGTH_EXCLUSIVITY in the RestrictionType parameter.
   Added section 6.6.1 that has an example of the port wavelength
   exclusivity constraint.

   1.1.9. Changes from 09

   Section 5: clarified the way that the resource pool is modeled from
   blocks of identical resources.

   Section 5.1: grammar fixes. Removed reference to "academic" modeling
   pre-print. Clarified RBNF resource pool model details.

   Section 5.2: Formatting fixes.

2. Terminology

   CWDM: Coarse Wavelength Division Multiplexing.

   DWDM: Dense Wavelength Division Multiplexing.

   FOADM: Fixed Optical Add/Drop Multiplexer.

   ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port
   count wavelength selective switching element featuring ingress and
   egress line side ports as well as add/drop side ports.

   RWA: Routing and Wavelength Assignment.

   Wavelength Conversion. The process of converting an 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 Network (WSON): A WDM based optical
   network in which switching is performed selectively based on the
   center wavelength of an optical signal.

3. Routing and Wavelength Assignment Information Model

   We group the following WSON RWA information model into four
   categories regardless of whether they stem from a switching subsystem
   or from a line subsystem:

   o  Node Information

   o  Link Information

   o  Dynamic Node Information

   o  Dynamic Link Information

   Note that this is roughly the categorization used in [G.7715] section

   In the following we use, where applicable, the reduced Backus-Naur
   form (RBNF) syntax of [RBNF] to aid in defining the RWA information

   3.1. Dynamic and Relatively Static Information

   All the RWA information of concern in a WSON network is subject to
   change over time.  Equipment can be upgraded; links may be placed in
   or out of service and the like.  However, from the point of view of
   RWA computations there is a difference between information that can
   change with each successive connection establishment in the network
   and that information that is relatively static on the time scales of
   connection establishment. A key example of the former is link
   wavelength usage since this can change with connection setup/teardown
   and this information is a key input to the RWA process.  Examples of
   relatively static information are the potential port connectivity of
   a WDM ROADM, and the channel spacing on a WDM link.

   In this document we will separate, where possible, dynamic and static
   information so that these can be kept separate in possible encodings
   and hence allowing for separate updates of these two types of
   information thereby reducing processing and traffic load caused by
   the timely distribution of the more dynamic RWA WSON information.

4. Node Information (General)

   The node information described here contains the relatively static
   information related to a WSON node. This includes connectivity
   constraints amongst ports and wavelengths since WSON switches can
   exhibit asymmetric switching properties. Additional information could
   include properties of wavelength converters in the node if any are
   present. In [Switch] it was shown that the wavelength connectivity
   constraints for a large class of practical WSON devices can be
   modeled via switched and fixed connectivity matrices along with
   corresponding switched and fixed port constraints. We include these
   connectivity matrices with our node information the switched and
   fixed port wavelength constraints with the link information.


   <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]

   Where the Node_ID would be an appropriate identifier for the node
   within the WSON RWA context.

   Note that multiple connectivity matrices are allowed and hence can
   fully support the most general cases enumerated in [Switch].

   4.1. Connectivity Matrix

   The connectivity matrix (ConnectivityMatrix) represents either the
   potential connectivity matrix for asymmetric switches (e.g. ROADMs
   and such) or fixed connectivity for an asymmetric device such as a
   multiplexer. Note that this matrix does not represent any particular
   internal blocking behavior but indicates which ingress ports and
   wavelengths could possibly be connected to a particular output port.
   Representing internal state dependent blocking for a switch or ROADM
   is beyond the scope of this document and due to it's highly
   implementation dependent nature would most likely not be subject to
   standardization in the future. The connectivity matrix is a
   conceptual M by N matrix representing the potential switched or fixed
   connectivity, where M represents the number of ingress ports and N
   the number of egress ports. We say this is a "conceptual" matrix
   since this matrix tends to exhibit structure that allows for very
   compact representations that are useful for both transmission and
   path computation [Encode].

   Note that the connectivity matrix information element can be useful
   in any technology context where asymmetric switches are utilized.

   ConnectivityMatrix(i, j) ::= <MatrixID> <ConnType> <Matrix>


   <MatrixID> is a unique identifier for the matrix.

   <ConnType> can be either 0 or 1 depending upon whether the
   connectivity is either fixed or potentially switched.

   <Matrix> represents the fixed or switched connectivity in that
   Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect
   to egress port j for one or more wavelengths.

   4.2. Shared Risk Node Group

   SRNG: Shared risk group for nodes. The concept of a shared risk link
   group was defined in [RFC4202]. This can be used to achieve a desired
   "amount" of link diversity. It is also desirable to have a similar
   capability to achieve various degrees of node diversity. This is
   explained in [G.7715]. Typical risk groupings for nodes can include
   those nodes in the same building, within the same city, or geographic

   Since the failure of a node implies the failure of all links
   associated with that node a sufficiently general shared risk link
   group (SRLG) encoding, such as that used in GMPLS routing extensions
   can explicitly incorporate SRNG information.

5. Node Information (WSON specific)

   As discussed in [WSON-Frame] a WSON node may contain electro-optical
   subsystems such as regenerators, wavelength converters or entire
   switching subsystems. The model present here can be used in
   characterizing the accessibility and availability of limited
   resources such as regenerators or wavelength converters as well as
   WSON signal attribute constraints of electro-optical subsystems. As
   such this information element is fairly specific to WSON

   A WSON node may include regenerators or wavelength converters
   arranged in a shared pool. As discussed in [WSON-Frame] this can
   include OEO based WDM switches as well. There are a number of
   different approaches used in the design of WDM switches containing
   regenerator or converter pools. However, from the point of view of
   path computation we need to know the following:

   1. The nodes that support regeneration or wavelength conversion.

   2. The accessibility and availability of a wavelength converter to
      convert from a given ingress wavelength on a particular ingress
      port to a desired egress wavelength on a particular egress port.

   3. Limitations on the types of signals that can be converted and the
      conversions that can be performed.

   For modeling purposes and encoding efficiency we group identical
   processing resources such as regenerators or wavelength converters
   with identical accessibility properties into "blocks". The resource
   pool model is composed of one or more resource blocks where the
   accessibility to and from any resource within a block must be is the same. The resource pool is composed of one or more

   This leads to the following formal high level model:

   <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]


   <ResourcePool> ::= <ResourceBlockInfo>...
   [<ResourceBlockAccessibility>...] [<ResourceWaveConstraints>...]

   First we will address the accessibility of resource blocks then we
   will discuss their properties.

   5.1. Resource Accessibility/Availability

   A similar technique as used to model ROADMs and optical switches can
   be used to model regenerator/converter accessibility. This technique
   was generally discussed in [WSON-Frame] and consisted of a matrix to
   indicate possible connectivity along with wavelength constraints for
   links/ports. Since regenerators or wavelength converters may be
   considered a scarce resource we will also want to our model to
   include as a minimum the usage state (availability) of individual
   regenerators or converters in the pool. Models that incorporate more
   state to further reveal blocking conditions on ingress or egress to
   particular converters are for further study and not included here.

   The three stage model as is shown schematically in Figure 1 and Figure
   2. The difference between the two figures is that in Figure 1 we
   assume that each signal that can get to a resource block may do so,
   while in Figure 2 the access to the resource blocks is via a shared
   fiber which imposes its own wavelength collision constraint. In the
   representation of Figure 1 we can have more than one ingress to each
   resource block since each ingress represents a single wavelength
   signal, while in Figure 2 we show a single multiplexed WDM ingress,
   e.g., a fiber, to each block.

    In this model we assume N ingress ports (fibers), P resource blocks
   containing one or more identical resources (e.g. wavelength
   converters), and M egress ports (fibers). Since not all ingress ports
   can necessarily reach each resource block, the model starts with a
   resource pool ingress matrix RI(i,p) = {0,1} whether ingress port i
   can reach potentially reach resource block p.

   Since not all wavelengths can necessarily reach all the resources or
   the resources may have limited input wavelength range we have a set
   of relatively static ingress port constraints for each resource. In
   addition, if the access to a resource block is via a shared fiber
   (Figure 2) this would impose a dynamic wavelength availability
   constraint on that shared fiber. We can model each resource block
   ingress port constraint via a static wavelength set mechanism and in
   the case of shared access to a block via another dynamic wavelength
   set mechanism.

   Next we have a state vector RA(j) = {0,...,k} which tells us the
   number of resources in resource block j in use. This is the only
   state kept in the resource pool model. This state is not necessary
   for modeling "fixed" transponder system or full OEO switches with WDM
   interfaces, i.e., systems where there is no sharing.

   After that, we have a set of static resource egress wavelength
   constraints and possibly dynamic shared egress fiber constraints. The
   static constraints indicate what wavelengths a particular resource
   block can generate or are restricted to generating e.g., a fixed
   regenerator would be limited to a single lambda. The dynamic
   constraints would be used in the case where a single shared fiber is
   used to egress the resource block (Figure 2).

   Finally, we have a resource pool egress matrix RE(p,k) = {0,1}
   depending on whether the output from resource block p can reach
   egress port k. Examples of this method being used to model wavelength
   converter pools for several switch architectures from the literature
   are given in reference [WC-Pool].

      I1   +-------------+                       +-------------+ E1
     ----->|             |      +--------+       |             |----->
      I2   |             +------+ Rb #1  +-------+             | E2
     ----->|             |      +--------+       |             |----->
           |             |                       |             |
           | Resource    |      +--------+       |  Resource   |
           | Pool        +------+        +-------+  Pool       |
           |             |      + Rb #2  +       |             |
           | Ingress     +------+        +-------|  Egress     |
           | Connection  |      +--------+       |  Connection |
           | Matrix      |           .           |  Matrix     |
           |             |           .           |             |
           |             |           .           |             |
      IN   |             |      +--------+       |             | EM
     ----->|             +------+ Rb #P  +-------+             |----->
           |             |      +--------+       |             |
           +-------------+   ^               ^   +-------------+
                             |               |
                             |               |
                             |               |
                             |               |

                    Ingress wavelength    Egress wavelength
                    constraints for       constraints for
                    each resource         each resource

            Figure 1 Schematic diagram of resource pool model.

      I1   +-------------+                       +-------------+ E1
     ----->|             |      +--------+       |             |----->
      I2   |             +======+ Rb #1  +=======+             | E2
     ----->|             |      +--------+       |             |----->
           |             |                       |             |
           | Resource    |      +--------+       |  Resource   |
           | Pool        |      |  Pool        |       |  Pool       |
           |             |======+ Rb #2  +=======+             |
           | Ingress     |      +        |       |  Egress     |
           | Connection  |      +--------+       |  Connection |
           | Matrix      |           .           |  Matrix     |
           |             |           .           |             |
           |             |           .           |             |
      IN   |             |      +--------+       |             | EM
     ----->|             +======+ Rb #P  +=======+             |----->
           |             |      +--------+       |             |
           +-------------+   ^               ^   +-------------+
                             |               |
                             |               |
                             |               |
                 Single (shared) fibers for block ingress and egress

                  Ingress wavelength         Egress wavelength
                  availability for           availability for
                  each block ingress fiber each block egress fiber

    Figure 2 Schematic diagram of resource pool model with shared block

   Formally we can specify complete the specification of the model as: with:

   <ResourceBlockAccessibility ::= <PoolIngressMatrix>

   [<ResourceWaveConstraints> ::= <IngressWaveConstraints>



   Note that except for <ResourcePoolState> all the other components of
   <ResourcePool> are relatively static. Also the
   <InAvailableWavelengths> and <OutAvailableWavelengths> are only used
   in the cases of shared ingress or egress access to the particular
   block. See the resource block information in the next section to see
   how this is specified.

   5.2. Resource Signal Constraints and Processing Capabilities

   The wavelength conversion abilities of a resource (e.g. regenerator,
   wavelength converter) were modeled in the <EgressWaveConstraints>
   previously discussed. As discussed in [WSON-Frame] we can model the
   constraints on an electro-optical resource in terms of input
   constraints, processing capabilities, and output constraints:

   <ResourceBlockInfo> ::=
   traints>)* ([<ResourceSet>] <InputConstraints>
   <ProcessingCapabilities> <OutputConstraints>)*

   Where  <ResourceSet> is a list of resource block identifiers with the
   same characteristics. If this set is missing the constraints are
   applied to the entire network element.

   The <InputConstraints> are signal compatibility based constraints
   and/or shared access constraint indication. The details of these
   constraints are defined in section 5.3.

   <InputConstraints> ::= <SharedIngress><ModulationTypeList> <SharedIngress> <ModulationTypeList>
   <FECTypeList> <BitRateRange> <ClientSignalList>

   The <ProcessingCapabilities> are important operations that the
   resource (or network element) can perform on the signal. The details
   of these capabilities are defined in section 5.3.

   <ProcessingCapabilities> ::= <NumResources>
   <RegenerationCapabilities> <FaultPerfMon> <VendorSpecific>

   The <OutputConstraints> are either restrictions on the properties of
   the signal leaving the block, options concerning the signal
   properties when leaving the resource or shared fiber egress
   constraint indication.

   <OutputConstraints> :=
   <SharedEgress><ModulationTypeList><FECTypeList> <SharedEgress> <ModulationTypeList>
   5.3. Compatibility and Capability Details

   5.3.1. Shared Ingress or Egress Indication

   As discussed in the previous section and shown in Figure 2 the
   ingress or egress access to a resource block may be via a shared
   fiber. The <SharedIngress> and <SharedEgress> elements are indicators
   for this condition with respect to the block being described.

      5.3.2. Modulation Type List

      Modulation type, also known as optical tributary signal class,
      comes in two distinct flavors: (i) ITU-T standardized types; (ii)
      vendor specific types. The permitted modulation type list can
      include any mixture of standardized and vendor specific types.


      Where the STANDARD_MODULATION object just represents one of the
      ITU-T standardized optical tributary signal class and the
      VENDOR_MODULATION object identifies one vendor specific modulation

      5.3.3. FEC Type List

      Some devices can handle more than one FEC type and hence a list is

      <fec-list>::= [<FEC>]

      Where the FEC object represents one of the ITU-T standardized FECs
      defined in [G.709], [G.707], [G.975.1] or a vendor-specific FEC.

      5.3.4. Bit Rate Range List

      Some devices can handle more than one particular bit rate range
      and hence a list is needed.

      <rate-range-list>::= [<rate-range>]...


      Where the START_RATE object represents the lower end of the range
      and the END_RATE object represents the higher end of the range.

      5.3.5. Acceptable Client Signal List

      The list is simply:


      Where the Generalized Protocol Identifiers (GPID) object
      represents one of the IETF standardized GPID values as defined in
      [RFC3471] and [RFC4328].

      5.3.6. Processing Capability List

     We have defined ProcessingCapabilities in Section 5.2 as follows:

     <ProcessingCapabilities> ::= <NumResources>
     <RegenerationCapabilities> <FaultPerfMon> <VendorSpecific>

     The processing capability list sub-TLV is a list of processing
     functions that the WSON network element (NE) can perform on the
     signal including:

        1. Number of Resources within the block

        2. Regeneration capability

        3. Fault and performance monitoring

        4. Vendor Specific capability

     Note that the code points for Fault and performance monitoring and
     vendor specific capability are subject to further study.

6. Link Information (General)

   MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630],
   [RFC5305] along with GMPLS routing protocol extensions for OSPF and
   IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static
   link information needed by the RWA process. However, WSON networks
   bring in additional link related constraints. These stem from WDM
   line system characterization, laser transmitter tuning restrictions,
   and switching subsystem port wavelength constraints, e.g., colored
   ROADM drop ports.

   In the following summarize both information from existing GMPLS route
   protocols and new information that maybe needed by the RWA process.

   <LinkInfo> ::=  <LinkID> [<AdministrativeGroup>] [<InterfaceCapDesc>]
   [<Protection>] [<SRLG>]... [<TrafficEngineeringMetric>]

   6.1. Administrative Group

   AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds
   to one administrative group assigned to the interface.  A link may
   belong to multiple groups. This is a configured quantity and can be
   used to influence routing decisions.

   6.2. Interface Switching Capability Descriptor

   InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different
   switching capabilities on this GMPLS interface. In both [RFC4203] and
   [RFC5307] this information gets combined with the maximum LSP
   bandwidth that can be used on this link at eight different priority

   6.3. Link Protection Type (for this link)

   Protection: Defined in [RFC4202] and implemented in [RFC4203,
   RFC5307]. Used to indicate what protection, if any, is guarding this

   6.4. Shared Risk Link Group Information

   SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307].
   This allows for the grouping of links into shared risk groups, i.e.,
   those links that are likely, for some reason, to fail at the same

   6.5. Traffic Engineering Metric

   TrafficEngineeringMetric: Defined in [RFC3630].  This allows for the
   definition of one additional link metric value for traffic
   engineering separate from the IP link state routing protocols link
   metric. Note that multiple "link metric values" could find use in
   optical networks, however it would be more useful to the RWA process
   to assign these specific meanings such as link mile metric, or
   probability of failure metric, etc...

   6.6. Port Label (Wavelength) Restrictions

   Port label (wavelength) restrictions (PortLabelRestriction) model the
   label (wavelength) restrictions that the link and various optical
   devices such as OXCs, ROADMs, and waveband multiplexers may impose on
   a port. These restrictions tell us what wavelength may or may not be
   used on a link and are relatively static. This plays an important
   role in fully characterizing a WSON switching device [Switch]. Port
   wavelength restrictions are specified relative to the port in general
   or to a specific connectivity matrix (section 4.1.  Reference
   [Switch] gives an example where both switch and fixed connectivity
   matrices are used and both types of constraints occur on the same
   port. Such restrictions could be applied generally to other label
   types in GMPLS by adding new kinds of restrictions.

   <PortLabelRestriction> ::= [<GeneralPortRestrictions>...]

   <GeneralPortRestrictions> ::= <RestrictionType>

   <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType>

   <RestrictionParameters> ::= [<LabelSet>...] [<MaxNumChannels>]


   MatrixID is the ID of the corresponding connectivity matrix (section

   The RestrictionType parameter is used to specify general port
   restrictions and matrix specific restrictions. It can take the
   following values and meanings:

   SIMPLE_WAVELENGTH:   Simple wavelength set restriction; The
   wavelength set parameter is required.

   CHANNEL_COUNT: The number of channels is restricted to be less than
   or equal to the Max number of channels parameter (which is required).

   PORT_WAVELENGTH_EXCLUSIVITY: A wavelength can be used at most once
   among a given set of ports. The set of ports is specified as a
   parameter to this constraint.

   WAVEBAND1:   Waveband device with a tunable center frequency and
   passband. This constraint is characterized by the MaxWaveBandWidth
   parameters which indicates the maximum width of the waveband in terms
   of channels. Note that an additional wavelength set can be used to
   indicate the overall tuning range. Specific center frequency tuning
   information can be obtained from dynamic channel in use information.

   It is assumed that both center frequency and bandwidth (Q) tuning can
   be done without causing faults in existing signals.

   Restriction specific parameters are used with one or more of the
   previously listed restriction types. The currently defined parameters

     LabelSet is a conceptual set of labels (wavelengths).

     MaxNumChannels is the maximum number of channels that can be
     simultaneously used (relative to either a port or a matrix).

     MaxWaveBandWidth is the maximum width of a tunable waveband
     switching device.

     PortSet is a conceptual set of ports.

   For example, if the port is a "colored" drop port of a ROADM then we
   have two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1,
   and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a
   single member corresponding to the frequency of the permitted
   wavelength. See [Switch] for a complete waveband example.

   This information model for port wavelength (label) restrictions is
   fairly general in that it can be applied to ports that have label
   restrictions only or to ports that are part of an asymmetric switch
   and have label restrictions. In addition, the types of label
   restrictions that can be supported are extensible.

   6.6.1. Port-Wavelength Exclusivity Example

   Although there can be many different ROADM or switch architectures
   that can lead to the constraint where a lambda (label) maybe used at
   most once on a set of ports Figure 3 shows a ROADM architecture based
   on components known as a Wavelength Selective Switch (WSS)[OFC08].
   This ROADM is composed of splitters, combiners, and WSSes. This ROADM
   has 11 egress ports, which are numbered in the diagram. Egress ports
   1-8 are known as drop ports and are intended to support a single
   wavelength. Drop ports 1-4 egress from WSS #2, which is fed from WSS
   #1 via a single fiber. Due to this internal structure a constraint is
   placed on the egress ports 1-4 that a lambda can be only used once
   over the group of ports (assuming uni-cast and not multi-cast
   operation). Similarly we see that egress ports 5-8 have a similar
   constraint due to the internal structure.

                               |               A
                               v            10 |
                           +-------+        +-------+
                           | Split |        |WSS  6 |
                           +-------+        +-------+
        +----+              | | | |          | | | |
        | W  |              | | | |          | | | +-------+   +----+
        | S  |--------------+ | | |    +-----+ | +----+    |   | S  |
      9 | S  |----------------|---|----|-------|------|----|---| p  |
     <--|    |----------------|---|----|-------|----+ |    +---| l  |<--
        | 5  |--------------+ |   |    | +-----+    | |     +--| i  |
        +----+              | |   |    | |   +------|-|-----|--| t  |
                   +--------|-+   +----|-|---|------|----+  |  +----+
        +----+     |        |          | |   |      | |  |  |
        | S  |-----|--------|----------+ |   |      | |  |  |  +----+
        | p  |-----|--------|------------|---|------|----|--|--| W  |
     -->| l  |-----|-----+  | +----------+   |      | |  +--|--| S  |11
        | i  |---+ |     |  | | +------------|------|-------|--| S  |-->
        | t  |   | |     |  | | |            |      | | +---|--|    |
        +----+   | | +---|--|-|-|------------|------|-|-|---+  | 7  |
                 | | |   +--|-|-|--------+ | |      | | |      +----+
                 | | |      | | |        | | |      | | |
                +------+   +------+     +------+   +------+
                | WSS 1|   | Split|     | WSS 3|   | Split|
                +--+---+   +--+---+     +--+---+   +--+---+
                   |          A            |          A
                   v          |            v          |
                +-------+  +--+----+    +-------+  +--+----+
                | WSS 2 |  | Comb. |    | WSS 4 |  | Comb. |
                +-------+  +-------+    +-------+  +-------+
                1|2|3|4|    A A A A     5|6|7|8|    A A A A
                 v v v v    | | | |      v v v v    | | | |

       Figure 3 A ROADM composed from splitter, combiners, and WSSs.

7. Dynamic Components of the Information Model

   In the previously presented information model there are a limited
   number of information elements that are dynamic, i.e., subject to
   change with subsequent establishment and teardown of connections.
   Depending on the protocol used to convey this overall information
   model it may be possible to send this dynamic information separate
   from the relatively larger amount of static information needed to
   characterize WSON's and their network elements.

   7.1. Dynamic Link Information (General)

   For WSON links wavelength availability and wavelengths in use for
   shared backup purposes can be considered dynamic information and
   hence we can isolate the dynamic information in the following set:

   <DynamicLinkInfo> ::=  <LinkID> <AvailableLabels>

   AvailableLabels is a set of labels (wavelengths) currently available
   on the link. Given this information and the port wavelength
   restrictions we can also determine which wavelengths are currently in
   use. This parameter could potential be used with other technologies
   that GMPLS currently covers or may cover in the future.

   SharedBackupLabels is a set of labels (wavelengths)currently (wavelengths) currently used
   for shared backup protection on the link. An example usage of this
   information in a WSON setting is given in [Shared]. This parameter
   could potential be used with other technologies that GMPLS currently
   covers or may cover in the future.

   7.2. Dynamic Node Information (WSON Specific)

   Currently the only node information that can be considered dynamic is
   the resource pool state and can be isolated into a dynamic node
   information element as follows:

   <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>]

8. Security Considerations

   This document discussed an information model for RWA computation in
   WSONs. Such a model is very similar from a security standpoint of the
   information that can be currently conveyed via GMPLS routing
   protocols.  Such information includes network topology, link state
   and current utilization, and well as the capabilities of switches and
   routers within the network.  As such this information should be
   protected from disclosure to unintended recipients.  In addition, the
   intentional modification of this information can significantly affect
   network operations, particularly due to the large capacity of the
   optical infrastructure to be controlled.

9. IANA Considerations

   This informational document does not make any requests for IANA

10. Acknowledgments

   This document was prepared using

11. References

   11.1. Normative References

   [Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
             Wavelength Assignment Information Encoding for Wavelength
             Switched Optical Networks", work in progress: draft-ietf-

   [G.707] ITU-T Recommendation G.707, Network node interface for the
             synchronous digital hierarchy (SDH), January 2007.

   [G.709] ITU-T Recommendation G.709, Interfaces for the Optical
             Transport Network(OTN), March 2003.

   [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for
             high bit-rate DWDM submarine systems, February 2004.

   [RBNF]   A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used in
             Various Protocol Specifications", RFC 5511, April 2009.

   [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Functional Description", RFC
             3471, January 2003.

   [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
             (TE) Extensions to OSPF Version 2", RFC 3630, September

   [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005.

   [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Extensions for G.709 Optical
             Transport Networks Control", RFC 4328, January 2006.

   [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
             Engineering", RFC 5305, October 2008.

   [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 5307, October 2008.

   [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
             and PCE Control of Wavelength Switched Optical Networks",
             work in progress: draft-ietf-ccamp-rwa-wson-framework.

   11.2. Informative References

   [OFC08]  P. Roorda and B. Collings, "Evolution to Colorless and
         Directionless ROADM Architectures," Optical Fiber
         communication/National Fiber Optic Engineers Conference, 2008.
         OFC/NFOEC 2008. Conference on, 2008, pp. 1-3.

   [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE-
         based WSON Networks", iPOP 2008, http://www.grotto- .

   [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling
         WDM Wavelength Switching Systems for Use in GMPLS and Automated
         Path Computation", Journal of Optical Communications and
         Networking, vol. 1, June, 2009, pp. 187-195.

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

   [WC-Pool] G. Bernstein, Y. Lee, "Modeling WDM Switching Systems
             including Wavelength Converters" to appear www.grotto-
   , 2008.

12. Contributors

   Diego Caviglia
   Via A. Negrone 1/A 16153
   Genoa Italy

   Phone: +39 010 600 3736
   Email: diego.caviglia@(,

   Anders Gavler
   Acreo AB
   Electrum 236
   SE - 164 40 Kista Sweden


   Jonas Martensson
   Acreo AB
   Electrum 236
   SE - 164 40 Kista, Sweden


   Itaru Nishioka
   NEC Corp.
   1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666

   Phone: +81 44 396 3287

   Lyndon Ong

Author's Addresses

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

   Phone: (510) 573-2237
   Young Lee (ed.)
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075

   Phone: (972) 509-5599 (x2240)

   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

   Wataru Imajuku
   NTT Network Innovation Labs
   1-1 Hikari-no-oka, Yokosuka, Kanagawa

   Phone: +81-(46) 859-4315

Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at

Disclaimer of Validity

   All IETF Documents and the information contained therein are provided


   Funding for the RFC Editor function is currently provided by the
   Internet Society.