Network Working Group                                      G. Bernstein
Internet Draft                                        Grotto Networking
Intended status: Standards Track                                 Y. Lee
Expires: November 2013 May 2014                                                 D. Li
                                                                 Huawei
                                                             W. Imajuku
                                                                    NTT

                                                            May 6,

                                                      November 13, 2013

     General Network Element Constraint Encoding for GMPLS Controlled
                                 Networks

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

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 6, 2013. May 13, 2012.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Internet-Draft  General Network Element Constraint Encoding    November
2013

   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.

Abstract

   Generalized Multiprotocol Label Switching 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.

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
      1.1. Node Switching Asymmetry Constraints......................4
      1.2. Non-Local Label Assignment Constraints....................4
      1.3. Change Log................................................5
   2. Encoding.......................................................6 Encoding.......................................................5
      2.1. Link Set Field............................................6 Connectivity Matrix Field.................................5
      2.2. Port Label Set Field...........................................8 Restriction Field..............................7
         2.2.1. Inclusive/Exclusive Label Lists......................9 SIMPLE_LABEL.........................................8
         2.2.2. Inclusive/Exclusive Label Ranges.....................9 CHANNEL_COUNT........................................8
         2.2.3. Bitmap LABEL_RANGE1.........................................9
         2.2.4. SIMPLE_LABEL & CHANNEL_COUNT.........................9

Internet-Draft  General Network Element Constraint Encoding    November
2013

         2.2.5. Link Label Set....................................10 Exclusivity..............................10
      2.3. Link Set Field...........................................10
      2.4. Available Labels Sub-TLV.................................11
      2.4. Field...................................12
      2.5. Shared Backup Labels Sub-TLV.............................11
      2.5. Connectivity Matrix Sub-TLV..............................12 Field...............................13
      2.6. Port Label Restriction sub-TLV...........................13 Set Field..........................................14
         2.6.1. SIMPLE_LABEL........................................14 Inclusive/Exclusive Label Lists.....................15
         2.6.2. CHANNEL_COUNT.......................................15 Inclusive/Exclusive Label Ranges....................15
         2.6.3. LABEL_RANGE1........................................15
         2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................16
         2.6.5. Link Bitmap Label Exclusivit...............................16 Set....................................16
   3. Security Considerations.......................................17
   4. IANA Considerations...........................................17
   5. Acknowledgments...............................................17
   APPENDIX A: Encoding Examples....................................18
      A.1. Link Set Field...........................................18
      A.2. Label Set Field..........................................18
      A.3. Connectivity Matrix Sub-TLV..............................19
      A.4. Connectivity Matrix with Bi-directional Symmetry.........22
      A.5. Priority Flags in Available/Shared Backup Labels sub-TLV.24
   6. References....................................................26
      6.1. Normative References.....................................26
      6.2. Informative References...................................26
   7. Contributors..................................................28
   Authors' Addresses...............................................29
   Intellectual Property Statement..................................30
   Disclaimer of Validity...........................................30

1. Introduction

   Some 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 WSON [WSON-
   Frame]. Such constraints can lead to the requirement for 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 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    November
2013

     1.1. Node Switching Asymmetry Constraints

   For some network elements the ability of a signal or packet on a
   particular ingress input port to reach a particular egress output port may be
   limited. In addition, in some network elements the connectivity
   between some ingress input ports and egress output ports may be fixed, e.g., a
   simple multiplexer. 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 ingress input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular output
   port. Representing internal state dependent blocking for a node is
   beyond the scope of this document and due to it's highly
   implementation dependent nature would most likely not be subject to
   standardization in the future. The connectivity matrix is a
   conceptual M by N matrix representing the potential switched or
   fixed connectivity, where M represents the number of ingress input ports and
   N the number of egress output ports.

     1.2. 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 an LSR may have a limited range of
   labels available for use on an egress output port and a set of labels
   already in use on that port and hence 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 node lacks the ability to perform time-slot interchange or a
   WSON lacks the ability to perform wavelength conversion then the
   label assignment process is not local to a single node and it may be
   advantageous to share the label assignment constraint information
   for use in path computation.

Internet-Draft  General Network Element Constraint Encoding    November
2013

   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
   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. Change Log

   Changes from 03 version:

   (a)  Removed informational BNF from section 1.

   (b)   Removed section on "Extension

2. Encoding Usage Recommendations"

   Changes from 04,05 versions:

   No changes just refreshed document that was expiring.

   Changes from 06 version:

   Added priority

   This section provides encodings for the information elements defined
   in [RWA-INFO] that have general applicability.  The encodings are
   designed to available wavelength encodings.

   Changes from 07 version:

   In port label constraint changed reserved field to Switching
   Capability and Encoding to allow be suitable for self description of labels used use in the GMPLS routing protocols OSPF
   [RFC4203] and interface capability.

   Changes from 08 version:

   Switching Capability IS-IS [RFC5307] and Encoding applied to all sub-cases for Port
   Label Restriction sub-TLV in Section 2.6.

   Eliminated A (Availability) Bit from Available Labels Sub-TLV and
   Shared Backup Labels Sub-TLV.

   Changes from 09 version:

   Editorial change: Action field can be set to 0x01(Inclusive Range)
   for Link Set Field Encoding the PCE protocol (PCEP)
   [RFC5440]. Note that the information distributed in Section 2.1.

   Changes from 10 version:

   Editorial change: A.5 example was corrected to be consistent to
   Sections 2.3 [RFC4203] and 2.4.

2. Encoding

   A type-length-value (TLV) encoding of
   [RFC5307] is arranged via the general connectivity and
   label restrictions nesting of sub-TLVs within TLVs and availability extensions is given in
   this
   section. document defines elements to be used within such constructs.

   This encoding is section provides encodings for the information elements defined
   in [RWA-INFO] 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 PCEP [PCEP]. (PCEP)
   [RFC5440]. Note that the information distributed in [RFC4203] and
   [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
   this document makes use of defines elements to be used within such constructs. First,
   however we define two general purpose fields that
   Specific constructs of sub-TLVs and the nesting of sub-TLVs of the
   information element defined by this document will be used
   repeatedly defined in the subsequent TLVs.
   respective protocol enhancement documents.

     2.1. Link Set Connectivity Matrix Field

   We will frequently need

   The Connectivity Matrix Field represents how input ports are
   connected to describe properties of groups of links.
   To do so efficiently we output ports for network elements. The switch and fixed
   connectivity matrices can make use be compactly represented in terms of a link
   minimal list of input and output port set concept similar 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 involves the label set concept fewest additional nodes and
   links.

Internet-Draft  General Network Element Constraint Encoding    November
2013

   A TLV encoding of [RFC3471]. This Link Set Field is used
   in the <ConnectivityMatrix> sub-TLV, which is defined in Section
   2.5.  The information carried in a Link Set is defined by: 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action     |Dir|  Format Connectivity  |         Length   MatrixID    |             Reserved          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Identifier 1 Set A #1                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Set B #1                         :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Additional Link Identifier N set pairs as needed     |
      :                     to specify connectivity                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Action: 8 bits

   Where

   Connectivity is the device type.

         0 - Inclusive List

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

         1 - Inclusive Range

   Indicates that -- the Link Set defines a range of links.  It contains
   two link identifiers. The first identifier indicates device is switched(e.g., ROADM/OXC)

   MatrixID represents the start ID of the range (inclusive). connectivity matrix and is an 8
   bit integer. The second identifier indicates the end of
   the range (inclusive). 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 0xFF is no bound on the
   corresponding portion of the range. Note that the Action field can reserved for use with port
   wavelength constraints and should not be set used to 0x01(Inclusive Range) only when unnumbered link identifier
   is used.

     Dir: Directionality of the identify a
   connectivity matrix.

   Link Set (2 bits)

         0 -- bidirectional

         1 -- ingress

         2 -- egress

   For example in optical networks we think in terms A #1 and Link Set B #1 together represent a pair of unidirectional
   as well as bidirectional links. For example, label restrictions or
   connectivity may be different for an ingress port, than link
   sets. See Section 2.3. for its
   "companion" egress port if one exists. Note that "interfaces" such
   as those discussed in a detail description of the Interfaces MIB [RFC2863] link set
   field. There are assumed to be
   bidirectional. This also applies to two permitted combinations for the links advertised in various link state routing protocols.

     Format: set field
   parameter "dir" for Link Set A and B pairs:

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

     The format meaning of the pair of link identifier (6 bits)

         0 -- Link Local Identifier

   Indicates that the links sets A and B in the Link Set are identified by link
   local identifiers. All this case is that
     any signal that inputs a link local identifiers are supplied in the
   context set A can be potentially switched
     out of the advertising node.

         1 -- Local Interface IPv4 Address

         2 -- Local Interface IPv6 Address

   Indicates that the links an output link in the set B.

   o  Link Set are identified by Local
   Interface IP Address. All Local Interface IP Address are supplied in
   the context A dir=bidirectional, Link Set B dir=bidirectional

Internet-Draft  General Network Element Constraint Encoding    November
2013

      The meaning of the advertising node.

         Others TBD.

   Note that all link identifiers in the same list must be pair of the same
   type.

     Length: 16 bits

   This field indicates the total length link sets A and B in bytes of the Link Set field.

     Link Identifier: length this case is dependent that
      any signal that inputs on the link format

   The link identifier represents the port which is being described
   either for connectivity or label restrictions. This links in set A can be the potentially
      output on a link
   local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF
   routing, in set B, and [RFC5307] IS-IS GMPLS routing. The use of any input signal on the link
   local identifier format links in
      set B can result potentially output on a link in more compact set A.

   See Appendix A for both types of encodings when
   the assignments are done in as applied to a reasonable fashion. ROADM
   example.

     2.2. Port Label Set Restriction Field

   Port Label Set Restriction Field is used within the <AvailableLabels> sub-TLV tells us what labels may or the
   <SharedBackupLabels> sub-TLV, which is defined in Section 2.3. and
   2.4. ,respectively.

   The general format for may not be
   used on a link.

   The port label set is given below. This format uses
   the Action concept from [RFC3471] with an additional Action to
   define a "bit map" type of label set. The second 32 bit field is a
   base label used restriction can be encoded as follows: More than one
   of these fields may be needed to fully specify a starting point in many complex port
   constraint. When more than one of the specific formats.

      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         |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Base Label                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Additional these fields as necessary per action                 |
     |

   Action:

         0  - Inclusive List

         1  - Exclusive List
         2  - Inclusive Range

         3  - Exclusive Range

         4  - Bitmap Set

   Num Labels are present the
   resulting restriction is only meaningful for Action value of 4 (Bitmap Set). It
   indicates the number intersection of labels represented by the bit map. See more
   detail restrictions
   expressed in section 3.2.3.

   Length is each field. To indicate that a restriction applies to
   the length port in bytes of the entire field.

   2.2.1.                         Inclusive/Exclusive Label Lists

   In general and not to a specific connectivity matrix use
   the case reserved value of 0xFF for the inclusive/exclusive lists the wavelength set
   format is given by: MatrixID.

      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 (not used)   MatrixID    |RestrictionType| Switching Cap |          Length     Encoding  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Base Label     Additional Restriction Parameters per RestrictionType     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Last  Label                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   Num Labels

   MatrixID: either is not used the value in this particular format since the Length
   parameter is sufficient corresponding Connectivity
   Matrix field or takes the value OxFF to determine indicate the number of labels in restriction
   applies to the
   list.

   2.2.2.                         Inclusive/Exclusive Label Ranges

   In port regardless of any Connectivity Matrix.

   RestrictionType can take the case following values and meanings:

         0: SIMPLE_LABEL  (Simple label selective restriction)

         1: CHANNEL_COUNT (Channel count restriction)

Internet-Draft  General Network Element Constraint Encoding    November
2013

         2: LABEL_RANGE1 (Label range device with a movable center
         label and width)

         3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of inclusive/exclusive ranges 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)

         4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once
         amongst a set of specified ports)

   Switching Capability is defined in [RFC4203] and Encoding 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.

   2.2.1.                         SIMPLE_LABEL

   In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
   MatrixSpecificRestrictions) format is given by:

      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(not used) MatrixID      |             Length RstType = 0   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Cap |                    Start Label   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     End                           Label Set Field                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that

   In this case the start and end accompanying label must in some sense "compatible" in set indicates the technology being used.

   2.2.3.                         Bitmap Label Set labels
   permitted on the port.

   2.2.2.                         CHANNEL_COUNT

   In the case of Action = 4, the bitmap CHANNEL_COUNT the label set format is given by:

Internet-Draft  General Network Element Constraint Encoding    November
2013

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MatrixID      |                         Base Label RstType = 1   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Cap |    Bit Map Word #1 (Lowest numerical labels)   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Bit Map Word #N (Highest numerical labels)                        MaxNumChannels                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Num Labels in

   In this case tells us the number of labels
   represented by the bit map. Each bit in accompanying MaxNumChannels indicates the bit map represents a
   particular label with a value maximum
   number of 1/0 indicating whether the label is
   in the set or not. Bit position zero represents the lowest label and
   corresponds to the base label, while each succeeding bit position
   represents channels (labels) that can be simultaneously used on the next label logically above
   port/matrix.

   2.2.3.                         LABEL_RANGE1

   In the previous.

   The size case of the bit map is Num Label bits, but the bit map is padded
   out to a full multiple of 32 bits so that LABEL_RANGE1 the TLV GeneralPortRestrictions (or
   MatrixSpecificRestrictions) format 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.

2.3. Available Labels Sub-TLV

   The Available Labels sub-TLV link consists of priority flags, and a
   single variable length label set field as follows: given by:

      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 MatrixID      |              Reserved RstType = 2   |Switching Cap |   Encoding     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                          MaxLabelRange                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   PRI (Priority Flags, 8 bits): Indicates priority level applied to
   Label Set Field. Bit 8 corresponds to priority level 0 and bit 15
   corresponds to priority level 7.

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

2.4. Shared Backup Labels Sub-TLV

   The Shared Backup Labels sub-TLV consists                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case the accompanying MaxLabelRange indicates the maximum
   range of priority flags, and
   single variable length the labels. The corresponding label set field as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 is used to indicate
   the overall label range. Specific center label information can be
   obtained from dynamic label in use information. It is assumed that
   both center label and range tuning can be done without causing
   faults to existing signals.

   2.2.4.                         SIMPLE_LABEL & CHANNEL_COUNT

   In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given
   by:

Internet-Draft  General Network Element Constraint Encoding    November
2013

      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 MatrixID      |            Reserved RstType = 3   | Switching Cap |   Encoding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MaxNumChannels                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Label Set Field                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
   PRI (Priority Flags, 8 bits): Indicates priority level applied to
   Label Set Field. Bit 8 corresponds to priority level 0

   In this case the accompanying label set and bit 15
   corresponds to priority level 7.

2.5. Connectivity Matrix Sub-TLV

   The Connectivity Matrix represents how ingress ports are connected
   to egress ports for network elements. The switch MaxNumChannels indicate
   labels permitted on the port and fixed
   connectivity matrices can be compactly represented in terms of a
   minimal list the maximum number of ingress and egress 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 labels that involves
   can be simultaneously used on the fewest additional nodes and
   links.

   A TLV encoding of this list port.

   2.2.5.                         Link Label Exclusivity

   In the case of link set pairs is: the Link Label Exclusivity the format is given by:

      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  | MatrixID      |             Reserved RstType = 4   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Cap |                         Link Set A #1   Encoding    |
      :                               :                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Link Set B #1                         :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Additional Link set pairs as needed Field                         |
      :                     to specify connectivity                   :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where

   Connectivity is the device type.

         0 -- the device is fixed

         1 -- the device is switched(e.g., ROADM/OXC)

   MatrixID represents the ID of

   In this case the connectivity matrix and is an 8
   bit integer. The value of 0xFF is reserved for use with accompanying port
   wavelength constraints and should not set indicate that a label may be
   used to identify a
   connectivity matrix.

   Link Set A #1 and Link Set B #1 together represent a pair of link
   sets. There are two permitted combinations for at most once among the ports in the link set field
   parameter "dir" for Link Set A and B pairs:

   o  Link Set A dir=ingress, field.

     2.3. Link Set B dir=egress

     The meaning Field

   We will frequently need to describe properties of the pair groups of link sets A and B in this case is that
     any signal that ingresses a link in set A links.
   To do so efficiently we can be potentially
     switched out make use of an egress a link in set B.

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

      The meaning of concept similar
   to the pair label set concept of link sets A and B in this case [RFC3471]. This Link Set Field is that
      any signal that ingresses on the links in set A can potentially
      egress on a link used
   in set B, and any ingress signal on the links <ConnectivityMatrix>, which is defined in
      set B can potentially egress on a link Section 2.1.  The
   information carried in set A.

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

2.6. Port Label Restriction sub-TLV

   Port Label Restriction tells us what labels may Link Set is defined by:

Internet-Draft  General Network Element Constraint Encoding    November
2013

       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 may not be used
   on more link identifiers are included in the Link
   Set. Each identifies a link. separate link that is part of the set.

         1 - Inclusive Range

   Indicates that the Link Set defines a range of links.  It contains
   two link identifiers. The port label restriction first identifier indicates the start of section 1.2.
   the range (inclusive). The second identifier indicates the end of
   the range (inclusive). 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 encoded set to 0x01(Inclusive Range) only when unnumbered link identifier
   is used.

     Dir: Directionality of the Link Set (2 bits)

         0 -- bidirectional

         1 -- input

         2 -- output

   For example in optical networks we think in terms of unidirectional
   as a sub-
   TLV well as follows. More than one of these sub-TLVs bidirectional links. For example, label restrictions or
   connectivity may be needed to
   fully specify a complex port constraint. When more different for an input port, than for its
   "companion" output port if one exists. Note that "interfaces" such

Internet-Draft  General Network Element Constraint Encoding    November
2013

   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 these
   sub-TLVs the link identifier (6 bits)

         0 -- Link Local Identifier

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

         1 -- Local Interface IPv4 Address

         2 -- Local Interface IPv6 Address

   Indicates that the links in the Link Set are identified by Local
   Interface IP Address. All Local Interface IP Address are supplied in
   the context of the advertising node.

         Others TBD.

   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.

     Link Identifier: length is dependent on the resulting restriction link format

   The link identifier represents the port which is being described
   either for connectivity or label restrictions. This can be the intersection link
   local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF
   routing, and [RFC5307] IS-IS GMPLS routing. The use of the restrictions expressed link
   local identifier format can result in each sub-TLV. To indicate that a
   restriction applies to more compact encodings when
   the port assignments are done in general and not to a specific
   connectivity matrix use the reserved value reasonable fashion.

     2.4. Available Labels Field

   The Available Labels Field consists of 0xFF for the MatrixID. priority flags, and a single
   variable length label set field as follows:

Internet-Draft  General Network Element Constraint Encoding    November
2013

      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    |RestrictionType| Switching Cap     PRI       |     Encoding              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Additional Restriction Parameters per RestrictionType                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   MatrixID: either is the value in the corresponding Connectivity
   Matrix sub-TLV or takes the value OxFF

   Where

   PRI (Priority Flags, 8 bits): A bitmap used to indicate which
   priorities are being advertised.  The bitmap is in ascending order,
   with the restriction
   applies to the port regardless of any Connectivity Matrix.

   RestrictionType can take leftmost bit representing priority level 0 (i.e., the following values and meanings:

         0: SIMPLE_LABEL  (Simple label selective restriction)

         1: CHANNEL_COUNT (Channel count restriction)

         2: LABEL_RANGE1 (Label range device with a movable center
         label and width)

         3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL
         and CHANNEL_COUNT restriction. The accompanying label set
   highest) and
         channel count indicate labels permitted on the port and rightmost bit representing priority level 7 (i.e.,
   the
         maximum number of channels that can lowest).  A bit MUST be set (1) corresponding to each priority
   represented in the sub-TLV, and MUST NOT be simultaneously used on set (0) when the port)

         4: LINK_LABEL_EXCLUSIVITY (A label may
   corresponding priority is not represented.  At least one priority
   level MUST be advertised that, unless overridden by local policy,
   SHALL be used at most once
         amongst a set of specified ports)

   Switching Capability priority level 0.

   Note that Label Set Field is defined in [RFC4203] and Encoding in
   [RFC3471]. Section 2.6. See Appendix
   A.5. for illustrative examples.

     2.5. Shared Backup Labels Field

   The combination of these fields defines the type Shared Backup Labels Field consists of
   labels used in specifying the port priority flags, and
   single variable length label restrictions as well set field as the
   interface type to which these restrictions apply.

   2.6.1.                         SIMPLE_LABEL

   In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
   MatrixSpecificRestrictions) format is given by: 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MatrixID      | RstType = 0   | Switching Cap     PRI         |   Encoding            Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case

   Where

   PRI (Priority Flags, 8 bits): A bitmap used to indicate which
   priorities are being advertised.  The bitmap is in ascending order,
   with the accompanying leftmost bit representing priority level 0 (i.e., the

Internet-Draft  General Network Element Constraint Encoding    November
2013

   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, and MUST NOT be set (0) when the
   corresponding priority is not represented.  At least one priority
   level MUST be advertised that, unless overridden by local policy,
   SHALL be at priority level 0.

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

     2.6. Label Set Field

   Label Set Field is used within the <AvailableLabels> or the
   <SharedBackupLabels>, which is defined in Section 2.4. and 2.5.,
   respectively.

   The general format for a label set indicates the labels
   permitted on the port.

   2.6.2.                         CHANNEL_COUNT

   In is given below. This format uses
   the case Action concept from [RFC3471] with an additional Action to
   define a "bit map" type of label set. Labels are variable in length
   The second 32 bit field is a part of the CHANNEL_COUNT base label used as a
   starting point in many of the format is given by: specific formats.

      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 Action|    Num Labels         | RstType = 1          Length               | Switching Cap
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Encoding                          Base Label                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MaxNumChannels                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case the accompanying MaxNumChannels indicates
     |     Additional fields as necessary per action                 |
     |                                                               |

   Action:

         0  - Inclusive List

         1  - Exclusive List

         2  - Inclusive Range

         3  - Exclusive Range

Internet-Draft  General Network Element Constraint Encoding    November
2013

         4  - Bitmap Set

   Length is the maximum
   number length in bytes of channels (labels) that can be simultaneously used on the
   port/matrix.

   2.6.3.                         LABEL_RANGE1 entire field.

   2.6.1.                         Inclusive/Exclusive Label Lists

   In the case of the LABEL_RANGE1 inclusive/exclusive lists the GeneralPortRestrictions (or
   MatrixSpecificRestrictions) wavelength set
   format is given by:

      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 | MatrixID      | RstType = 2   |Switching Cap Num Labels          |   Encoding            Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MaxLabelRange                         Label #1                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Label Set Field #N                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case the accompanying MaxLabelRange indicates the maximum
   range of the labels. The corresponding label set

   Where:

   Label #1 is used to indicate the overall label range. Specific center label information can first Label to be
   obtained from dynamic label in use information. It is assumed that
   both center label included/excluded and range tuning can be done without causing
   faults Label #N is
   the last Label to existing signals.

   2.6.4.                         SIMPLE_LABEL & CHANNEL_COUNT be included/excluded. Num Labels MUST match with
   N.

   2.6.2.                         Inclusive/Exclusive Label Ranges

   In the case of inclusive/exclusive ranges the SIMPLE_LABEL & CHANNEL_COUNT the label set format is
   given by:

Internet-Draft  General Network Element Constraint Encoding    November
2013

      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 or 3 | Switching Cap Num Labels          |   Encoding               Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MaxNumChannels                    Start Label                                |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     End Label Set Field                                 |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this case

   Note that that Start Label is the accompanying label set and MaxNumChannels indicate
   labels permitted on first Label in the port range to be
   included/excluded and End Label is the maximum number of labels that
   can be simultaneously used on last label in the port.

   2.6.5.                         Link same range.
   Num Labels MUST be two.

   2.6.3.                         Bitmap Label Exclusivity Set

   In the case of Action = 4, the Link Label Exclusivity bitmap the label set format is given
   by:

      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    | Switching Cap   Num Labels          |   Encoding             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Link Set Field                         Base Label                            |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In
     |    Bit Map Word #1 (Lowest numerical labels)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Bit Map Word #N (Highest numerical labels)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Num Labels in this case tells us the accompanying port set indicate that number of labels
   represented by the bit map. Each bit in the bit map represents a
   particular label with a value of 1/0 indicating whether the label may be
   used at most once among is
   in the set or not. 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.

Internet-Draft  General Network Element Constraint Encoding    November
2013

   The size of the bit map is Num Label bits, but the bit map is padded
   out to a full multiple of 32 bits so that the ports field is a multiple of
   four bytes. Bits that do not represent labels (i.e., those in the link
   positions (Num Labels) and beyond SHOULD be set field. 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
   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

   TBD. Once our approach

   This document provides general protocol independent information
   encodings.  There is finalized we may need identifiers no IANA allocation request for the
   various TLVs and sub-TLVs. information
   elements defined in this document. IANA allocation requests will be
   addressed in 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    November
2013

APPENDIX A: Encoding Examples

   Here we give 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 ingress input ports that are have
   link local identifiers number 3 through 42. In the link set field we
   set the Action = 1 to denote an inclusive range; the Dir = 1 to
   denote ingress input links; and, the Format = 0 to denote link local
   identifiers. In particular 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 C-Band DWDM system with 100GHz spacing with lowest
   frequency 192.0THz (1561.4nm) and highest frequency 195.9THz
   (1530.3nm). These frequencies correspond to n = -11, and n = 28
   respectively. Now suppose the following channels are available:

   Frequency (THz)       n Value      bit map 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

   With

   Using the label format defined in [RFC 6205], with the Grid value
   set to indicate an ITU-T G.694.1 DWDM grid, C.S. set to indicate
   100GHz this lambda bit map set would then be encoded as follows:

Internet-Draft  General Network Element Constraint Encoding    November
2013

      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 Wavelengths 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 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 Wavelengths Labels = 40 7        |    Length = 20 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 Sub-TLV

   Example:

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

Internet-Draft  General Network Element Constraint Encoding    November
2013

   below illustrates how a typical 2-degree ROADM system that works
   with bi-directional fiber pairs is a highly asymmetrical system
   composed of two unidirectional ROADM subsystems.

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

   Referring to the figure we see that the ingress Input direction of ports
   #3-#42 #3-
   #42 (add ports) can only connect to the egress output on port #1. While the ingress
   Input side of port #2 (line side) can only connect to the
   egress output on
   ports #3-#42 (drop) and to the egress output on port #1 (pass through).
   Similarly, the ingress input direction of ports #43-#82 can only connect to
   the egress output on port #2 (line). While the ingress input direction of port #1
   can only connect to the egress 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 30 32-
   bit 32-bit words.

Internet-Draft  General Network Element Constraint Encoding    November
2013

     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    November
2013

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     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 Symmetry

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

Internet-Draft  General Network Element Constraint Encoding    November
2013

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

Internet-Draft  General Network Element Constraint Encoding    November
2013

     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 #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 sub-TLV

   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    November
2013

   while allowing a set of labels (indicated by Label Set Field #2)
   available to all priority levels (Priority Level 7), 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 0 0 0 0|              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field #1                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 0 0 0 0|              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field #2                        |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Internet-Draft  General Network Element Constraint Encoding    November
2013

6. References

     6.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, June 2000.

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

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

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

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

     6.2. Informative References

   [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
             applications: DWDM frequency grid, June 2002.

   [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
             applications: CWDM wavelength grid, December 2003.

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

   [RFC5440]    Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path
             Computation Element (PCE) communication Protocol (PCEP) -
             Version 1", RFC5440.

Internet-Draft  General Network Element Constraint Encoding    November
2013

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

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

   [PCEP]    Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation

Internet-Draft  General Network Element (PCE) communication Protocol (PCEP) - Version 1",
             RFC5440. Constraint Encoding    November
2013

7. Contributors

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

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

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

   Email: Anders.Gavler@acreo.se

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

   Email: Jonas.Martensson@acreo.se

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

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

   Rao Rajan
   Infinera

   Email: rrao@infinera.com

   Giovanni Martinelli
   CISCO

   Email: giomarti@cisco.com

   Remi Theillaud

Internet-Draft  General Network Element Constraint Encoding    November
2013

   Marben
   remi.theillaud@marben-products.com

Authors' Addresses

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

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

   Young Lee (ed.)
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: (972) 509-5599 (x2240)
   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

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

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

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

Internet-Draft  General Network Element Constraint Encoding    November
2013

   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972916
   Email: hanjianrui@huawei.com

Intellectual Property Statement

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

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

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

Disclaimer of Validity

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

Internet-Draft  General Network Element Constraint Encoding    November
2013

Acknowledgment

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