Network Working Group                                            Y. Lee
Internet Draft Engineering Task Force (IETF)                       Y. Lee, Ed.
Request for Comments: 7446                                        Huawei
Intended status:
Category: Informational                                G. Bernstein
Expires: June 2015 Bernstein, Ed.
ISSN: 2070-1721                                        Grotto Networking
                                                                   D. Li
                                                                  Huawei
                                                              W. Imajuku
                                                                     NTT

                                                       December 4, 2014
                                                           February 2015

          Routing and Wavelength Assignment Information Model
                for Wavelength Switched Optical Networks

                     draft-ietf-ccamp-rwa-info-24.txt

Abstract

   This document provides a model of information needed by the routing Routing
   and wavelength assignment Wavelength Assignment (RWA) process in wavelength switched
   optical networks Wavelength Switched
   Optical Networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath optical path 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.

Status of this This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product 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
   (IETF).  It represents the consensus of six
   months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents
   at
   approved by the IESG are a candidate for any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on June 4, 2015.
   http://www.rfc-editor.org/info/rfc7446.

Copyright Notice

   Copyright (c) 2014 2015 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 Introduction ....................................................3
   2. Terminology....................................................3 Terminology .....................................................3
   3. Routing and Wavelength Assignment Information Model............4 Model .............3
      3.1. Dynamic and Relatively Static Information.................4 Information ..................4
   4. Node Information (General).....................................5 (General) ......................................4
      4.1. Connectivity Matrix.......................................5 Matrix ........................................5
   5. Node Information (WSON specific)...............................6 Specific) ................................5
      5.1. Resource Accessibility/Availability.......................7 Accessibility/Availability ........................7
      5.2. Resource Signal Constraints and Processing Capabilities..11 Capabilities ...11
      5.3. Compatibility and Capability Details.....................12 Details ......................12
           5.3.1. Shared Input or Output Indication...................12 Indication ..................12
           5.3.2. Optical Interface Class List........................13 List .......................12
           5.3.3. Acceptable Client Signal List.......................13 List ......................13
           5.3.4. Processing Capability List..........................13 List .........................13
   6. Link Information (General)....................................14 (General) .....................................13
      6.1. Administrative Group.....................................14 Group ......................................14
      6.2. Interface Switching Capability Descriptor................15
      6.3. Link Protection Type (for this link).....................15
      6.4. Shared Risk Link Group Information.......................15
      6.5. Traffic Engineering Metric...............................15
      6.6. Port Label Restrictions..................................15 Descriptor .................14
           6.6.1. Port-Wavelength Exclusivity Example.................18 Example ................17
   7. Dynamic Components of the Information Model...................19 Model ....................18
      7.1. Dynamic Link Information (General).......................20 (General) ........................19
      7.2. Dynamic Node Information (WSON Specific).................20 Specific) ..................19
   8. Security Considerations.......................................20 Considerations ........................................19
   9. IANA Considerations...........................................21
   10. Acknowledgments..............................................21
   11. References...................................................22
      11.1. References .....................................................20
      9.1. Normative References....................................22
      11.2. References ......................................20
      9.2. Informative References..................................23
   12. Contributors.................................................24 References ....................................21
   Contributors ......................................................22
   Authors' Addresses...............................................25
   Intellectual Property Statement..................................25
   Disclaimer of Validity...........................................26 Addresses ................................................23

1.  Introduction

   The purpose of the WSONs WSON information model described in this document
   is to facilitate constrained lightpath computation optical path computation, and as such it
   is not a general purpose general-purpose network management information model.  This
   constraint is frequently referred to as the "wavelength continuity"
   constraint, and the corresponding constrained lightpath optical path
   computation is known as the routing Routing and wavelength assignment Wavelength Assignment (RWA)
   problem. Hence  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 [RFC6163].  The model
   defined here includes constraints between WSON signal attributes and
   network elements, 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.  The portion of the information model applicable
   to other technologies beyond WSON is referred to as "general" to
   distinguish it from the "WSON-specific" portion that is applicable
   only to WSON technology.

2.  Terminology

   Refer to [RFC6163] for definitions of Reconfigurable Optical Add/Drop
   Multiplexer (ROADM), RWA, Wavelength Conversion, Wavelength Division
   Multiplexing (WDM) (WDM), WSON, and WSON. other related terminology used in this
   document.

3.  Routing and Wavelength Assignment Information Model

   The WSON RWA information model in this document comprises four
   categories of information.  The categories are independent of whether
   the information comes from a switching subsystem or from a line
   subsystem -- a switching subsystem refers to WSON nodes such as a
   ROADM or an Optical Add/Drop Multiplexer (OADM), and a line subsystem
   refers to devices such as WDM or Optical Amplifier.  The categories
   are these:

   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 7. Section 7 of
   [G.7715].

   In the following, where applicable, the reduced Reduced Backus-Naur form Form
   (RBNF) syntax of [RBNF] is used to aid in defining the RWA
   information model.

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 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 and independent 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.

   This document separates, where possible, dynamic and static
   information so that these can be kept separate in possible encodings
   and hence allowing encodings.
   This allows for separate updates of these two types of
   information 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 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.  These
   connectivity matrices are included with the node information information, while
   the switched and fixed port wavelength constraints are included with
   the link information.

   Formally,

   <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 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. (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 input ports and
   wavelengths could possibly be connected to a particular output port.
   Representing internal state dependent blocking for
   For a switch or ROADM ROADM, representing blocking that is dependent on the
   internal state is beyond the scope of this document and due document.  Due to its
   highly
   implementation dependent nature implementation-dependent nature, it 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 input ports and
   N the number of output ports.  This is a "conceptual" matrix since
   the matrix tends to exhibit structure that allows for very compact
   representations that are useful for both transmission and path
   computation.

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

   <ConnectivityMatrix> ::= <MatrixID>

                            <ConnType>

                            <Matrix>

   Where

   <MatrixID> is a unique identifier for the matrix.

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

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

5.  Node Information (WSON specific) Specific)

   As discussed in [RFC6163] [RFC6163], 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
   such, this information element is fairly specific to WSON
   technologies.

   In this document, the term "resource" is used to refer to a physical
   component of a WSON node such as a regenerator or a wavelength
   converter.  Multiple instances of such components are often present
   within a single WSON node.  This term is not to be confused with the
   concept of forwarding or switching resources such as bandwidth or
   lambdas.

   A WSON node may include regenerators or wavelength converters
   arranged in a shared pool.  As discussed in [RFC6163] this [RFC6163], a WSON node
   can also include OEO based WDM switches as well. that use optical-electronic-optical
   (OEO) processing.  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 computation, the following
   need to be known:

   1.  The nodes that support regeneration or wavelength conversion.

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

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

   Since resources tend to be packaged together in blocks of similar
   devices, e.g., on line cards or other types of modules, the
   fundamental unit of identifiable resource in this document is the
   "resource block".

   A resource block may contain one or more
   resources. A resource is the smallest identifiable unit a collection of
   processing allocation. One can group resources from the same WSON node
   that are grouped together for administrative reasons and for ease of
   encoding in the protocols.  All resources into blocks
   if they in the same resource block
   behave in the same way and have similar characteristics relevant to
   the optical system
   being modeled, system, e.g., processing properties, accessibility, etc.

   A resource pool is a collection of resource blocks for the purpose of
   representing throughput or cross-connect capabilities in a WSON node.
   A resource pool associates input ports or links on the node with
   output ports or links and is used to indicate how signals may be
   passed from an input port or link to an output port or link by way of
   a resource block (in other words, by way of a resource).  A resource
   pool may, therefore, be modeled as a matrix.

   A resource block may be present in multiple resource pools.

   This leads to the following formal high level high-level model:

   <Node_Information> ::= <Node_ID>

                          [<ConnectivityMatrix>...]

                          [<ResourcePool>]

   Where

   <ResourcePool> ::= <ResourceBlockInfo>...

                     [<ResourceAccessibility>...]

                     [<ResourceWaveConstraints>...]

                     [<RBPoolState>]

   First

   First, the accessibility of resource blocks is addressed then addressed; then, their
   properties are discussed.

5.1.  Resource Accessibility/Availability

   A similar technique as used to model ROADMs ROADMs, and optical switches can
   be used to model regenerator/converter accessibility.  This technique
   was generally discussed in [RFC6163] 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 resource, it is desirable that the model include,
   if desired, the usage state (availability) of individual regenerators
   or converters in the pool.  Models that incorporate more state to
   further reveal blocking conditions on input or output to particular
   converters are for further study and not included here.

   The three stage three-stage model is shown schematically in Figure Figures 1 and Figure 2.  The
   difference between the two figures is that in Figure 1 assumes it's assumed
   that each signal that can get to a resource block may do so, while in
   Figure 2 the access to sets of resource blocks is via a shared fiber which
   that imposes its own wavelength collision constraint. The
   representation of  Figure 1 shows
   that there can have be more than one input to each resource block since
   each input represents a single wavelength signal, while in Figure 2
   shows a single multiplexed WDM input or output, e.g., a fiber, to/from each set
   of block. blocks.

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

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

   Next

   Next, a state vector RA(j) = {0,...,k} is used to track 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, a set of static resource output wavelength constraints
   and possibly dynamic shared output fiber constraints maybe used.  The
   static constraints indicate what wavelengths a particular resource
   block can generate or are is restricted to generating 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 output the resource block (Figure 2).

   Finally, to complete the model, a resource pool output matrix RE(p,k)
   = {0,1} depending on whether the output from resource block p can
   reach output port k, may be used.

      I1   +-------------+                       +-------------+ O1
     ----->|             |      +--------+       |             |----->
      I2   |             +------+ Rb #1  +-------+             | O2
     ----->|             |      +--------+       |             |----->
           |             |                       |             |
           | Resource    |      +--------+       |  Resource   |
           | Pool        +------+        +-------+  Pool       |
           |             |      + Rb #2  +       |             |
           | Input       +------+        +-------|  Output     |
           | Connection  |      +--------+       |  Connection |
           | Matrix      |           .           |  Matrix     |
           |             |           .           |             |
           |             |           .           |             |
      IN   |             |      +--------+       |             | OM
     ----->|             +------+ Rb #P  +-------+             |----->
           |             |      +--------+       |             |
           +-------------+   ^               ^   +-------------+
                             |               |
                             |               |
                             |               |
                             |               |

                    Input wavelength      Output wavelength
                    constraints for       constraints for
                    each resource         each resource

   Note: Rb is a Resource Block. resource block.

           Figure 1 1: Schematic diagram Diagram of resource pool model. the Resource Pool Model
    I1   +-------------+                       +-------------+ O1
   ----->|             |      +--------+       |             |----->
    I2   |             +======+ Rb #1  +-+     |             | O2
   ----->|             |      +--------+ |     |             |----->
         |             |                 |=====|             |
         | Resource    |      +--------+ |     |  Resource   |
         | Pool        |    +-+ Rb #2  +-+     |  Pool       |
         |             |    | +--------+       |             |
         | Input       |====|                  |  Output     |
         | Connection  |    | +--------+       |  Connection |
         | Matrix      |    +-| Rb #3  |=======|  Matrix     |
         |             |      +--------+       |             |
         |             |           .           |             |
         |             |           .           |             |
         |             |           .           |             |
    IN   |             |      +--------+       |             | OM
   ----->|             +======+ Rb #P  +=======+             |----->
         |             |      +--------+       |             |
         +-------------+   ^               ^   +-------------+
                           |               |
                           |               |
                           |               |
               Single (shared) fibers for block input and output

                Input wavelength          Output wavelength
                availability for          availability for
                each block input fiber    each block output fiber

   Note: Rb is a Resource Block. resource block.

    Figure 2 2: Schematic diagram Diagram of resource pool model the Resource Pool Model with shared block
                              accessibility.

   Formally
                    Shared Block Accessibility

   Formally, the model can be specified as:

   <ResourceAccessibility> ::= <PoolInputMatrix>

                               <PoolOutputMatrix>

   <ResourceWaveConstraints> ::= <InputWaveConstraints>

                                 <OutputOutputWaveConstraints>

                                 <OutputWaveConstraints>

   <RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>]

                                        [<OutAvailableWavelengths>]
   <RBPoolState> ::=    <ResourceBlockID>

                        <NumResourcesInUse>

                        [<RBSharedAccessWaveAvailability>]

                        [<RBPoolState>]

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

5.2.  Resource Signal Constraints and Processing Capabilities

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

   <ResourceBlockInfo> ::= <ResourceBlockSet>

                           [<InputConstraints>]

                           [<ProcessingCapabilities>]

                           [<OutputConstraints>]

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

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

   <InputConstraints> ::= <SharedInput>

                          [<OpticalInterfaceClassList>]

                          [<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 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 resource, or shared fiber output
   constraint indication.

   <OutputConstraints> := <SharedOutput>

                          [<OpticalInterfaceClassList>]

                          [<ClientSignalList>]

5.3.  Compatibility and Capability Details

5.3.1.  Shared Input or Output Indication

   As discussed in the previous section Section 5.2 and shown in Figure 2 2, the input or
   output access to a resource block may be via a shared fiber.  The
   <SharedInput> and <SharedOutput> elements are indicators for this
   condition with respect to the block being described.

5.3.2.  Optical Interface Class List

      <OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ...

   The Optical Interface Class is a unique number that identifies all
   information related to optical characteristics of a physical
   interface.  The class may include other optical parameters related to
   other interface properties.  A class always includes signal
   compatibility information.

   The content of each class is out of the scope of this document and
   can be defined by other entities (e.g. (e.g., the ITU, optical equipment
   vendors, etc.).

   Since even current implementation of physical interfaces may support
   different optical characteristics, a single interface may support
   multiple interface classes.  Which optical interface class is used
   among all the ones available for an interface is out of the scope of
   this document but is an output of the RWA process.

5.3.3.  Acceptable Client Signal List

   The list is simply:

   <ClientSignalList>::=[<G-PID>]...

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

5.3.4.  Processing Capability List

   The ProcessingCapabilities were are defined in Section 5.2.

   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  number of Resources resources within the block

      2. Regeneration  regeneration capability

      3. Fault  fault and performance monitoring

      4. Vendor Specific  vendor-specific capability

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

6.  Link Information (General)

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

   In the

   The following summarize syntax summarizes both information from existing GMPLS
   route
   routing protocols and new information that maybe may be needed by the RWA
   process.

   <LinkInfo> ::=  <LinkID>

                   [<AdministrativeGroup>]

                   [<InterfaceCapDesc>]

                   [<Protection>]

                   [<SRLG>...]

                   [<TrafficEngineeringMetric>]

                   [<PortLabelRestriction>...]

   Note that these additional link characteristics only applies apply to line line-
   side ports of a WDM system or add/drop ports pertaining to Resource
   Pool the
   resource pool (e.g., Regenerator regenerator or Wavelength Converter Pool). wavelength converter pool).  The
   advertisement of input/output tributary ports is not intended here.

6.1.  Administrative Group

   Administrative Group: Defined in [RFC3630] and extended for MPLS-TE
   [RFC7308].  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], [RFC4202]; lets us know the different
   switching capabilities on this GMPLS interface.  In both [RFC4203]
   and [RFC5307] [RFC5307], this information gets combined with the maximum LSP Link
   State Protocol Data Unit (LSP) bandwidth that can be used on this
   link at eight different priority levels.

   6.3.  Link Protection Type (for this link) This Link)

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

6.4.  Shared Risk Link Group Information

   SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. [RFC4203] and
   [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 time.

6.5.  Traffic Engineering Metric

   TrafficEngineeringMetric: Defined in [RFC3630] and [RFC5305].  This
   allows for the identification of a data channel data-channel link metric value for
   traffic engineering that is separate from the metric used for path
   cost computation of the control plane.

   Note that multiple "link metric values" could find use in optical
   networks, however
   networks; however, it would be more useful to the RWA process to
   assign these specific meanings such as link mile "link mile" metric, or
   probability
   "probability of failure failure" metric, etc... etc.

6.6. Port Label Restrictions

   Port label restrictions could be applied generally to any label types
   in GMPLS by adding new kinds of restrictions.  Wavelength is a type
   of label.

   Port label (wavelength) restrictions (PortLabelRestriction) model the
   label (wavelength) restrictions that the link and various optical devices
   devices, such as OXCs, Optical Cross-Connects (OXCs), ROADMs, and waveband multiplexers
   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 (Section 4.1).  [Switch] gives an example where
   both switch and fixed connectivity matrices are used and both types
   of constraints occur on the same port.

   <PortLabelRestriction> ::= <MatrixID>

                              <RestrictionType>

                              <Restriction parameters list>

   <Restriction parameters list> ::=

                        <Simple label restriction parameters> |

                        <Channel count restriction parameters> |

                        <Label range restriction parameters> |

                        <Simple+channel restriction parameters> |

                        <Exclusive label restriction parameters>
   <Simple label restriction parameters> ::= <LabelSet> ...

   <Channel count restriction parameters> ::= <MaxNumChannels>

   <Label range restriction parameters> ::= <MaxLabelRange>

                                            (<LabelSet> ...)

   <Simple+channel restriction parameters> ::= <MaxNumChannels>

                                               (<LabelSet> ...)

   <Exclusive label restriction parameters> ::= <LabelSet> ...

   Where

   MatrixID is the ID of the corresponding connectivity matrix (section
   4.1. (Section
   4.1).

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

      SIMPLE_LABEL:   Simple label (wavelength) set restriction; The label
   set the
         LabelSet parameter is required.

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

      LABEL_RANGE:  Used to indicate a restriction on a range of labels
         that can be switched.  For example, a waveband device with a
         tunable center frequency and passband.  This constraint is
         characterized by the MaxLabelRange parameter parameter, which indicates
         the maximum range of the labels, e.g., which may represent a
         waveband in terms of channels.  Note that an additional
         parameter can be used to indicate the overall tuning range.
         Specific center frequency tuning information can be obtained
         from information about the dynamic channel in use information. use.  It is
         assumed that both center frequency and bandwidth (Q) tuning can
         be done without causing faults in existing signals.

      SIMPLE LABEL & and CHANNEL COUNT: In this case, the accompanying
         label set and MaxNumChannels indicate labels permitted on the
         port and the maximum number of labels that can be
         simultaneously used on the port.

      LINK LABEL_EXCLUSIVITY: A label (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.

   Restriction specific

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

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

      LinkSet is a conceptual set of ports.

   MaxLabelRange indicates the maximum range of the labels.  For
   example, if the port is a "colored" drop port of a ROADM ROADM, then there
   are 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 ports, Figure 3 shows a ROADM architecture
   based on components known as a Wavelength Selective Switch
   (WSS)[OFC08]. Switches (WSSes)
   [OFC08].  This ROADM is composed of splitters, combiners, and WSSes.
   This ROADM has 11 output ports, which are numbered in the diagram.
   Output ports 1-8 are known as drop ports and are intended to support
   a single wavelength.  Drop ports 1-4 output from WSS #2, 2, which is fed
   from WSS #1 1 via a single fiber.  Due to this internal
   structure structure, a
   constraint is placed on the output ports 1-4 that a lambda can be only
   used only once over the group of ports (assuming uni-
   cast unicast and not multi-cast
   multicast operation). Similarly the  The output 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 3: A ROADM composed Composed from splitter, combiners, Splitter, Combiners, and WSSs. WSSes

7.  Dynamic Components of the Information Model

   In the previously presented information model 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
   model, it may be possible to send this dynamic information separate separately
   from the relatively larger amount of static information needed to
   characterize WSON's WSONs and their network elements.

7.1.  Dynamic Link Information (General)

   For WSON links links, the wavelength availability and which wavelengths are
   in use for shared backup purposes can be considered dynamic
   information and hence are grouped with the dynamic information in the
   following set:

   <DynamicLinkInfo> ::=  <LinkID>

                          <AvailableLabels>

                          [<SharedBackupLabels>]

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

   SharedBackupLabels is a set of labels (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 potentially be used with other technologies that GMPLS
   currently covers or may cover in the future.

   Note that the above does not dictate a particular encoding or
   placement for available label information.  In some routing protocols
   protocols, it may be advantageous or required to place this
   information within another information element such as the interface switching
   capability descriptor Interface
   Switching Capability Descriptor (ISCD).  Consult the extensions that
   are specific to each routing protocol specific
   extensions for details of placement of
   information elements.

7.2.  Dynamic Node Information (WSON Specific)

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

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

8.  Security Considerations

   This document discussed discusses an information model for RWA computation in
   WSONs. Such  From a security standpoint, such a model is very similar from a security standpoint of to
   the information that can be currently conveyed via GMPLS routing
   protocols.  Such information includes network topology, link state
   and current utilization, and as well as the capabilities of switches and
   routers within the network.  As such 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.  A general discussion on
   security in GMPLS networks can be found in [RFC5920].

9. IANA Considerations

   This informational document does not make any requests for IANA
   action.

10. Acknowledgments

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

11.  References

   11.1.

9.1.  Normative References

   [G.7715] ITU-T Recommendation G.7715, Architecture  ITU-T, "Architecture and requirements for routing in the
             automatically switched optical
             networks, networks", ITU-T
             Recommendation G.7715, June 2002.

   [RBNF]   A.    Farrel, "Reduced A., "Routing Backus-Naur Form (RBNF) (RBNF): A Syntax Used
             to Form Encoding Rules in Various Routing Protocol
             Specifications", RFC 5511, April 2009. 2009,
             <http://www.rfc-editor.org/info/rfc5511>.

   [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Functional Description", RFC
             3471, January 2003. 2003,
             <http://www.rfc-editor.org/info/rfc3471>.

   [RFC3630] Katz, van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., Kompella, K., and D. Yeung, "Traffic Engineering
             (TE) Extensions to OSPF Version 2", RFC 3630, September
             2003.

   [RFC5305] T. Li,
             and H. SMIT, "Intermediate System to Intermediate
             System (IS-IS) Extensions P. Gentric, "RTP Payload Format for Traffic Engineering (TE)", Transport of MPEG-4
             Elementary Streams", RFC 5305, October 2008. 3640, November 2003,
             <http://www.rfc-editor.org/info/rfc3640>.

   [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005 2005,
             <http://www.rfc-editor.org/info/rfc4202>.

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005. 2005,
             <http://www.rfc-editor.org/info/rfc4203>.

   [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Extensions for G.709 Optical
             Transport Networks Control", RFC 4328, January 2006. 2006,
             <http://www.rfc-editor.org/info/rfc4328>.

   [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
             Engineering", RFC 5305, October 2008,
             <http://www.rfc-editor.org/info/rfc5305>.

   [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 5307, October 2008. 2008,
             <http://www.rfc-editor.org/info/rfc5307>.

   [RFC6163] Y. Lee, G. Y., Ed., Bernstein, G., Ed., and W. Imajuku,
             "Framework for GMPLS and
             PCE Path Computation Element (PCE)
             Control of Wavelength Switched Optical Networks", Networks (WSONs)",
             RFC 6163, April 2011. 2011,
             <http://www.rfc-editor.org/info/rfc6163>.

   [RFC7308] E. Osborne, E., "Extended Administrative Groups in MPLS
             Traffic Engineering (MPLS-TE)", RFC 7308, July 2014.

   11.2. 2014,
             <http://www.rfc-editor.org/info/rfc7308>.

9.2.  Informative References

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

   [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010,
             <http://www.rfc-editor.org/info/rfc5920>.

   [Shared] G.  Bernstein, G., and Y. Lee, "Shared Backup Mesh Protection
             in PCE-based WSON Networks", iPOP 2008.

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

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

12.

Contributors

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

   Phone: +39 010 600 3736
   Email:
   EMail: diego.caviglia@(marconi.com, ericsson.com)

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

   Email:

   EMail: Anders.Gavler@acreo.se

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

   Email:

   EMail: Jonas.Martensson@acreo.se

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

   Phone: +81 44 396 3287
   Email:
   EMail: i-nishioka@cb.jp.nec.com

   Lyndon Ong
   Ciena
   Email:
   EMail: lyong@ciena.com

   Cyril Margaria
   Email:
   EMail: cyril.margaria@gmail.com

Authors' Addresses

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

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

   Young Lee (ed.) (editor)
   Huawei Technologies
   5369 Legacy Drive, Building 3
   Plano, TX  75023
   USA
   United States

   Phone: (469) 277-5838
   Email:
   EMail: leeyoung@huawei.com

   Greg M. Bernstein (editor)
   Grotto Networking
   Fremont, CA
   United States

   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
   China

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

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

   Phone: +81-(46) 859-4315
   Email:
   EMail: imajuku.wataru@lab.ntt.co.jp

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 http://www.ietf.org/ipr

   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 ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
   HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

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