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

                                                      February 24,
                                                                  J. Han
                                                                  Huawei
                                                               June 2015

       Routing and Wavelength Assignment Information Encoding for
                  Wavelength Switched Optical Networks

                  draft-ietf-ccamp-rwa-wson-encode-28.txt

Abstract

   A wavelength switched optical network Wavelength Switched Optical Network (WSON) requires that certain key
   information fields are be made available to facilitate path computation
   and the establishment of label switching paths Label Switched Paths (LSPs).  The
   information model described in "Routing and Wavelength Assignment
   Information Model for Wavelength Switched Optical Networks" (RFC
   7446) shows what information is required at specific points in the
   WSON.  Part of the WSON information model contains aspects that may
   be of general applicability to other technologies, while other parts
   are specific to WSONs.

   This document provides efficient, protocol-agnostic encodings for the
   WSON-specific information fields.  It is intended that protocol-
   specific documents will reference this memo to describe how
   information is carried for specific uses.  Such encodings can be used
   to extend GMPLS signaling and routing protocols.  In addition addition, these
   encodings could be used by other mechanisms to convey this same
   information to a path computation element Path Computation Element (PCE).

Status of this This Memo

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

   Internet-Drafts are working documents an Internet Standards Track document.

   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 documents
   at any time.  It the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work available in progress."

   The list 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 August 24, 2015.
   http://www.rfc-editor.org/info/rfc7581.

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.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

   1. Introduction...................................................3 Introduction ....................................................4
      1.1. Terminology..................................................4 Terminology ................................................4
      1.2. Conventions Used in This Document ..........................5
   2. Resources, Resource Blocks, and the Resource Pool..............4 Pool ...............5
      2.1. Resource Block Set Field..................................5 Field ...................................5
   3. Resource Accessibility/Availability............................6 Accessibility/Availability .............................7
      3.1. Resource Accessibility Field..............................6 Field ...............................7
      3.2. Resource Wavelength Constraints Field.....................8 Field ......................9
      3.3. Resource Block Pool State (RBPoolState) Field.............9 Field ...........................10
      3.4. Resource Block Shared Access Wavelength
           Availability
      (RBSharedAccessWaveAvailability) Field........................11 Field ........................................12
   4. Resource Block Information (ResourceBlockInfo) Field..........12 Field ...............................13
      4.1. Optical Interface Class List Subfield....................14 Subfield .....................15
           4.1.1. ITU-G.698.1 ITU-T G.698.1 Application Code Mapping.............16 Mapping .............17
           4.1.2. ITU-G.698.2 ITU-T G.698.2 Application Code Mapping.............18 Mapping .............18
           4.1.3. ITU-G.959.1 ITU-T G.959.1 Application Code Mapping.............19
             ITU-G.695 Mapping .............20
           4.1.4. ITU-T G.695 Application Code Mapping.....................22
            4.1.4...................................................22 Mapping ...............22
      4.2. Acceptable Client Signal List Subfield................24 Subfield ....................23
      4.3. Input Bit Rate List Subfield..........................24 Subfield ..............................24
      4.4. Processing Capability List Subfield...................25 Subfield .......................24
   5. Security Considerations.......................................27 Considerations ........................................26
   6. IANA Considerations...........................................27 Considerations ............................................26
      6.1. Types for subfields Subfields of WSON Resource Block Information...27 Information ....26
   7. Acknowledgments...............................................28
   APPENDIX A: References .....................................................27
      7.1. Normative References ......................................27
      7.2. Informative References ....................................28
   Appendix A. Encoding Examples....................................29 Examples .....................................30
      A.1. Wavelength Converter Accessibility Field.................29 Field ..................30
      A.2. Wavelength Conversion Range Field........................31 Field .........................32
      A.3. An OEO Switch with DWDM Optics...........................31
   8. References....................................................35
      8.1. Normative References.....................................35
      8.2. Informative References...................................35
   9. Contributors..................................................37 Optics ............................32
   Contributors ......................................................35
   Authors' Addresses...............................................38 Addresses ................................................37

1.  Introduction

   A Wavelength Switched Optical Network (WSON) is a Wavelength Division
   Multiplexing (WDM) optical network in which switching is performed
   selectively based on the center wavelength of an optical signal.

   [RFC6163] describes a framework for Generalized Multiprotocol Label
   Switching (GMPLS) and Path Computation Element (PCE) control of a
   WSON.  Based on this framework, [RWA-Info] [RFC7446] describes an information
   model that specifies what information is needed at various points in
   a WSON in order to compute paths and establish Label Switched Paths
   (LSPs).

   This document provides efficient encodings of information needed by
   the routing Routing and wavelength assignment Wavelength Assignment (RWA) process in a WSON.  Such
   encodings can be used to extend GMPLS signaling and routing
   protocols.  In addition addition, these encodings could be used by other
   mechanisms to convey this same information to a path computation
   element (PCE). PCE.  Note that since
   these encodings are efficient efficient, they can provide more accurate
   analysis of the control plane control-plane communications/processing load for
   WSONs looking to utilize a GMPLS control plane.

   In parallel to this document, [Gen-Encode] [RFC7579] provides efficient encodings
   of information needed by the routing and label assignment process
   that are potentially applicable to a wider range of technologies.

1.1.  Terminology

   Refer to [RFC6163] for CWDM, DWDM, RWA, WDM. definitions of the following:

   o  Coarse Wavelength Division Multiplexing (CWDM)

   o  Dense Wavelength Division Multiplexing (DWDM)

   o  Routing and Wavelength Assignment (RWA)

   o  Wavelength Division Multiplexing (WDM)

   Refer to Section 5 of [RWA-Info] [RFC7446] for definitions of the terminology following:

   o  resource

   o  resource block

   o  resource pool
   The Optical Interface (OI) Code Point is a unique number that
   identifies all information related to optical characteristics of Resources,
   Resource Blocks, a
   physical interface.

1.2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and Resource Pool. "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Resources, Resource Blocks, and the Resource Pool

   This section provides encodings for the information fields defined in [RWA-Info]
   [RFC7446] that have applicability to WSON.  The encodings are
   designed to be suitable for use in the GMPLS routing protocols OSPF
   [RFC4203] and IS-IS [RFC5307] and in the PCE protocol Communication Protocol
   (PCEP) [RFC5440].  Note that the information distributed in [RFC4203]
   and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and TLVs;
   this document defines elements to be used within such constructs.
   Specific constructs of sub-TLVs and the nesting of sub-TLVs of the
   information field fields defined by this document will be defined in the
   respective protocol enhancement documents.

   This document defines the following information fields pertaining to
   resources within an optical node:

     .

   o  Resource Accessibility <ResourceAccessibility>

     .

   o  Resource Wavelength Constraints <ResourceWaveConstraints>

     .

   o  Resource Block Pool State <RBPoolState>
     .

   o  Resource Block Shared Access Wavelength Availability
      <RBSharedAccessWaveAvailability>

     .

   o  Resource Block Information <ResourceBlockInfo>

   Each of these information fields works with one or more sets of
   resources rather than just a single resource block.  This motivates
   the following field definition. definition in Section 2.1.

2.1.  Resource Block Set Field

   In a WSON node that includes resource blocks (RB), (RBs), denoting subsets
   of these blocks allows one to efficiently describe common properties
   of the blocks and to describe the structure and characteristics, if
   non-trivial,
   nontrivial, of the resource pool.  The RB Resource Block Set field (RB Set)
   Field is defined in a similar manner to the label set concept of
   [RFC3471].

   The information carried in an RB set field Set Field is defined by: as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action     |C|  Reserved   |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        RB Identifier 1                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        RB Identifier n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Action: 8 bits

      0 - Inclusive List

          Indicates that the TLV contains one or more RB elements that
          are included in the list.

      1 - Inclusive Range(s)

          Indicates that the TLV contains one or more ranges of RBs.
          Each individual range is denoted by two 32-bit RB identifier. identifiers.
          The first 32 bits is the RB identifier for the start of the range
          range, and the next 32 bits is the RB identifier for the end
          of the range.  Note that the Length field is used to determine
          the number of ranges.

   C (Connectivity bit): bit)

      Set to 0 to denote fixed (possibly multi-
   cast) connectivity; Set multicast) connectivity, and
      set to 1 to denote potential (switched) connectivity.  Used in
      Resource Accessibility field.  Ignored elsewhere.

   Reserved: 7 bits

      This field is reserved.  It MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Length: 16 bits

      The total length of this field in bytes.

   RB Identifier:

      The RB identifier represents the ID of the resource block block, which
      is a
   32 bit 32-bit integer.  The scope of the RB identifier is local to
      the node on which it is applied.

   Usage Note: the The inclusive range "Action" can result in very compact
   encoding of resource sets sets, and it can be advantageous to number
   resource blocks in such a way so that status updates (dynamic
   information) can take advantage of this efficiency.

3.  Resource Accessibility/Availability

   This section defines the information fields for dealing with
   accessibility and availability of resource blocks within a pool of
   resources.  These include the ResourceAccessibility,
   ResourceWaveConstraints, <ResourceAccessibility>,
   <ResourceWaveConstraints>, <RBPoolState>, and RBPoolState
   <RBSharedAccessWaveAvailability> fields.

3.1.  Resource Accessibility Field

   This information field describes the structure of the resource pool
   in relation to the switching device.  In particular particular, it indicates the
   ability of an input port to reach sets of resources and the ability
   of sets of resources to reach a particular output port.  This is the
   PoolInputMatrix
   <PoolInputMatrix> and PoolOutputMatrix <PoolOutputMatrix> of [RWA-Info]. [RFC7446].

   The Resource Accessibility field is defined by: as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Reserved(8bits)|C|             Reserved (23 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Link Set Field A #1                  |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RB Set Field A #1                    |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Additional Link set and RB set pairs as needed to     |
      :                    specify PoolInputMatrix                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output Link Set Field B #1                     |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             RB Set B Field #1 (for output connectivity)       |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Additional Link Set and RB set pairs as needed to     |
      :                    specify PoolOutputMatrix                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   Where:

   C (Connectivity bit): Connectivity indicates how the input/output
      ports connect to the resource blocks.

      0 -- - the device is fixed (e.g., a connected port must go through
          the resource block)

      1 -- - the device is switched (e.g., a port can be configured to go
          through a resource but isn't required)

   For the Input and Output Link Set Fields, the Link Set Field encoding
   defined in [Gen-Encode] [RFC7579] is to be used. A Label Set Field
   MUST carry a label as defined in [RFC6205].

   Note that the direction parameter within the Link Set Field is used
   to indicate whether the link set is an input or output link set, and
   the bidirectional value for this parameter is not permitted in this
   field.

   See Appendix A.1 for an illustration of this encoding.

3.2.  Resource Wavelength Constraints Field

   Resources, such as wavelength converters, etc., may have limited
   input or output wavelength ranges.  Additionally, due to the
   structure of the optical system system, not all wavelengths can necessarily
   reach or leave all the resources.  These properties are described by
   using one or more resource wavelength restrictions Resource Wavelength Constraints fields as defined
   below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|B|                      Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Input Wavelength Constraints                   |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output Wavelength Constraints                  |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I = (Input):

      1 - indicates the presence of the Input Wavelength Constraints
   Field and I =
          field

      0 - indicates otherwise.

   O = (Output):

      1 - indicates the presence of the Output Wavelength Constraints
   Field and O =
          field

      0 - indicates otherwise.

   B = (Both):

      1 - indicates that a single wavelength constraints Wavelength Constraints field
          represents both Input and Output Wavelength Constraints Fields.

   Currently
          fields.

   Currently, the only valid combinations of (I,O,B) are (1,0,0),
   (0,1,0), (1,1,0), and (0,0,1).

   RB Set Field:

      A set of resource blocks (RBs) which that have the same wavelength
      restrictions.

   Input Wavelength Constraints Field: Constraints:

      Indicates the wavelength input restrictions of the RBs in the
      corresponding RB set.  This field is encoded via the Label Set field
      Field of [Gen-Encode]. [RFC7579].

   Output Wavelength Constraints Field: Constraints:

      Indicates the wavelength output restrictions of RBs in the
      corresponding RB set.  This field is encoded via the Label Set field
      Field of [Gen-Encode]. [RFC7579].

3.3.  Resource Block Pool State (RBPoolState) Field

   The state of the pool is given by the number of resources available
   with particular characteristics.  A resource block set is used to
   encode all or a subset of the resources of interest.  The usage state
   of resources within a resource block set is encoded as either a list
   of 16 bit 16-bit integer values or a bit map bitmap indicating whether a single
   resource is available or in use.  The bit map bitmap encoding is appropriate
   when resource blocks consist of a single resource.  This information
   can be relatively dynamic, i.e., can change when a connection (LSP (LSP)
   is established or torn down.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Action        |    Reserved                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  RB Usage state State                               |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   Where:

   Action = 0 denotes a list of 16 bit integers 16-bit integers, and Action = 1 denotes
   a bit map. bitmap.  Action = 0 covers the case where there are multiple
   elements for each resource block.  Action = 1 covers the case where
   each resource block only contains a single element.

   In both cases cases, the elements of the RB Set field Field are in a one-to-one
   correspondence with the values in the usage RB usage state Usage State area.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Action = 0    |    Reserved                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  RB#1 state State   |      RB#2 state State               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 RB#n-1 state State  |   RB#n state State or Padding       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RB#i State (16 bits, unsigned integer): indicates  Indicates the number of
      resources available in Resource Block #i.

   Whether the last 16 bits is a wavelength converter (RB) state or
   padding is determined by the number of elements in the RB set field. Set Field.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Action = 1    |    Reserved                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  RB Usage state bitmap State Bitmap                        |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ......             |      Padding bits Bits    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RB Usage state: State Bitmap:  Variable Length length but must be a multiple of 4 byes.
   bytes.

   Each bit indicates the usage status of one RB with 0 indicating the
   RB is available and 1 indicating the RB is in use.  The sequence of
   the bit map bitmap is ordered according to the RB Set field Field with this
   element.

   Padding bits: Variable Length length

3.4.  Resource Block Shared Access Wavelength Availability
   (RBSharedAccessWaveAvailability) Field

   Resource blocks may be accessed via a shared fiber.  If this is the
   case, then wavelength availability on these shared fibers is needed
   to understand resource availability.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|B|                        Reserved                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Input Available Wavelength Set Field               |
      :                          (Optional)                           :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Output Available Wavelength Set Field             |
      :                          (Optional)                           :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I = (Input):

      1 or 0 - indicates the presence or of the Input Available Wavelength Set
          Field.

      0 - indicates the absence of the Input Available Wavelength Set Field
          Field.

   O = (Output):

      1 or 0 - indicates the presence or of the Output Available Wavelength Set
          Field.

      0 - indicates the absence of the Output Available Wavelength Set
          Field.

   B = (Both):

      1 - indicates that a single Available Wavelength Set Field
          represents both Input and Output Available Wavelength Set
          Fields.

   Currently

   Currently, the only valid combinations of (I,O,B) are (1,0,0),
   (0,1,0), (1,1,0), and (0,0,1).

   RB Set Field:

      A Resource Block resource block set in which all the members share the same input
      or output fiber or both.

   Input Available Wavelength Set Field:

      Indicates the wavelengths currently available (not being used) on
      the input fiber to this resource block.  This field is encoded via
      the Label Set field Field of [Gen-Encode]. [RFC7579].

   Output Available Wavelength Set Field:

      Indicates the wavelengths currently available (not being used) on
      the output fiber from this resource block.  This field is encoded
      via the Label Set field Field of [Gen-Encode]. [RFC7579].

4.  Resource Block Information (ResourceBlockInfo) Field

   As defined in [RWA-Info], [RFC7446], the Resource Block Information
   <ResourceBlockInfo> field is used to represent resource signal
   constraints and processing capabilities of a node.

   The fundamental properties of a resource block are:

     (a)

   o  Optical Interface Class List(s)
     (b)

   o  Acceptable Client Signal (shared input, modulation, FEC, Forward Error
      Correction (FEC), bit rate, G-PID)
     (c) and Generalized Protocol Identifier
      (G-PID))

   o  Input Bit Rate
     (d)

   o  Processing Capabilities (number of resources in a block,
      regeneration, performance monitoring, vendor specific)

   ResourceBlockInfo

   <ResourceBlockInfo> fields are used to convey relatively static
   information about individual resource blocks blocks, including the resource
   block properties and the number of resources in a block.

   When more than one ResourceBlockInfo <ResourceBlockInfo> field is used, there are no
   ordering requirements amongst these fields.  The length of the
   ResourceBlockInfo
   <ResourceBlockInfo> field is determined from the length of the object
   that includes it.

   This ResourceBlockInfo

   The <ResourceBlockInfo> field has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RB Set Field                         |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|B|                       Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Optional subfield Subfield 1                    |
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Optional subfield Subfield N                    |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RB Set Field is described in Section 2.1.

   The shared input or output indication is indicated by the first bit
   (I), the second bit (O) (O), and the third bit (B): (B).

   I = (Input):

      1 - indicates if the resource blocks identified in the RB set
   field Set
          Field utilized a shared fiber for input access and and I = access.

      0 - indicates otherwise.

   O = (Output):

      1 - indicates if the resource blocks identified in the RB set
   field Set
          Field utilized a shared fiber for output access and O = access.

      0 - indicates otherwise.

   B = (Both):

      1 - indicates if the resource blocks identified in the RB set
   field Set
          Field utilized a shared fiber for both input and output access and B
   =
          access.

      0 - indicates otherwise.

   Currently

   Currently, the only valid combinations of (I,O,B) are (1,0,0),
   (0,1,0), (1,1,0), and (0,0,1).

   Zero or more Optional subfields Subfields MAY be present.  Optional subfields Subfields
   have the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field defines the length of the value portion in bytes
   (thus
   (thus, a subfield with no value portion would have a length of zero).
   The subfield is padded to four-byte 4-byte alignment; padding is not included
   in the Length field (so a three byte 3-byte value would have a length of three,
   but the total size of the subfield would be eight
   byte). 8 bytes).  Unrecognized
   types are not processed.  If multiple subfields of the same type are
   present, only the first of the type SHOULD be processed.

   The following subfield Types sub-TLV types are defined:

      Value          Length      Sub-TLV Type

       1             variable    Optical Interface Class List
       2             variable    Acceptable Client Signal List
       3             variable    Input Bit Rate List
       4             variable    Processing Capability List

   See the IANA Considerations section for allocation of new Types. types.

4.1.  Optical Interface Class List Subfield

   The Optical Interface Class List subfield has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                        |I|O|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Optical Interface Classes                   |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The following I and O combination are defined:

   I   O
   -----
   0   0   Invalid

   1   0   Optical Interface Class List acceptable in input

   0   1   Optical Interface Class List available in output

   1   1   Optical Interface Class List available on both input and
           output.

   The Resource Block resource block MAY contain one or more lists according to the
   input/output flags.

   The Optical Interface Classes format is defined as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|     Reserved                |    OI Code Points             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Optical Interface Class                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Optical Interface Class  (Cont.)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the first 32 bits of the encoding shall be used to identify the
   semantics of the Optical Interface Class in the following way:

   S  Standard bit.

              S=0, identify (Standard bit):

      S=0: identifies non-ITU code points

              S=1, identify

      S=1: identifies ITU application codes

   With S=0, the OI Code Points field can take the following value:

      0: reserved

   Future work may add support for vendor-specific AI application codes
   once the ITU-T has completed its work in that area.

   With S=1, the OI Code Points field can take the following values:

      0: reserved

      1: [G.698.1] application code. code

      2: [G.698.2] application code. code

      3: [G.959.1] application code. code

      4: [G.695] application code. code

   In the case of ITU Application Codes, application codes, the mapping between the string
   defining the application code and the 64 bits implementing the
   optical interface class is given in the following sections.

4.1.1. ITU-G.698.1  ITU-T G.698.1 Application Code Mapping

      [698.1]

   [G.698.1] defines the Application Codes: following application codes: DScW-ytz(v) and B-DScW-
      ytz(v).
   B-DScW-ytz(v).  Where:

      B: means Bidirectional. Bidirectional

      D: means a DWDM application. application

      S: takes values N (narrow spectral excursion), excursion) or W (wide spectral
   excursion).
         excursion)

      c: Channel Spacing (GHz). (GHz)

      W: takes values S (short-haul), (short-haul) or L (long-haul). (long-haul)

      y: takes values 1 (NRZ 2.5G), 2.5G) or 2 (indicating NRZ 10G). (NRZ 10G)

      t: only D value is defined (link does not contain optical
         amplifier)

      z: takes values 2 ([G.652] fibre), 3 ([G.653] fibre), or 5
   (indicating [G.655] fibre).
         ([G.655] fibre)

      v: takes values S (Short wavelength), C (Conventional), or L (Long
   wavelength).
         wavelength)

   The F flag indicates the presence or absence of an optional FEC
   Encoding
   encoding suffix.

   These get mapped into the 64 bit OIC 64-bit Optical Interface Class field as
   follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  D  |S|   c   |   W   |   y   |   t   |   z   |  v  |   F   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where values (values between parentheses refer to ITU defined ITU-defined values as
   reported above: above):

      B: = 1 bidirectional, 0 otherwise

      D (prefix): = 0 reserved, = 1 (D)

      S: = 0 (N), = 1 (W)

      c: Channel Spacing, 4 bits mapped according to the same definition
         as in Figure 2 the third figure in Section 3.2 of [RFC6205] (note that
         DWDM spacing applies here) here).

      W: = 0 reserved, = 2 (S), = 3 (L)

      y: = 0 reserved, = 1 (1), = 2 (2)

      t: = 0 reserved, = 4 (D)

      z: = 0 reserved, = 2 (2), = 3 (3), = 5 (5)

      v: = 0 reserved, = 1 (S), = 2 (C), = 3 (L)

      F (suffix): = 0 No FEC Encoding encoding suffix present, = 1 FEC
   Encoding encoding
         suffix present

   Values not mentioned here are not allowed in this application code;
   the last 32 bits are reserved and shall be set to zero.

4.1.2. ITU-G.698.2  ITU-T G.698.2 Application Code Mapping

   [G.698.2] defines the Application Codes: following application codes: DScW-ytz(v) and B-DScW-
   ytz(v).
   B-DScW-ytz(v).  Where:

      B: means Bidirectional. Bidirectional

      D: means a DWDM application. application
      S: takes values N (narrow spectral excursion), excursion) or W (wide spectral
   excursion).
         excursion)

      c: Channel Spacing (GHz). (GHz)

      W: takes values C (link is dispersion compensated), compensated) or U (link is
         dispersion uncompensated). uncompensated)

      y: takes values 1 (NRZ 2.5G), 2.5G) or 2 (indicating NRZ 10G). (NRZ 10G)

      t: takes value A (link may contains optical amplifier)

      z: takes values 2 ([G.652] fibre), 3 ([G.653] fibre), or 5
   (indicating [G.655] fibre).
         ([G.655] fibre)

      v: takes values S (Short wavelength), C (Conventional), or L (Long
   wavelength).
         wavelength)

      An Optional optional F can be added indicating to indicate a FEC Encoding. encoding.

   These get mapped into the 64-bit OIC Optical Interface Class field as
   follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  D  |S|   c   |   W   |   y   |   t   |   z   |  v  |   F   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where (values between parentheses refer to ITU defined ITU-defined values as
   reported above):

      B: = 1 bidirectional, 0 otherwise

      D (prefix): = 0 reserved, = 1 (D)

      S: = 0 (N), = 1 (W)

      c: Channel Spacing, 4 bits mapped according to the same definition
         as in Figure 2 the third figure in Section 3.2 of [RFC6205] (note that
         DWDM spacing applies here) here).

      W: = 0 reserved, = 10 (C), = 11 (U)

      y: = 0 reserved, = 1 (1), = 2 (2)
      t: = 0 reserved, = 1 (A)

      z: = 0 reserved, = 2 (2), = 3 (3), = 5 (5)

      v: = 0 reserved, = 1 (S), = 2 (C), = 3 (L)

      F (suffix): = 0 reserved, = 1 FEC Encoding encoding

   Values not mentioned here are not allowed in this application
   code, the code.
   The last 32 bits are reserved and shall be set to zero.

4.1.3. ITU-G.959.1  ITU-T G.959.1 Application Code Mapping

   [G.959.1] defines the Application Codes: following application codes: PnWx-ytz and
   BnWx-ytz.  Where:

      P,B: when present present, indicate Plural or Bidirectional

      n: maximum number of channels supported by the application code
         (i.e., an integer number)

      W: takes values I (intra-office), S (short-haul), L (long-haul), V
         (very long-haul), or U (ultra long-haul). long-haul)

      x: maximum number of spans allowed within the application code
         (i.e., an integer number)

      y: takes values 1 (NRZ 2.5G), 2 (NRZ 10G), 9 (NRZ 25G), 3 (NRZ
         40G), or 7 (RZ 40G). 40G)

      t: takes values A (power levels suitable for a booster amplifier
         in the originating ONE and power levels suitable for a pre-amplifier pre-
         amplifier in the terminating ONE), B (booster amplifier only),
         C (pre-
   amplifier (pre-amplifier only), or D (no amplifiers). amplifiers)

      z: takes values 1 (1310 nm sources on [G.652] fibre), 2 (1550 nm
         sources on [G.652] fibre), 3 (1550 nm sources on [G.653]
         fibre), or 5 (1550 nm sources on [G.655] fibre).

   The following list of suffixes can be added to these application
   codes:

      F: FEC encoding. encoding

      D: Adaptive dispersion compensation. compensation

      E: receiver capable of dispersion compensation. compensation
      r: reduced target distance. distance

      a: power levels appropriate to APD receivers. receivers

      b: power levels appropriate to PIN receivers. receivers

   These values are encoded as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | p |  P  |       n           |   W   |     x     |   reserved  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   y   |   t   |   z   |   suffix  |          reserved         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where (values between parentheses refer to ITU defined ITU-defined values as
   reported above):

      p (prefix) = (prefix): 0 otherwise, = 1 Bidirectional (B)

      P (optional): = 0 not present, = 2 (P).

      n: maximum number of channels (10 bits, up to 1023 channels)

      W: = 0 reserved, = 1 (I), = 2 (S), = 3 (L), = 4 (V), = 5 (U)

      x: = number of spans (6 bits, up to 64 spans)

      y: = 0 reserved, = 1 (1), = 2 (2), = 3 (3), = 7 (7), = 9 (9)

      t: = 0 reserved, = 1 (A), = 2 (B), = 3 (C), = 4 (D)

      z: = 0 reserved, = 1 (1), = 2 (2), = 3 (3), = 5 (5)

         suffix is

      suffix: a 6-bit bitmap:

       0 1 2 3 4 5
      +-+-+-+-+-+-+
      |F|D|E|r|a|b|
      +-+-+-+-+-+-+ bitmap, where a 1 "1" in the appropriate slot
         indicates that the corresponding suffix has been added.

             0 1 2 3 4 5
            +-+-+-+-+-+-+
            |F|D|E|r|a|b|
            +-+-+-+-+-+-+

4.1.4. ITU-G.695  ITU-T G.695 Application Code Mapping

   [G.695] defines the Application Codes: CnWx-ytz and B-CnWx-ytz following application codes: CnWx-ytz,
   B-CnWx-ytz, and S-CnWx-ytz.

   Where the optional prefixes are:

      B: Bidirectional

      S: a system using a black link approach

   And the rest of the application code is defined as:

      C: CWDM (Coarse WDM) application

      n: maximum number of channels supported by the application code
         (i.e., an integer number)

      W: takes values S (short-haul), (short-haul) or L (long-haul). (long-haul)

      x: maximum number of spans allowed

      y: takes values 0 (NRZ 1.25G), 1 (NRZ 2.5G), or 2 (NRZ 10G).

      t: takes value D (link does not contain any optical amplifier).

      z: takes values 1 (1310 nm region for [G.652] fibre), 2 (ITU-T
         [G.652] fibre), 3 ([G.653] fibre), or 5 ([G.655] fibre). fibre)

   The following list of suffixes can be added to these application
   codes:

      F: FEC encoding. encoding

   Since the application codes are very similar to the ones from the
   [G.959] section
   [G.959.1] section, most of the fields are reused.  The 64-bit OIC Optical
   Interface Class field is encoded as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | p |  C  |       n           |   W   |     x     |   reserved  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   y   |   t   |   z   |   suffix  |          reserved         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Where (values between parentheses refer to ITU defined ITU-defined values as
   reported above):

      p: = 0 no prefix, = 1 B (B) bidirectional, = 2 S (S) black link

      C: = 0 reserved, = 3 (C). (C)

      n: maximum number of channels (10 bits, up to 1023 channels)

      W: = 0 reserved, = 1 reserved, = 2 (S), = 3 (L), > 3 reserved

      x: = number of spans (6 bits, up to 64 spans)

      y: = 0 (0), = 1 (1), =2 2 (2), > 2 reserved

      t: = 4 (D), all other values are reserved

      z: = 0 reserved, = 1 (1), = 2 (2), = 3 (3)

         suffix is

      suffix: a 6-bit bitmap:

       0 1 2 3 4 5
      +-+-+-+-+-+-+
      |F|0|0|0|0|0|
      +-+-+-+-+-+-+ bitmap, where a 1 "1" in the appropriate slot
         indicates that the corresponding suffix has been added.

             0 1 2 3 4 5
            +-+-+-+-+-+-+
            |F|0|0|0|0|0|
            +-+-+-+-+-+-+

4.2.  Acceptable Client Signal List Subfield

   This subfield contains a list of acceptable input client signal
   types.

   The acceptable client signal list is a list of Generalized Protocol
   Identifiers (G-PIDs).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Reserved           |       Number of G-PIDs        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            G-PID #1           |          G-PID #2             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               |                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            G-PID #N           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (16 bits):  identifies the Acceptable Client Signal List field.

   Length (16 bits): The Length field defines the length of the value
   portion in octets.

   The number
     |            G-PID #1           |          G-PID #2             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               |                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            G-PID #N           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Number of G-PIDs is G-PIDs: an integer greater than or equal to one.

   G-PIDs are

   G-PIDs: assigned by IANA and many IANA.  Many are defined in [RFC3471] and
      [RFC4328].

4.3.  Input Bit Rate List Subfield

   This subfield contains a list of bit rates of each input client
   signal type specified in the Input Client Signal List.

   The number of Input Bit Rates MUST match the number of G-PIDs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Input Bit Rate of G-PID #1                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Input Bit Rate of G-PID #N                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Input Bit Rates are in IEEE 754 floating point format [IEEE].

4.4.  Processing Capability List Subfield

   The processing capability list field Processing Capability List subfield is a list of capabilities
   that can be achieved through the referred resources:

   1.  Regeneration capability

   2.  Fault and performance monitoring

   3. Vendor specific  Vendor-specific capability

   Fault and performance monitoring and Vendor specific vendor-specific capability have
   no additional capability parameters.

   The processing capability list field Processing Capability List subfield is then given by: defined as:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Reserved           |        Processing Cap ID      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Possible additional capability parameters depending upon    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :   the processing ID                                           :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The processing capability Processing Cap ID field defines the following processing
   capabilities:

      0: Reserved

      1: Regeneration capability

      2: Fault and performance monitoring

      3: Vendor specific Vendor-specific capability

   When the processing Processing Cap ID is "regeneration "Regeneration capability", the
   following additional capability parameters are provided in the
   following field:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  T  | C |                 Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the T bit indicates the type of regenerator:

      T=0: Reserved

      T=1: 1R Regenerator

      T=2: 2R Regenerator

      T=3: 3R Regenerator

   Where
   And where the C bit indicates the capability of the regenerator:

      C=0: Reserved

      C=1: Fixed Regeneration Point

      C=2: Selective Regeneration Pools

   Note that when the capability of the regenerator is indicated to be
   Selective
   "Selective Regeneration Pools, Pools", regeneration pool properties such as
   input and output restrictions and availability need to be specified.
   These properties will be encoded in the capabilities field providing additional
   capability parameters, starting with the bits marked Reserved in the figure.
   figure immediately above.  An additional specification describing the
   encoding of these parameters is required before the value C=2 can be
   used.

5.  Security Considerations

   This document defines protocol-independent encodings for WSON
   information and does not introduce any security issues.

   However, other documents that make use of these encodings within
   protocol extensions need to consider the issues and risks associated
   with inspection, interception, modification, or spoofing of any of
   this information.  It is expected that any such documents will
   describe the necessary security measures to provide adequate
   protection.  A general discussion on security in GMPLS networks can
   be found in [RFC5920].

6.  IANA Considerations

   This document introduces a new top-level registry for GMPLS routing
   parameters for WSON encoding.  This new IANA registry will be has been
   created to make the assignment of a new type and new values for the
   new "GMPLS Routing Parameters for WSON". WSON" registry.  Note that this
   registry is only used in routing, not in signaling.

6.1.  Types for subfields Subfields of WSON Resource Block Information

   Under this the new GMPLS "GMPLS Routing Parameters for WSON, WSON" registry, a new
   IANA
   registry will be subregistry has been created for nested subfields of the
   Resource Block Information field to create a new section named "Types
   for subfields Subfields of WSON Resource Block Information Registry". The new  This
   registry will be maintained via Standards Action as defined by
   [RFC5226].

   There are

   The initial values in the new registry are as follows:

   Value      Length      Sub-TLV Type      Description                     Reference
   -----      ------      ------------                    ---------
   0                      Reserved
   1          variable    Optical Interface Class List [This.I-D]    [RFC7581]
   2          variable    Acceptable Client Signal List                  [This.I-D]   [RFC7581]
   3          variable    Input Bit Rate List          [This.I-D]             [RFC7581]
   4          variable    Processing Capability List   [This.I-D]      [RFC7581]
   5-65535                Unassigned

7. Acknowledgments

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

8.  References

8.1.

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

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

   [RFC6205]   T.  Otani, H. Guo, K. Miyazaki, T., Ed., and D. Caviglia, Li, Ed., "Generalized Labels for G.694 Lambda-Switching Capable
              Lambda-Switch-Capable (LSC) Label Switching Routers",
              RFC 6205, DOI 10.17487/RFC6205, March 2011.

   [RWA-Info]  G. Bernstein, Y. 2011,
              <http://www.rfc-editor.org/info/rfc6205>.

   [RFC7446]  Lee, D. Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku,
              "Routing and Wavelength Assignment Information Model for
              Wavelength Switched Optical Networks", work in progress: draft-ietf-
             ccamp-rwa-info.

   [Gen-Encode]   G. RFC 7446,
              DOI 10.17487/RFC7446, February 2015,
              <http://www.rfc-editor.org/info/rfc7446>.

   [RFC7579]  Bernstein, Y. G., Ed., Lee, D. Y., Ed., Li, W. D., Imajuku, W., and
              J. Han, "General Network Element Constraint Encoding for GMPLS Controlled
              GMPLS-Controlled Networks", work in progress: draft-ietf-ccamp-general-
             constraint-encode.

8.2. RFC 7579,
              DOI 10.17487/RFC7579, June 2015,
              <http://www.rfc-editor.org/info/rfc7579>.

7.2.  Informative References

   [G.652] ITU-T Recommendation G.652, Characteristics    ITU-T, "Characteristics of a single-mode optical fibre and cable, September, 2011.

   [G.653]
              cable", ITU-T Recommendation G.653, Characteristics G.652, November 2009.

   [G.653]    ITU-T, "Characteristics of a dispersion-
             shifted, single-mode dispersion-shifted, single-
              mode optical fibre and cable, July,
             2010.

   [G.655] cable", ITU-T Recommendation G.655, Characteristics G.653,
              July 2010.

   [G.655]    ITU-T, "Characteristics of a non-zero dispersion-shifted
              single-mode optical fibre and cable,
             September, 2011.

   [G.695] cable", ITU-T Recommendation G.695, Optical
              G.655, November 2009.

   [G.695]    ITU-T, "Optical interfaces for coarse wavelength division
              multiplexing applications, October,
             2010. applications", ITU-T Recommendation G.695,
              January 2015.

   [G.698.1]  ITU-T, "Multichannel DWDM applications with single-channel
              optical interfaces", ITU-T Recommendation G.698.1, Spectral grids for WDM
             applications: DWDM frequency grid, June 2002.
              November 2009.

   [G.698.2]  ITU-T, "Amplified multichannel dense wavelength division
              multiplexing applications with single channel optical
              interfaces", ITU-T Recommendation G.698.2, Spectral grids for WDM
             applications: CWDM wavelength grid, December 2003. November 2009.

   [G.959.1] ITU-T Recommendation G.959.1, Optical  ITU-T, "Optical transport network physical layer interfaces, February,
              interfaces", ITU-T Recommendation G.959.1, February 2012.

   [IEEE]     IEEE, "IEEE Standard for Binary Floating-Point
              Arithmetic", IEEE Standard 754-1985, 1985 (ISBN 1-5593-7653-8). 754.

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

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

   [RFC5226]  Narten, T., T. and H. Alvestrand, H., "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

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

   [RFC5440]  Vasseur, JP. JP., Ed., and JL. Le Roux,  JL., Eds., Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009. 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

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

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

   [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, DOI 10.17487/RFC6163, April 2011.

APPENDIX A: 2011,
              <http://www.rfc-editor.org/info/rfc6163>.

Appendix A.  Encoding Examples

A.1.  Wavelength Converter Accessibility Field

   Example:

   Figure 1 shows a wavelength converter pool architecture known as
   "shared per fiber".  In this case case, the input and output pool matrices
   are simply:

              +-----+       +-----+
              | 1 1 |       | 1 0 |
          WI =|     |,  WE =|     |
              | 1 1 |       | 0 1 |
              +-----+       +-----+

                    +-----------+                      +------+
                    |           |--------------------->|      |
                    |           |--------------------->|  C   |
              /|    |           |--------------------->|  o   |
             /D+--->|           |--------------------->|  m   |
            + e+--->|           |                      |  b   |=======>
   ========>| M|    |  Optical  |    +-----------+     |  i   | Port O1
   Port I1  + u+--->|  Switch   |    |  WC Pool  |     |  n   |
             \x+--->|           |    |  +-----+  |     |  e   |
              \|    |           +----+->|WC #1|--+---->|  r   |
                    |           |    |  +-----+  |     +------+
                    |           |    |           |     +------+
              /|    |           |    |  +-----+  |     |      |
             /D+--->|           +----+->|WC #2|--+---->|  C   |
            + e+--->|           |    |  +-----+  |     |  o   |
   ========>| M|    |           |    +-----------+     |  m   |=======>
   Port I2  + u+--->|           |                      |  b   | Port O2
             \x+--->|           |--------------------->|  i   |
              \|    |           |--------------------->|  n   |
                    |           |--------------------->|  e   |
                    |           |--------------------->|  r   |
                    +-----------+                      +------+

    Figure 1 1:  An optical switch featuring Optical Switch Featuring a shared per fiber wavelength
                       converter pool architecture. Shared Per-Fiber Wavelength
                       Converter Pool Architecture
   The wavelength converters are resource blocks and the wavelength
   converter pool is a resource block pool.  This can be encoded as
   follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved |1|                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Note: I1,I2 can connect to either WC1 or WC2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |0|  Reserved   |            Length = 12        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Link Local Identifier = #1                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Link Local Identifier = #2                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |1|  Reserved   |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           RB ID = #1                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           RB ID = #2                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Note: WC1 can only connect to O1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |1|  Reserved   |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Link Local Identifier = #1                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |0|  Reserved   |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            RB ID = #1                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Note: WC2 can only connect to O2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |1|  Reserved   |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Link Local Identifier = #2                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |0|                |            Length = 8      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            RB ID = #2                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.  Wavelength Conversion Range Field

   Example:

   This example, based on figure Figure 1, shows how to represent the
   wavelength conversion range of wavelength converters.  Suppose the
   wavelength range of input and output of WC1 and WC2 are {L1, L2, L3,
   L4}:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                             Note: WC Set
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Action=0     |1| Reserved    |     Length = 8                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           WC ID = #1          |       WC ID = #2              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Note: wavelength input range
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 2   | Num Wavelengths = 4     |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Grid |  C.S. |     Reserved    |  n for lowest frequency = 1   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Note: wavelength output range
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 2   | Num Wavelengths = 4     |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Grid |  C.S. |     Reserved    |  n for lowest frequency = 1   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3.  An OEO Switch with DWDM Optics

   Figure 2 shows an electronic switch fabric surrounded by DWDM optics.
   In this example example, the electronic fabric can handle either G.709 or SDH
   Synchronous Digital Hierarchy (SDH) signals only (2.5 or 10 Gbps).
   To describe this node, the following information in RBNF Reduced Backus-
   Naur Form (RBNF) form [RFC5511] is needed:

      <Node_Info> ::= <Node_ID>

                      [Other GMPLS info-elements]

                      [<ConnectivityMatrix>...]

                      [<ResourcePool>]

                      [<RBPoolState>]
   In this case case, there is complete port-to-port connectivity connectivity, so the
   <ConnectivityMatrix> is not required.  In addition addition, since there are
   sufficient ports to handle all wavelength signals signals, the <RBPoolState>
   element is not needed.

   Hence

   Hence, the attention will be focused on the <ResourcePool> field:

      <ResourcePool> ::= <ResourceBlockInfo>

                         [<RBAccessibility>...]

                         [<ResourceWaveConstraints>...]

              /|    +-----------+    +-------------+   +------+
             /D+--->|           +--->|Tunable Laser|-->|      |
            + e+--->|           |    +-------------+   |  C   |
   ========>| M|    |           |        ...           |  o   |=======>
   Port I1  + u+--->|           |    +-------------+   |  m   | Port O1
             \x+--->|           |--->|Tunable Laser|-->|  b   |
              \|    |  Electric |    +-------------+   +------+
                    |   Switch  |
              /|    |           |    +-------------+   +------+
             /D+--->|           +--->|Tunable Laser|-->|      |
            + e+--->|           |    +-------------+   |  C   |
   ========>| M|    |           |        ...           |  o   |=======>
   Port I2  + u+--->|           |    +-------------+   |  m   | Port O2
             \x+--->|           +--->|Tunable Laser|-->|  b   |
              \|    |           |    +-------------+   +------+
                    |           |
              /|    |           |    +-------------+   +------+
             /D+--->|           |--->|Tunable Laser|-->|      |
            + e+--->|           |    +-------------+   |  C   |
   ========>| M|    |           |        ...           |  o   |=======>
   Port I3  + u+--->|           |    +-------------+   |  m   | Port O3
             \x+--->|           |--->|Tunable Laser|-->|  b   |
              \|    +-----------+    +-------------+   +------+

                 Figure 2 2: An optical switch built Optical Switch Built around
                        an electronic switching
                                  fabric. Electronic Switching Fabric

   The resource block information will tell us about the processing
   constraints of the receivers, transmitters, and the electronic
   switch.  The resource availability information, although very simple,
   tells us that all signals must traverse the electronic fabric (fixed
   connectivity).  The resource wavelength constraints are not needed
   since there are no special wavelength constraints for the resources
   that would not appear as port/wavelength constraints.

   <ResourceBlockInfo>:

   The <ResourceBlockInfo> is encoded as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :  (only one resource block in this example with shared         |
      |                     input/output case)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|                 Reserved                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Optical Interface Class List(s)               |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Client Signal Type                   |
      :                   (G-PIDs for SDH and G.709)                  :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Bit Rate Range List                  |
      :                       (2.5Gbps, 10Gbps)                      (2.5 Gbps, 10 Gbps)                      :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Processing Capabilities List                |
      :              Fixed (non optional) 3R regeneration             :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Since there is fixed connectivity to resource blocks (the electronic
   switch)
   switch), the <RBAccessibility> is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Connectivity=0|Reserved                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Link Set Field A #1                  |
      :                    (All input links connect to resource)      :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RB Set Field A #1                    |
      :              (trivial set only one resource block)            :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output Link Set Field B #1                     |
      :                    (All output links connect to resource)     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.

Contributors

   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A 16153
   Genoa
   Italy
   Phone: +39 010 600 3736
   Email:
   EMail: diego.caviglia@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, Simonumabe
   Nakahara-ku, Kawasaki, Kanagawa 211-8666
   Japan
   Phone: +81 44 396 3287
   Email:
   EMail: i-nishioka@cb.jp.nec.com

   Pierre Peloso
   ALU

   Email:
   EMail: pierre.peloso@alcatel-lucent.com

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

   Giovanni Martinelli
   Cisco

   Email:
   EMail: giomarti@cisco.com

   Gabriele M Galimberti
   Cisco
   Email:
   EMail: ggalimbe@cisco.com
   Lyndon Ong
   Ciena Corporation
   Email:
   EMail: lyong@ciena.com

   Daniele Ceccarelli
   Ericsson
   Email:
   EMail: daniele.ceccarelli@ericsson.com

Authors' Addresses

   Greg M. Bernstein (ed.) (editor)
   Grotto Networking
   Fremont California, USA
   Fremont, California
   United States
   Phone: (510) 573-2237
   Email:
   EMail: gregb@grotto-networking.com

   Young Lee (ed.) (editor)
   Huawei Technologies
   5340 Legacy Drive Build 3
   Plano, TX 75024
   USA
   United States
   Phone: (469) 277-5838
   Email:
   EMail: leeyoung@huawei.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

   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China
   China
   Phone: +86-755-28972916
   Email:
   EMail: hanjianrui@huawei.com