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

                                                      February 23,
                                                                  J. Han
                                                                  Huawei
                                                               June 2015

              General Network Element Constraint Encoding
                     for GMPLS Controlled GMPLS-Controlled Networks

             draft-ietf-ccamp-general-constraint-encode-20.txt

Abstract

   Generalized Multiprotocol Label Switching (GMPLS) can be used to
   control a wide variety of technologies.  In some of these
   technologies, network elements and links may impose additional
   routing constraints such as asymmetric switch connectivity, non-local
   label assignment, and label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability.  It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.

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

Internet-Draft General Network Element Constraint Encoding February
2015

   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 June 23, 2015.
   http://www.rfc-editor.org/info/rfc7579.

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.

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. Node Switching Asymmetry Constraints......................4 Constraints .......................4
      1.2. Non-Local Non-local Label Assignment Constraints....................4 Constraints .....................5
      1.3. Conventions Used in This Document ..........................5
   2. Encoding.......................................................5 Encoding ........................................................5
      2.1. Connectivity Matrix Field.................................5 Field ..................................6
      2.2. Port Label Restriction Field..............................7 Restrictions Field ..............................7
           2.2.1. SIMPLE_LABEL.........................................8 SIMPLE_LABEL ........................................9
           2.2.2. CHANNEL_COUNT........................................9 CHANNEL_COUNT .......................................9
           2.2.3. LABEL_RANGE..........................................9

Internet-Draft General Network Element Constraint Encoding February
2015 LABEL_RANGE ........................................10
           2.2.4. SIMPLE_LABEL & CHANNEL_COUNT........................10 CHANNEL_COUNT .......................10
           2.2.5. Link Label Exclusivity..............................10 LINK_LABEL_EXCLUSIVITY .............................11
      2.3. Link Set Field...........................................11 Field ............................................11
      2.4. Available Labels Field...................................13 Field ....................................13
      2.5. Shared Backup Labels Field...............................14 Field ................................14
      2.6. Label Set Field..........................................14
         2.6.1. Inclusive/Exclusive Label Lists.....................15
         2.6.2. Inclusive/Exclusive Label Ranges....................16
         2.6.3. Bitmap Label Set....................................17 Field ...........................................15
   3. Security Considerations.......................................17 Considerations ........................................17
   4. IANA Considerations...........................................18 Considerations ............................................18
   5. Acknowledgments...............................................18
   APPENDIX A: References .....................................................18
      5.1. Normative References ......................................18
      5.2. Informative References ....................................19
   Appendix A. Encoding Examples....................................19 Examples .....................................20
      A.1. Link Set Field...........................................19 Field ............................................20
      A.2. Label Set Field..........................................19 Field ...........................................20
      A.3. Connectivity Matrix......................................20 Matrix .......................................21
      A.4. Connectivity Matrix with Bi-directional Symmetry.........23 Bidirectional Symmetry ...........25
      A.5. Priority Flags in Available/Shared Backup Labels.........25
   6. References....................................................27
      6.1. Normative References.....................................27
      6.2. Informative References...................................28
   7. Contributors..................................................29 Labels ..........27
   Contributors ......................................................27
   Authors' Addresses...............................................30 Addresses ................................................29

1.  Introduction

   Some data plane data-plane technologies that wish to make use of a GMPLS control
   plane contain additional constraints on switching capability and
   label assignment.  In addition, some of these technologies must
   perform non-local label assignment based on the nature of the
   technology, e.g., wavelength continuity constraint in Wavelength
   Switched Optical Networks (WSON) (WSONs) [RFC6163].  Such constraints can
   lead to the requirement for link by link link-by-link label availability in path
   computation and label assignment.

   This document provides efficient encodings of information needed by
   the routing and label assignment process in technologies such as WSON
   and are potentially applicable to a wider range of technologies.
   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).

Internet-Draft General Network Element Constraint Encoding February
2015

1.1.  Node Switching Asymmetry Constraints

   For some network elements, the ability of a signal or packet on a
   particular input port to reach a particular output port may be
   limited. In addition,  Additionally, in some network elements (e.g., a simple
   multiplexer), the connectivity between some input ports and output ports
   may be fixed, e.g., a
   simple multiplexer. fixed.  To take into account such constraints during path
   computation, we model this aspect of a network element via a
   connectivity matrix.

   The connectivity matrix (ConnectivityMatrix) represents either the
   potential connectivity matrix for asymmetric switches 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 labels (e.g.,
   wavelengths) could possibly be connected to a particular output port
   and label pair.  Representing internal state dependent state-dependent blocking for a
   node is beyond the scope of this document and, due to its highly
   implementation-dependent nature, would most likely not be subject to
   standardization in the future.  The connectivity matrix is a
   conceptual M*m by N*n matrix where M represents the number of input
   ports each (each with m labels labels) and N the number of output ports each (each
   with n labels. labels).

1.2. Non-Local  Non-local Label Assignment Constraints

   If the nature of the equipment involved in a network results in a
   requirement for non-local label assignment, we can have constraints
   based on limits imposed by the ports themselves and those that are
   implied by the current label usage.  Note that constraints such as
   these only become important when label assignment has a non-local
   character.  For example, in MPLS MPLS, an LSR may have a limited range of
   labels available for use on an output port, port and a set of labels
   already in use on that port, and hence port; these are therefore unavailable for use.
   This information, however, does not need to be shared unless there is
   some limitation on the LSR's label swapping ability.  For example, if
   a TDM Time Division Multiplexer (TDM) node lacks the ability to perform
   time-slot interchange, interchange or a WSON lacks the ability to perform
   wavelength conversion, then the label assignment process is not local
   to a single node.  In this case, it may be advantageous to share the
   label assignment constraint information for use in path computation.

   Port label restrictions (PortLabelRestriction) model the label
   restrictions that the network element (node) and link may impose on a
   port.  These restrictions tell us what labels may or may not be

Internet-Draft General Network Element Constraint Encoding February
2015 used
   on a link and are intended to be relatively static.  More dynamic
   information is contained in the information on available labels.
   Port label restrictions are specified relative to the port in general
   or to a specific connectivity matrix for increased modeling
   flexibility. Reference  [Switch] gives an example where both switch and fixed
   connectivity matrices are used and both types of constraints occur on
   the same port.

1.3.  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].

2.  Encoding

   This section provides encodings for the information elements 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 element defined by this document will be defined in the
   respective protocol enhancement documents.

2.1.  Connectivity Matrix Field

   The Connectivity Matrix Field represents how input ports are
   connected to output ports for network elements.  The switch and fixed
   connectivity matrices can be compactly represented in terms of a
   minimal list of input and output port set pairs that have mutual
   connectivity.  As described in [Switch], such a minimal list
   representation leads naturally to a graph representation for path
   computation purposes that purposes; this representation involves the fewest
   additional nodes and links.

   The Connectivity Matrix Field is uniquely identified only by the
   advertising node.  There may be more than one Connectivity Matrix
   Field associated with a node as a node can partition the switch
   matrix into several sub-
   matrices. sub-matrices.  This partitioning is primarily to
   limit the size of any individual information element used to
   represent the matrix and to enable incremental updates.  When the
   matrix is partitioned into sub-
   matrices, sub-matrices, each sub-matrix will be
   mutually exclusive to one another in representing which ports/labels
   are associated with each sub-
   matrix. sub-matrix.  This implies that two matrices
   will not have the same {src port, src label, dst port, dst label}.

Internet-Draft General Network Element Constraint Encoding February
2015

   Each sub-matrix is identified via a different Matrix ID which that MUST
   represent a unique combination of {src port, src label, dst port, dst
   label}.

   A TLV encoding of this list of link set pairs 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Conn  |   MatrixID    |            Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Set A #1                         |
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Set B #1                         :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Additional Link set pairs Set Pairs as needed Needed           |
      :                     to specify connectivity Specify Connectivity                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
   Where:

   Connectivity (Conn) (4 bit) bits) is the device type.

      0 -- - the device is fixed

      1 -- - the device is switched (e.g., ROADM/OXC) Reconfigurable Optical Add/Drop
          Multiplexer / Optical Cross-Connect (ROADM/OXC))

   MatrixID represents the ID of the connectivity matrix and is an 8
   bit 8-bit
   integer.  The value of 0xFF is reserved for use with port label
   constraints and should not be used to identify a connectivity matrix.

   Link Set A #1 and Link Set B #1 together represent a pair of link
   sets.  See Section 2.3. 2.3 for a detail detailed description of the link set
   field. Link Set
   Field.  There are two permitted combinations for the link set field Link Set Field
   parameter "dir" for Link Set link set A and B pairs:

   o  Link Set A dir=input, Link Set B dir=output

      In this case, the meaning of the pair of link sets A and B in this
     case is that
      any signal that inputs a link in set A can be potentially switched
      out of an output link in set B.

Internet-Draft General Network Element Constraint Encoding February
2015

   o  Link Set A dir=bidirectional, Link Set B dir=bidirectional

      The

      In this case, the meaning of the pair of link sets A and B in this case is that
      any signal that inputs on the links in set A can potentially
      output on a link in set B, B and any input signal on the links in set
      B can potentially output on a link in set A.  If link set A is an
      input and link set B is an output for a signal, then it implies
      that link set A is an output and link set B is an input for that
      signal.

   See Appendix A for both types of encodings as applied to a ROADM
   example.

2.2.  Port Label Restriction Restrictions Field

   The Port Label Restriction Restrictions Field tells us what labels may or may not
   be used on a link.

   The port label restriction restrictions can be encoded as follows: follows.  More than one
   of these fields may be needed to fully specify a complex port
   constraint.  When more than one of these fields are is present, the
   resulting restriction is the union of the restrictions expressed in
   each field.  The use of the reserved value of 0xFF for the MatrixID
   indicates that a restriction applies to the port, port and not to a
   specific connectivity matrix.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MatrixID    |    RstType    |  SwitchingCap Switching Cap |     Encoding  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Additional Restriction Parameters per Restriction Type    |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   MatrixID: either is the value in the corresponding Connectivity
   Matrix field Field or takes the value 0xFF to indicate the restriction
   applies to the port regardless of any Connectivity Matrix. connectivity matrix.

   RstType (Restriction Type) can take the following values and
   meanings:

Internet-Draft General Network Element Constraint Encoding February
2015

      0: SIMPLE_LABEL (Simple label selective restriction; restriction).  See
         Section 2.2.1 for details) details.

      1: CHANNEL_COUNT (Channel count restriction; restriction).  See Section 2.2.2
         for details) details.

      2: LABEL_RANGE (Label range device with a movable center label and width;
         width).  See Section 2.2.3 for details) details.

      3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL and
         CHANNEL_COUNT restriction.  The accompanying label set and
         channel count indicate labels permitted on the port and the
         maximum number of channels that can be simultaneously used on
         the port; port).  See Section 2.2.4 for details) details.

      4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once
         amongst a set of specified ports; ports).  See Section 2.2.5 for
         details)

   SwitchingCap
         details.

   Switching Cap (Switching Capability) is defined in [RFC4203] [RFC4203], and LSP
   Encoding Type is defined in [RFC3471].  The combination of these
   fields defines the type of labels used in specifying the port label
   restrictions as well as the interface type to which these
   restrictions apply.

   The Additional Restriction Parameters per RestrictionType field is an
   optional field that describes additional restriction parameters for
   each RestrictionType pertaining to specific protocols.

2.2.1.  SIMPLE_LABEL

   In the case of the SIMPLE_LABEL, The the format is given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 0   |  SwitchingCap Switching Cap |   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Label Set Field                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case case, the accompanying label set indicates the labels
   permitted on the port/matrix.

   See Section 2.6 for the definition of label set.

Internet-Draft General Network Element Constraint Encoding February
2015

2.2.2.  CHANNEL_COUNT

   In the case of the CHANNEL_COUNT, the format is given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 1   | SwitchingCap   |Switching Cap  |   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MaxNumChannels                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case case, the accompanying MaxNumChannels indicates the maximum
   number of channels (labels) that can be simultaneously used on the
   port/matrix.

   MaxNumChannels is a 32-bit integer.

2.2.3.  LABEL_RANGE

   In the case of the LABEL_RANGE, the format is given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 2   | Switching Cap |  Encoding     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MaxLabelRange                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Label Set Field                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is a generalization of the waveband device.  The MaxLabelRange
   indicates the maximum width of the waveband in terms of the channels
   spacing given in the Label Set Field.  The corresponding label set is
   used to indicate the overall tuning range.

   MaxLabelRange is a 32-bit integer.

   See Section 2.6.2 for the an explanation of label range.

Internet-Draft General Network Element Constraint Encoding February
2015

2.2.4.  SIMPLE_LABEL & CHANNEL_COUNT

   In the case of the SIMPLE_LABEL & CHANNEL_COUNT CHANNEL_COUNT, the format is given
   by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 3   |  SwitchingCap Switching Cap |   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MaxNumChannels                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Label Set Field                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case 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.

   See Section 2.6 for the definition of label set.

2.2.5.                         Link Label Exclusivity  LINK_LABEL_EXCLUSIVITY

   In the case of the Link Label Exclusivity Exclusivity, the format is given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 4   |  SwitchingCap Switching Cap |   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Link Set Field                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case case, the accompanying link set indicates that a label may be
   used at most once among the ports in the link set field. Link Set Field.

   See Section 2.3 for the definition of link set.

Internet-Draft General Network Element Constraint Encoding February
2015

2.3.  Link Set Field

   We will frequently need to describe properties of groups of links.
   To do so efficiently efficiently, we can make use of a link set concept similar
   to the label set concept of [RFC3471]. This  The Link Set Field is used in
   the <ConnectivityMatrix>, which is defined in Section 2.1.  The
   information carried in a Link Set link set 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     |Dir|  Format   |         Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier 1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier N                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Action: 8 bits

      0 - Inclusive List

          Indicates that one or more link identifiers are included in
          the Link
   Set. link set.  Each identifies a separate link that is part of
          the set.

      1 - Inclusive Range

          Indicates that the Link Set link set defines a range of links.  It
          contains two link identifiers.  The first identifier indicates
          the start of the range.  The second identifier indicates the
          end of the range.  All links with numeric values between the
          bounds are considered to be part of the set.  A value of zero
          in either position indicates that there is no bound on the
          corresponding portion of the range.  Note that the Action
          field can be set to 0x01 (Inclusive Range) only when the
          identifier for unnumbered link is used.

   Dir: Directionality of the Link Set link set (2 bits)

      0 -- - bidirectional

      1 -- - input

Internet-Draft General Network Element Constraint Encoding February
2015

      2 -- - output

   For example, in

      In optical networks networks, we think in terms of unidirectional
   as well as and
      bidirectional links.  For example, label restrictions or
      connectivity may be different for an input port, port than for its
      "companion" output port port, if one exists.  Note that "interfaces"
      such as those discussed in the Interfaces MIB [RFC2863] are
      assumed to be bidirectional.  This also applies to the links
      advertised in various link state routing protocols.

   Format: The format of the link identifier (6 bits)

      0 -- - Link Local Identifier

          Indicates that the links in the Link Set link set are identified by
          link local identifiers.  All link local identifiers are
          supplied in the context of the advertising node.

      1 -- - Local Interface IPv4 Address

          Indicates that the links in the link set are identified by
          Local Interface IPv4 Address.

      2 -- - Local Interface IPv6 Address

          Indicates that the links in the Link Set link set are identified by
          Local Interface IP IPv6 Address.

      Others -- - Reserved for future use. use
      Note that all link identifiers in the same list must be of the
      same type.

   Length: 16 bits

      This field indicates the total length in bytes of the Link Set field.
      Field.

   Link Identifier: length is dependent on the link format

      The link identifier represents the port which that is being described
      either for connectivity or for label restrictions.  This can be
      the link local identifier of [RFC4202], GMPLS routing, [RFC4203] routing [RFC4202], GMPLS OSPF
   routing,
      routing [RFC4203], and [RFC5307] IS-IS GMPLS routing. routing [RFC5307].  The use of
      the link local identifier format can result in more compact
      encodings when the assignments are done in a reasonable fashion.

Internet-Draft General Network Element Constraint Encoding February
2015

2.4.  Available Labels Field

   The Available Labels Field consists of priority flags, flags and a single
   variable length label set field
   variable-length Label Set 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     PRI       |              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   Where:

   PRI (Priority Flags, 8 bits): A bitmap used to indicate which
   priorities are being advertised.  The bitmap is in ascending order,
   with the leftmost bit representing priority level 0 (i.e., the
   highest) and the rightmost bit representing priority level 7 (i.e.,
   the lowest).  A bit MUST be set (1) corresponding to each priority
   represented in the sub-TLV, sub-TLV and MUST NOT be set (0) when the
   corresponding priority is not represented.  If a label is available
   at priority M M, it MUST be advertised available at each priority N <
   M.  At least one priority level MUST be advertised.

   The PRI field indicates the availability of the labels for use in
   LSP set up
   Label Switched Path (LSP) setup and pre-emption preemption as described in
   [RFC3209].

   When a label is advertised as available for priorities 0, 1, ... M M,
   it may be used by any LSP of priority N <= M.  When a label is in use
   by an LSP of priority M M, it may be used by an LSP of priority N < M
   if LSP preemption is supported.

   When a label was initially advertised as available for priorities, priorities 0,
   1, ... M and once a label is used for an LSP at a priority, say N
   (N<=M), then this label is advertised as available for 0, ... N-1.

   Note that the Label Set Field is defined in Section 2.6.  See
   Appendix
   A.5. A.5 for illustrative examples.

Internet-Draft General Network Element Constraint Encoding February
2015

2.5.  Shared Backup Labels Field

   The Shared Backup Labels Field consists of priority flags, flags and a
   single variable length label set field variable-length Label Set 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     PRI         |            Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   Where:

   PRI (Priority Flags, 8 bits): A bitmap used to indicate which
   priorities are being advertised.  The bitmap is in ascending order,
   with the leftmost bit representing priority level 0 (i.e., the
   highest) and the rightmost bit representing priority level 7 (i.e.,
   the lowest).  A bit MUST be set (1) corresponding to each priority
   represented in the sub-TLV, sub-TLV and MUST NOT be set (0) when the
   corresponding priority is not represented.  If a label is available
   at priority M M, it MUST be advertised available at each priority N <
   M.  At least one priority level MUST be advertised.

   The same LSP set up setup and pre-emption preemption rules specified in Section 2.4
   apply here.

   Note that Label Set Field is defined in Section 2.6.  See
   Appendix
   A.5. A.5 for illustrative examples.

2.6.  Label Set Field

   The Label Set Field is used within the <AvailableLabels> Available Labels Field or the
   <SharedBackupLabels>, which is
   Shared Backup Labels Field, defined in Sections 2.4. 2.4 and 2.5., 2.5,
   respectively. It is also used within the <SIMPLE_LABEL>,
   <LABEL_RANGE>, <SIMPLE_LABEL> SIMPLE_LABEL, LABEL_RANGE, or <CHANNEL_COUNT>, which is
   SIMPLE_LABEL & CHANNEL_COUNT, defined in Sections 2.1.1. - 2.1.4., 2.2.1, 2.2.3, and
   2.2.4, respectively.

   The general format for a label set is given below.  This format uses
   the Action concept from [RFC3471] with an additional Action to define
   a "bit map" "bitmap" type of label set.  Labels are variable in length.
   Action specific
   Action-specific fields are defined below.

Internet-Draft General Network Element Constraint Encoding February
2015 in Sections 2.6.1, 2.6.2, and
   2.6.3.

      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|    Num Labels = N       |           Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Base Label                           |
     |                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      (Action specific                      (Action-specific fields)                 |
     |                              . . . .                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Action:

      0 - Inclusive List

      1 - Exclusive List

      2 - Inclusive Range

      3 - Exclusive Range

      4 - Bitmap Set

   Num Labels is generally the number of labels.  It has a specific
   meaning depending on the action Action value.  See Sections 2.6.1 - 2.6.1, 2.6.2,
   and 2.6.3 for details.  Num Labels is a 12 bit 12-bit integer.

   Length is the length in bytes of the entire label set field. Label Set Field.

2.6.1.  Inclusive/Exclusive Label Lists

   In the case of the

   For inclusive/exclusive lists (Action = 0 or 1), the wavelength set
   format is given by:

Internet-Draft General Network Element Constraint Encoding February
2015 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 or 1 | Num Labels = 2        |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Label #1                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Label #N                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   Label #1 is the first Label label to be included/excluded included/excluded, and Label #N is
   the last Label label to be included/excluded.  Num Labels MUST match
   with N.

2.6.2.  Inclusive/Exclusive Label Ranges

   In the case of

   For inclusive/exclusive ranges (Action = 2 or 3), the label set
   format is
   given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |2 or 3 | Num Labels          |               Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Start Label                                |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     End Label                                 |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that Start Label is the first Label label in the range to be
   included/excluded
   included/excluded, and End Label is the last label in the same range.
   Num Labels MUST be two.

Internet-Draft General Network Element Constraint Encoding February
2015

2.6.3.  Bitmap Label Set

   In the case of Action = 4, the

   For bitmap sets (Action = 4), the label set format is given
   by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  4    |   Num Labels          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Base Label                            |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Bit Map    Bitmap Word #1 (Lowest numerical labels)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Bit Map    Bitmap Word #N (Highest numerical labels)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   In this case, Num Labels in this case tells us the number of labels represented by
   the bit map. bitmap.  Each bit in the bit map bitmap represents a particular label
   with a value of 1/0 indicating whether or not the label is in the set or not.
   set.  Bit position zero represents the lowest label and corresponds
   to the base label, while each succeeding bit position represents the
   next label logically above the previous.

   The size of the bit map bitmap is Num Labels bits, but the bit map bitmap is padded
   out to a full multiple of 32 bits so that the field is a multiple of
   four bytes.  Bits that do not represent labels (i.e.,
   those in positions (Num Labels) and beyond) SHOULD be set to zero
   and MUST be ignored.

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

Internet-Draft General Network Element Constraint Encoding February
2015
   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].

4.  IANA Considerations

   This document provides general protocol independent protocol-independent information
   encodings.  There is no IANA allocation request for the information
   elements defined in this document.  IANA allocation requests will be
   addressed in protocol specific protocol-specific documents based on the encodings
   defined here.

5. Acknowledgments

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

Internet-Draft General Network Element Constraint Encoding February
2015

Internet-Draft General Network Element Constraint Encoding February
2015

6.  References

     6.1.

5.1.  Normative References

   [G.694.1]  ITU-T, "Spectral grids for WDM applications: DWDM
              frequency grid", ITU-T Recommendation G.694.1, February
              2012.

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

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000. 2000,
              <http://www.rfc-editor.org/info/rfc2863>.

   [RFC3209]  Awduche, D., et al. Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001. 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

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

   [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
             applications: DWDM frequency grid", June, 2002. 2003,
              <http://www.rfc-editor.org/info/rfc3471>.

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

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

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

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

Internet-Draft General Network Element Constraint Encoding February
2015

     6.2. 2011,
              <http://www.rfc-editor.org/info/rfc6205>.

5.2.  Informative References

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

   [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 Path Computation Element (PCE)
              Control of Wavelength Switched Optical Networks (WSONs)",
              RFC 6163, DOI 10.17487/RFC6163, April 2011. 2011,
              <http://www.rfc-editor.org/info/rfc6163>.

   [RFC7446]  Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku,
              "Routing and Wavelength Assignment Information Model for
              Wavelength Switched Optical Networks", RFC 7446,
              DOI 10.17487/RFC7446, February 2015,
              <http://www.rfc-editor.org/info/rfc7446>.

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

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

APPENDIX A: 187-195, June 2009.

Appendix A.  Encoding Examples

   Here we give

   This appendix contains examples of the general encoding extensions
   applied to some simple ROADM network elements and links.

A.1.  Link Set Field

   Suppose that we wish to describe a set of input ports that are have link
   local identifiers number numbered 3 through 42.  In the link set field Link Set Field, we
   set the Action = 1 to denote an inclusive range; the range, Dir = 1 to denote input links; and, the
   links, and Format = 0 to denote link local identifiers. In particular  Thus, we
   have:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Action=1     |0 1|0 0 0 0 0 0|             Length = 12       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Link Local Identifier = #3                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Link Local Identifier = #42               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.  Label Set Field

   Example:

   A 40 channel

   In this example, we use a 40-channel C-Band DWDM Dense Wavelength Division
   Multiplexing (DWDM) system with 100GHz 100 GHz spacing with lowest frequency 192.0THz (1561.4nm)
   192.0 THz (1561.4 nm) and highest frequency 195.9THz
   (1530.3nm). 195.9 THz (1530.3 nm).
   These frequencies correspond to n = -11, -11 and n = 28 28, respectively.
   Now suppose the following channels are available:

   Frequency (THz)       n Value      bit map      bitmap position
   --------------------------------------------------
      192.0             -11                  0
      192.5              -6                  5
      193.1               0                 11
      193.9               8                 19
      194.0               9                 20
      195.2              21                 32
      195.8              27                 38
   Using the label format defined in [RFC6205], with the Grid value set
   to indicate an ITU-T A/2 [G.694.1] DWDM grid, grid and C.S. set to indicate
   100GHz
   100 GHz, this lambda bit map bitmap set would then be encoded as follows:

Internet-Draft General Network Element Constraint Encoding February
2015

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  4    | Num Labels = 40       |    Length = 16 bytes          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = -11 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0 0 0 0 0 1 0|   Not used in 40 Channel system (all zeros)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   To encode this same set as an inclusive list list, we would have:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0    | Num Labels = 7        |    Length = 32 bytes          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = -11 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = -6  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = -0  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = 8   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = 9   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = 21  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |      Reserved   | n  for lowest frequency = 27  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3.  Connectivity Matrix

   Example:

   Suppose we have a typical 2-degree 40 channel 40-channel ROADM.  In addition to
   its two line side ports ports, it has 80 add and 80 drop ports.  The picture

Internet-Draft General Network Element Constraint Encoding February
2015 figure
   below illustrates how a typical 2-degree ROADM system that works with bi-directional
   bidirectional fiber pairs is a highly asymmetrical system composed of
   two unidirectional ROADM subsystems.

                         (Tributary) Ports #3-#42
                     Input added to    Output dropped from
                     West Line Output    East Line Input
                           vvvvv          ^^^^^
                          | |||.|        | |||.|
                    +-----| |||.|--------| |||.|------+
                    |    +----------------------+     |
                    |    |                      |     |
        Output      |    | Unidirectional ROADM |     |    Input
   -----------------+    |                      |     +--------------
   <=====================|                      |===================<
   -----------------+    +----------------------+     +--------------
                    |                                 |
        Port #1     |                                 |   Port #2
   (West Line Side) |                                 |(East Line Side)
   -----------------+    +----------------------+     +--------------
   >=====================|                      |===================>
   -----------------+    | Unidirectional ROADM |     +--------------
          Input     |    |                      |     |    Output
                    |    |              _       |     |
                    |    +----------------------+     |
                    +-----| |||.|--------| |||.|------+
                          | |||.|        | |||.|
                           vvvvv          ^^^^^
                     (Tributary) Ports #43-#82
                Output dropped from    Input added to
                West Line Input      East Line Output

   Referring to the figure above, we see that the Input direction of
   ports #3-
   #42 #3-#42 (add ports) can only connect to the output on port #1. While #1
   while the Input side of port #2 (line side) can only connect to the
   output on ports #3-#42 (drop) and to the output on port #1 (pass
   through).  Similarly, the input direction of ports #43-#82 can only
   connect to the output on port #2 (line). While (line) while the input direction of
   port #1 can only connect to the output on ports #43-#82 (drop) or
   port #2 (pass through).  We can now represent this potential
   connectivity matrix as follows.  This representation uses only 29
   32-bit words.

Internet-Draft General Network Element Constraint Encoding February
2015

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Conn = 1   |    MatrixID   |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Note: adds to line
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |0 1|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #3                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #42               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line to drops
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |1 0|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #3                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #42               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line to line
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Note: adds to line
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |0 1|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #43               |

Internet-Draft General Network Element Constraint Encoding February
2015
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #82               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line to drops
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 1|0 0 0 0 0 0||          Length = 8          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |1 0|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #43               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #82               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line to line
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.  Connectivity Matrix with Bi-directional Bidirectional Symmetry

   If one has the ability to renumber the ports of the previous example
   as shown in the next figure figure, then we can take advantage of the bi-
   directional
   bidirectional symmetry and use bi-directional bidirectional encoding of the
   connectivity matrix.  Note that we set dir=bidirectional in the link
   set fields.

Internet-Draft General Network Element Constraint Encoding February
2015 Link
   Set Fields.

                                (Tributary)
                     Ports #3-42         Ports #43-82
                     West Line Output    East Line Input
                           vvvvv          ^^^^^
                          | |||.|        | |||.|
                    +-----| |||.|--------| |||.|------+
                    |    +----------------------+     |
                    |    |                      |     |
        Output      |    | Unidirectional ROADM |     |    Input
   -----------------+    |                      |     +--------------
   <=====================|                      |===================<
   -----------------+    +----------------------+     +--------------
                    |                                 |
        Port #1     |                                 |   Port #2
   (West Line Side) |                                 |(East Line Side)
   -----------------+    +----------------------+     +--------------
   >=====================|                      |===================>
   -----------------+    | Unidirectional ROADM |     +--------------
        Input     |    |                      |     |    Output
                    |    |              _       |     |
                    |    +----------------------+     |
                    +-----| |||.|--------| |||.|------+
                          | |||.|        | |||.|
                           vvvvv          ^^^^^
                     Ports #3-#42            Ports #43-82
                Output dropped from    Input added to
                West Line Input      East Line Output

Internet-Draft General Network Element Constraint Encoding February
2015
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Conn = 1   |    MatrixID   |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Add/Drops
                   Note: Add/Drop #3-42 to Line side #1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |0 0|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #3                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #42               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line #2 to add/drops #43-82
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=1     |0 0|0 0 0 0 0 0|          Length = 12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #43               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #82               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: line to line
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Local Identifier = #2                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5.  Priority Flags in Available/Shared Backup Labels

   If one wants to make a set of labels (indicated by Label Set Field
   #1) available only for the highest priority level (Priority Level 0)

Internet-Draft General Network Element Constraint Encoding February
2015
   while allowing a set of labels (indicated by Label Set Field #2) to
   be available to all priority levels, the following encoding will
   express such need.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0 0 0 0 0 0 0|              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field #1                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 1 1 1 1|              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field #2                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Internet-Draft General Network Element Constraint Encoding February
2015

7.

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

   Rao Rajan
   Infinera

   Email:
   EMail: rrao@infinera.com

   Giovanni Martinelli
   CISCO

   Email:
   Cisco
   EMail: giomarti@cisco.com

   Remi Theillaud

Internet-Draft General Network Element Constraint Encoding February
2015
   Marben
   EMail: remi.theillaud@marben-products.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
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA
   United States
   Phone: (972) 509-5599 (x2240)
   Email:
   EMail: ylee@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

Internet-Draft General Network Element Constraint Encoding February
2015

   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