GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7446

Internet Engineering Task Force (IETF) Y. Lee, Ed. Request for Comments: 7446 Huawei Category: Informational G. Bernstein, Ed. ISSN: 2070-1721 Grotto Networking

                                                                 D. Li
                                                                Huawei
                                                            W. Imajuku
                                                                   NTT
                                                         February 2015
        Routing and Wavelength Assignment Information Model
              for Wavelength Switched Optical Networks

Abstract

 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 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 Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7446.

Lee, et al. Informational [Page 1] RFC 7446 WSON Information Model February 2015

Copyright Notice

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

Lee, et al. Informational [Page 2] RFC 7446 WSON Information Model February 2015

1. Introduction

 The purpose of the WSON information model described in this document
 is to facilitate constrained optical path computation, and as such it
 is not a general-purpose network management information model.  This
 constraint is frequently referred to as the "wavelength continuity"
 constraint, and the corresponding constrained optical path
 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 [RFC6163].  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.  The portion of the information model applicable
 to 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), WSON, and 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

Lee, et al. Informational [Page 3] RFC 7446 WSON Information Model February 2015

 Note that this is roughly the categorization used in Section 7 of
 [G.7715].
 In the following, where applicable, the Reduced Backus-Naur 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, there is a difference between information that can
 change with each successive connection establishment in the network
 and 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.
 This allows 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.  These
 connectivity matrices are included with the node 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.

Lee, et al. Informational [Page 4] RFC 7446 WSON Information Model February 2015

 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 input ports and
 wavelengths could possibly be connected to a particular output port.
 For a switch or ROADM, representing blocking that is dependent on the
 internal state is beyond the scope of this document.  Due to its
 highly 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)

 As discussed in [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

Lee, et al. Informational [Page 5] RFC 7446 WSON Information Model February 2015

 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
 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], a WSON node
 can also include WDM switches 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, 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 is a collection of resources from the same WSON node
 that are grouped together for administrative reasons and for ease of
 encoding in the protocols.  All resources in the same resource block
 behave in the same way and have similar characteristics relevant to
 the optical 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.

Lee, et al. Informational [Page 6] RFC 7446 WSON Information Model February 2015

 A resource block may be present in multiple resource pools.
 This leads to the following formal high-level model:
 <Node_Information> ::= <Node_ID>
                        [<ConnectivityMatrix>...]
                        [<ResourcePool>]
 Where
 <ResourcePool> ::= <ResourceBlockInfo>...
                   [<ResourceAccessibility>...]
                   [<ResourceWaveConstraints>...]
                   [<RBPoolState>]
 First, the accessibility of resource blocks is addressed; then, their
 properties are discussed.

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 [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, 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 model is shown schematically in Figures 1 and 2.  The
 difference between the two figures is that in Figure 1 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
 that imposes its own wavelength collision constraint.  Figure 1 shows
 that there can be more than one input to each resource block since
 each input represents a single wavelength signal, while Figure 2
 shows a single WDM input or output, e.g., a fiber, to/from each set
 of blocks.

Lee, et al. Informational [Page 7] RFC 7446 WSON Information Model February 2015

 This model assumes N input ports (fibers), P resource blocks
 containing one or more identical resources (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, 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), 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, and the case of shared access to a set of blocks is
 modeled via a dynamic wavelength set mechanism.
 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 is 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 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.

Lee, et al. Informational [Page 8] RFC 7446 WSON Information Model February 2015

    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.
         Figure 1: Schematic Diagram of the Resource Pool Model

Lee, et al. Informational [Page 9] RFC 7446 WSON Information Model February 2015

  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.
  Figure 2: Schematic Diagram of the Resource Pool Model with
                  Shared Block Accessibility
 Formally, the model can be specified as:
 <ResourceAccessibility> ::= <PoolInputMatrix>
                             <PoolOutputMatrix>
 <ResourceWaveConstraints> ::= <InputWaveConstraints>
                               <OutputWaveConstraints>
 <RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>]
                                      [<OutAvailableWavelengths>]

Lee, et al. Informational [Page 10] RFC 7446 WSON Information Model February 2015

 <RBPoolState> ::=    <ResourceBlockID>
                      <NumResourcesInUse>
                      [<RBSharedAccessWaveAvailability>]
                      [<RBPoolState>]
 Note that, except for <RBPoolState>, all the components of
 <ResourcePool> are relatively static.  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 for
 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 <OutputWaveConstraints>
 previously discussed.  As discussed in [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, the
 constraints are applied to the entire network element.
 The <InputConstraints> are constraints are based on signal
 compatibility and/or shared access constraint indication.  The
 details of these constraints are defined in 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 5.3.

Lee, et al. Informational [Page 11] RFC 7446 WSON Information Model February 2015

 <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 output
 constraint indication.
 <OutputConstraints> := <SharedOutput>
                        [<OpticalInterfaceClassList>]
                        [<ClientSignalList>]

5.3. Compatibility and Capability Details

5.3.1. Shared Input or Output Indication

 As discussed in Section 5.2 and shown in Figure 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., 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.

Lee, et al. Informational [Page 12] RFC 7446 WSON Information Model February 2015

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 G-PID values as defined in [RFC3471] and
 [RFC4328].

5.3.4. Processing Capability List

 The ProcessingCapabilities 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 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 [RFC3630] and IS-IS
 [RFC5305], along with GMPLS routing protocol extensions for OSPF
 [RFC4203] and IS-IS [RFC5307] provide the bulk of the relatively
 static link information needed by the RWA process.  However, WSONs
 bring in additional link-related constraints.  These stem from
 characterizing WDM line systems, restricting laser transmitter
 tuning, and switching subsystem port wavelength constraints, e.g.,
 "colored" ROADM drop ports.
 The following syntax summarizes both information from existing GMPLS
 routing protocols and new information that may be needed by the RWA
 process.

Lee, et al. Informational [Page 13] RFC 7446 WSON Information Model February 2015

 <LinkInfo> ::=  <LinkID>
                 [<AdministrativeGroup>]
                 [<InterfaceCapDesc>]
                 [<Protection>]
                 [<SRLG>...]
                 [<TrafficEngineeringMetric>]
                 [<PortLabelRestriction>...]
 Note that these additional link characteristics only apply to line-
 side ports of a WDM system or add/drop ports pertaining to the
 resource pool (e.g., regenerator or 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]; lets us know the different
 switching capabilities on this GMPLS interface.  In both [RFC4203]
 and [RFC5307], this information gets combined with the maximum 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)

 Protection: Defined in [RFC4202] and implemented in [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] 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.

Lee, et al. Informational [Page 14] RFC 7446 WSON Information Model February 2015

6.5. Traffic Engineering Metric

 TrafficEngineeringMetric: Defined in [RFC3630] and [RFC5305].  This
 allows for the identification of a 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, it would be more useful to the RWA process to
 assign these specific meanings such as "link mile" metric,
 "probability of failure" metric, 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, such as Optical Cross-Connects (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).  [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>

Lee, et al. Informational [Page 15] RFC 7446 WSON Information Model February 2015

 <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).
 The RestrictionType parameter is used to specify general port
 restrictions and matrix-specific restrictions.  It can take the
 following values and meanings:
    SIMPLE_LABEL:   Simple label (wavelength) set restriction; the
       LabelSet parameter is required.
    CHANNEL_COUNT: The number of channels is restricted to be less
       than or equal to the 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, 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.  It is
       assumed that both center frequency and bandwidth (Q) tuning can
       be done without causing faults in existing signals.

Lee, et al. Informational [Page 16] RFC 7446 WSON Information Model February 2015

    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 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, 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, Figure 3 shows a ROADM architecture
 based on components known as Wavelength Selective 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, which is fed
 from WSS 1 via a single fiber.  Due to this internal structure, a
 constraint is placed on the output ports 1-4 that a lambda can be
 used only once over the group of ports (assuming unicast and not
 multicast operation).  The output ports 5-8 have a similar constraint
 due to the internal structure.

Lee, et al. Informational [Page 17] RFC 7446 WSON Information Model February 2015

                          |               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 WSSes

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 separately
 from the relatively larger amount of static information needed to
 characterize WSONs and their network elements.

Lee, et al. Informational [Page 18] RFC 7446 WSON Information Model February 2015

7.1. Dynamic Link Information (General)

 For WSON 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, one can also determine which wavelengths are currently
 in use.  This parameter could 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 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, it may be advantageous or required to place this
 information within another information element such as the Interface
 Switching Capability Descriptor (ISCD).  Consult the extensions that
 are specific to each routing protocol 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, and it can be isolated into a dynamic node
 information element as follows:
 <DynamicNodeInfo> ::=  <NodeID> [<ResourcePool>]

8. Security Considerations

 This document discusses an information model for RWA computation in
 WSONs.  From a security standpoint, such a model is very similar to
 the information that can be currently conveyed via GMPLS routing
 protocols.  Such information includes network topology, link state
 and current utilization, as well as the capabilities of switches and

Lee, et al. Informational [Page 19] RFC 7446 WSON Information Model February 2015

 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.  A general discussion on
 security in GMPLS networks can be found in [RFC5920].

9. References

9.1. Normative References

 [G.7715]  ITU-T, "Architecture and requirements for routing in the
           automatically switched optical networks", ITU-T
           Recommendation G.7715, June 2002.
 [RBNF]    Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
           to Form Encoding Rules in Various Routing Protocol
           Specifications", RFC 5511, April 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,
           <http://www.rfc-editor.org/info/rfc3471>.
 [RFC3630] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
           and P. Gentric, "RTP Payload Format for Transport of MPEG-4
           Elementary Streams", RFC 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,
           <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,
           <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,
           <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>.

Lee, et al. Informational [Page 20] RFC 7446 WSON Information Model February 2015

 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
           in Support of Generalized Multi-Protocol Label Switching
           (GMPLS)", RFC 5307, October 2008,
           <http://www.rfc-editor.org/info/rfc5307>.
 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
           "Framework for GMPLS and Path Computation Element (PCE)
           Control of Wavelength Switched Optical Networks (WSONs)",
           RFC 6163, April 2011,
           <http://www.rfc-editor.org/info/rfc6163>.
 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
           Traffic Engineering (MPLS-TE)", RFC 7308, July 2014,
           <http://www.rfc-editor.org/info/rfc7308>.

9.2. Informative References

 [OFC08]   Roorda, P., and B. Collings, "Evolution to Colorless and
           Directionless ROADM Architectures", Optical Fiber
           Communication / National Fiber Optic Engineers Conference
           (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]  Bernstein, G., and Y. Lee, "Shared Backup Mesh Protection
           in PCE-based WSON Networks", iPOP 2008.
 [Switch]  Bernstein, G., Lee, 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 2009, pp.
           187-195.

Lee, et al. Informational [Page 21] RFC 7446 WSON Information Model February 2015

Contributors

 Diego Caviglia
 Ericsson
 Via A. Negrone 1/A 16153
 Genoa, Italy
 Phone: +39 010 600 3736
 EMail: diego.caviglia@(marconi.com, ericsson.com)
 Anders Gavler
 Acreo AB
 Electrum 236
 SE - 164 40 Kista
 Sweden
 EMail: Anders.Gavler@acreo.se
 Jonas Martensson
 Acreo AB
 Electrum 236
 SE - 164 40 Kista
 Sweden
 EMail: Jonas.Martensson@acreo.se
 Itaru Nishioka
 NEC Corp.
 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666
 Japan
 Phone: +81 44 396 3287
 EMail: i-nishioka@cb.jp.nec.com
 Lyndon Ong
 Ciena
 EMail: lyong@ciena.com
 Cyril Margaria
 EMail: cyril.margaria@gmail.com

Lee, et al. Informational [Page 22] RFC 7446 WSON Information Model February 2015

Authors' Addresses

 Young Lee (editor)
 Huawei Technologies
 5369 Legacy Drive, Building 3
 Plano, TX  75023
 United States
 Phone: (469) 277-5838
 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
 China
 Phone: +86-755-28973237
 EMail: danli@huawei.com
 Wataru Imajuku
 NTT Network Innovation Labs
 1-1 Hikari-no-oka, Yokosuka, Kanagawa
 Japan
 Phone: +81-(46) 859-4315
 EMail: imajuku.wataru@lab.ntt.co.jp

Lee, et al. Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7446.txt · Last modified: 2015/02/12 18:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki