draft-ietf-ccamp-general-constraint-encode-11.txt   draft-ietf-ccamp-general-constraint-encode-12.txt 
Network Working Group G. Bernstein Network Working Group G. Bernstein
Internet Draft Grotto Networking Internet Draft Grotto Networking
Intended status: Standards Track Y. Lee Intended status: Standards Track Y. Lee
Expires: November 2013 D. Li Expires: May 2014 D. Li
Huawei Huawei
W. Imajuku W. Imajuku
NTT NTT
May 6, 2013 November 13, 2013
General Network Element Constraint Encoding for GMPLS Controlled General Network Element Constraint Encoding for GMPLS Controlled
Networks Networks
draft-ietf-ccamp-general-constraint-encode-11.txt draft-ietf-ccamp-general-constraint-encode-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 6, 2013. This Internet-Draft will expire on May 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. 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 This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
skipping to change at page 2, line 40 skipping to change at page 2, line 43
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Node Switching Asymmetry Constraints......................4 1.1. Node Switching Asymmetry Constraints......................4
1.2. Non-Local Label Assignment Constraints....................4 1.2. Non-Local Label Assignment Constraints....................4
1.3. Change Log................................................5 2. Encoding.......................................................5
2. Encoding.......................................................6 2.1. Connectivity Matrix Field.................................5
2.1. Link Set Field............................................6 2.2. Port Label Restriction Field..............................7
2.2. Label Set Field...........................................8 2.2.1. SIMPLE_LABEL.........................................8
2.2.1. Inclusive/Exclusive Label Lists......................9 2.2.2. CHANNEL_COUNT........................................8
2.2.2. Inclusive/Exclusive Label Ranges.....................9 2.2.3. LABEL_RANGE1.........................................9
2.2.3. Bitmap Label Set....................................10 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT.........................9
2.3. Available Labels Sub-TLV.................................11
2.4. Shared Backup Labels Sub-TLV.............................11 Internet-Draft General Network Element Constraint Encoding November
2.5. Connectivity Matrix Sub-TLV..............................12 2013
2.6. Port Label Restriction sub-TLV...........................13
2.6.1. SIMPLE_LABEL........................................14 2.2.5. Link Label Exclusivity..............................10
2.6.2. CHANNEL_COUNT.......................................15 2.3. Link Set Field...........................................10
2.6.3. LABEL_RANGE1........................................15 2.4. Available Labels Field...................................12
2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................16 2.5. Shared Backup Labels Field...............................13
2.6.5. Link Label Exclusivit...............................16 2.6. Label Set Field..........................................14
2.6.1. Inclusive/Exclusive Label Lists.....................15
2.6.2. Inclusive/Exclusive Label Ranges....................15
2.6.3. Bitmap Label Set....................................16
3. Security Considerations.......................................17 3. Security Considerations.......................................17
4. IANA Considerations...........................................17 4. IANA Considerations...........................................17
5. Acknowledgments...............................................17 5. Acknowledgments...............................................17
APPENDIX A: Encoding Examples....................................18 APPENDIX A: Encoding Examples....................................18
A.1. Link Set Field...........................................18 A.1. Link Set Field...........................................18
A.2. Label Set Field..........................................18 A.2. Label Set Field..........................................18
A.3. Connectivity Matrix Sub-TLV..............................19 A.3. Connectivity Matrix Sub-TLV..............................19
A.4. Connectivity Matrix with Bi-directional Symmetry.........22 A.4. Connectivity Matrix with Bi-directional Symmetry.........22
A.5. Priority Flags in Available/Shared Backup Labels sub-TLV.24 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV.24
6. References....................................................26 6. References....................................................26
skipping to change at page 4, line 5 skipping to change at page 4, line 5
link label availability in path computation and label assignment. link label availability in path computation and label assignment.
This document provides efficient encodings of information needed by This document provides efficient encodings of information needed by
the routing and label assignment process in technologies such as the routing and label assignment process in technologies such as
WSON and are potentially applicable to a wider range of WSON and are potentially applicable to a wider range of
technologies. Such encodings can be used to extend GMPLS signaling technologies. Such encodings can be used to extend GMPLS signaling
and routing protocols. In addition these encodings could be used by and routing protocols. In addition these encodings could be used by
other mechanisms to convey this same information to a path other mechanisms to convey this same information to a path
computation element (PCE). computation element (PCE).
1.1. Node Switching Asymmetry Constraints 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 For some network elements the ability of a signal or packet on a
particular ingress port to reach a particular egress port may be particular input port to reach a particular output port may be
limited. In addition, in some network elements the connectivity limited. In addition, in some network elements the connectivity
between some ingress ports and egress ports may be fixed, e.g., a between some input ports and output ports may be fixed, e.g., a
simple multiplexer. To take into account such constraints during simple multiplexer. To take into account such constraints during
path computation we model this aspect of a network element via a path computation we model this aspect of a network element via a
connectivity matrix. connectivity matrix.
The connectivity matrix (ConnectivityMatrix) represents either the The connectivity matrix (ConnectivityMatrix) represents either the
potential connectivity matrix for asymmetric switches or fixed potential connectivity matrix for asymmetric switches or fixed
connectivity for an asymmetric device such as a multiplexer. Note connectivity for an asymmetric device such as a multiplexer. Note
that this matrix does not represent any particular internal blocking that this matrix does not represent any particular internal blocking
behavior but indicates which ingress ports and labels (e.g., behavior but indicates which input ports and labels (e.g.,
wavelengths) could possibly be connected to a particular output wavelengths) could possibly be connected to a particular output
port. Representing internal state dependent blocking for a node is port. Representing internal state dependent blocking for a node is
beyond the scope of this document and due to it's highly beyond the scope of this document and due to it's highly
implementation dependent nature would most likely not be subject to implementation dependent nature would most likely not be subject to
standardization in the future. The connectivity matrix is a standardization in the future. The connectivity matrix is a
conceptual M by N matrix representing the potential switched or conceptual M by N matrix representing the potential switched or
fixed connectivity, where M represents the number of ingress ports fixed connectivity, where M represents the number of input ports and
and N the number of egress ports. N the number of output ports.
1.2. Non-Local Label Assignment Constraints 1.2. Non-Local Label Assignment Constraints
If the nature of the equipment involved in a network results in a If the nature of the equipment involved in a network results in a
requirement for non-local label assignment we can have constraints requirement for non-local label assignment we can have constraints
based on limits imposed by the ports themselves and those that are based on limits imposed by the ports themselves and those that are
implied by the current label usage. Note that constraints such as implied by the current label usage. Note that constraints such as
these only become important when label assignment has a non-local these only become important when label assignment has a non-local
character. For example in MPLS an LSR may have a limited range of character. For example in MPLS an LSR may have a limited range of
labels available for use on an egress port and a set of labels labels available for use on an output port and a set of labels
already in use on that port and hence unavailable for use. This already in use on that port and hence unavailable for use. This
information, however, does not need to be shared unless there is information, however, does not need to be shared unless there is
some limitation on the LSR's label swapping ability. For example if 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 a TDM node lacks the ability to perform time-slot interchange or a
WSON lacks the ability to perform wavelength conversion then the WSON lacks the ability to perform wavelength conversion then the
label assignment process is not local to a single node and it may be label assignment process is not local to a single node and it may be
advantageous to share the label assignment constraint information advantageous to share the label assignment constraint information
for use in path computation. for use in path computation.
Internet-Draft General Network Element Constraint Encoding November
2013
Port label restrictions (PortLabelRestriction) model the label Port label restrictions (PortLabelRestriction) model the label
restrictions that the network element (node) and link may impose on restrictions that the network element (node) and link may impose on
a port. These restrictions tell us what labels may or may not be 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 used on a link and are intended to be relatively static. More
dynamic information is contained in the information on available dynamic information is contained in the information on available
labels. Port label restrictions are specified relative to the port labels. Port label restrictions are specified relative to the port
in general or to a specific connectivity matrix for increased in general or to a specific connectivity matrix for increased
modeling flexibility. Reference [Switch] gives an example where both modeling flexibility. Reference [Switch] gives an example where both
switch and fixed connectivity matrices are used and both types of switch and fixed connectivity matrices are used and both types of
constraints occur on the same port. constraints occur on the same port.
1.3. Change Log 2. Encoding
Changes from 03 version: This section provides encodings for the information elements defined
in [RWA-INFO] that have general applicability. 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)
[RFC5440]. Note that the information distributed in [RFC4203] and
[RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
this document defines elements to be used within such constructs.
(a) Removed informational BNF from section 1. This 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)
[RFC5440]. Note that the information distributed in [RFC4203] and
[RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
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.
(b) Removed section on "Extension Encoding Usage Recommendations" 2.1. Connectivity Matrix Field
Changes from 04,05 versions: 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 involves the fewest additional nodes and
links.
No changes just refreshed document that was expiring. Internet-Draft General Network Element Constraint Encoding November
2013
Changes from 06 version: A TLV encoding of this list of link set pairs is:
Added priority information to available wavelength encodings. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set A #1 |
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set B #1 :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Link set pairs as needed |
: to specify connectivity :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Changes from 07 version: Where
In port label constraint changed reserved field to Switching Connectivity is the device type.
Capability and Encoding to allow for self description of labels used
and interface capability.
Changes from 08 version: 0 -- the device is fixed
Switching Capability and Encoding applied to all sub-cases for Port 1 -- the device is switched(e.g., ROADM/OXC)
Label Restriction sub-TLV in Section 2.6.
Eliminated A (Availability) Bit from Available Labels Sub-TLV and MatrixID represents the ID of the connectivity matrix and is an 8
Shared Backup Labels Sub-TLV. bit integer. The value of 0xFF is reserved for use with port
wavelength constraints and should not be used to identify a
connectivity matrix.
Changes from 09 version: Link Set A #1 and Link Set B #1 together represent a pair of link
sets. See Section 2.3. for a detail description of the link set
field. There are two permitted combinations for the link set field
parameter "dir" for Link Set A and B pairs:
Editorial change: Action field can be set to 0x01(Inclusive Range) o Link Set A dir=input, Link Set B dir=output
for Link Set Field Encoding in Section 2.1.
Changes from 10 version: 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.
Editorial change: A.5 example was corrected to be consistent to o Link Set A dir=bidirectional, Link Set B dir=bidirectional
Sections 2.3 and 2.4.
2. Encoding Internet-Draft General Network Element Constraint Encoding November
2013
A type-length-value (TLV) encoding of the general connectivity and The meaning of the pair of link sets A and B in this case is that
label restrictions and availability extensions is given in this any signal that inputs on the links in set A can potentially
section. This encoding is designed to be suitable for use in the output on a link in set B, and any input signal on the links in
GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in set B can potentially output on a link in set A.
the PCE protocol PCEP [PCEP]. 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 such constructs. First,
however we define two general purpose fields that will be used
repeatedly in the subsequent TLVs.
2.1. Link Set Field See Appendix A for both types of encodings as applied to a ROADM
example.
2.2. Port Label Restriction Field
Port Label Restriction Field tells us what labels may or may not be
used on a link.
The port label restriction can be encoded as 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 present the
resulting restriction is the intersection of the restrictions
expressed in each field. To indicate that a restriction applies to
the port in general and not to a specific connectivity matrix use
the reserved value of 0xFF for the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID |RestrictionType| Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Restriction Parameters per RestrictionType |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
MatrixID: either is the value in the corresponding Connectivity
Matrix field or takes the value OxFF to indicate the restriction
applies to the port regardless of any Connectivity Matrix.
RestrictionType can take the 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 0 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set indicates the labels
permitted on the port.
2.2.2. CHANNEL_COUNT
In the case of the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 1 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxNumChannels indicates the maximum
number of channels (labels) that can be simultaneously used on the
port/matrix.
2.2.3. LABEL_RANGE1
In the case of the LABEL_RANGE1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 2 |Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxLabelRange |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxLabelRange indicates the maximum
range of the labels. The corresponding label set 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 3 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set and MaxNumChannels indicate
labels permitted on the port and the maximum number of labels that
can be simultaneously used on the port.
2.2.5. Link Label Exclusivity
In the case of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 4 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying port set indicate that a label may be
used at most once among the ports in the link set field.
2.3. Link Set Field
We will frequently need to describe properties of groups of links. We will frequently need to describe properties of groups of links.
To do so efficiently we can make use of a link set concept similar To do so efficiently we can make use of a link set concept similar
to the label set concept of [RFC3471]. This Link Set Field is used to the label set concept of [RFC3471]. This Link Set Field is used
in the <ConnectivityMatrix> sub-TLV, which is defined in Section in the <ConnectivityMatrix>, which is defined in Section 2.1. The
2.5. The information carried in a Link Set is defined by: information carried in a Link Set is defined by:
Internet-Draft General Network Element Constraint Encoding November
2013
0 1 2 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 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 | | Action |Dir| Format | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier 1 | | Link Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
skipping to change at page 7, line 24 skipping to change at page 11, line 44
bounds are considered to be part of the set. A value of zero in bounds are considered to be part of the set. A value of zero in
either position indicates that there is no bound on the either position indicates that there is no bound on the
corresponding portion of the range. Note that the Action field can corresponding portion of the range. Note that the Action field can
be set to 0x01(Inclusive Range) only when unnumbered link identifier be set to 0x01(Inclusive Range) only when unnumbered link identifier
is used. is used.
Dir: Directionality of the Link Set (2 bits) Dir: Directionality of the Link Set (2 bits)
0 -- bidirectional 0 -- bidirectional
1 -- ingress 1 -- input
2 -- egress 2 -- output
For example in optical networks we think in terms of unidirectional For example in optical networks we think in terms of unidirectional
as well as bidirectional links. For example, label restrictions or as well as bidirectional links. For example, label restrictions or
connectivity may be different for an ingress port, than for its connectivity may be different for an input port, than for its
"companion" egress port if one exists. Note that "interfaces" such "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 as those discussed in the Interfaces MIB [RFC2863] are assumed to be
bidirectional. This also applies to the links advertised in various bidirectional. This also applies to the links advertised in various
link state routing protocols. link state routing protocols.
Format: The format of the link identifier (6 bits) Format: The format of the link identifier (6 bits)
0 -- Link Local Identifier 0 -- Link Local Identifier
Indicates that the links in the Link Set are identified by link Indicates that the links in the Link Set are identified by link
local identifiers. All link local identifiers are supplied in the local identifiers. All link local identifiers are supplied in the
skipping to change at page 8, line 23 skipping to change at page 12, line 46
Link Identifier: length is dependent on the link format Link Identifier: length is dependent on the link format
The link identifier represents the port which is being described The link identifier represents the port which is being described
either for connectivity or label restrictions. This can be the link either for connectivity or label restrictions. This can be the link
local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF
routing, and [RFC5307] IS-IS GMPLS routing. The use of the link routing, and [RFC5307] IS-IS GMPLS routing. The use of the link
local identifier format can result in more compact encodings when local identifier format can result in more compact encodings when
the assignments are done in a reasonable fashion. the assignments are done in a reasonable fashion.
2.2. Label Set Field 2.4. Available Labels Field
Label Set Field is used within the <AvailableLabels> sub-TLV or the The Available Labels Field consists of priority flags, and a single
<SharedBackupLabels> sub-TLV, which is defined in Section 2.3. and variable length label set field as follows:
2.4. ,respectively.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, 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.5. Shared Backup Labels Field
The Shared Backup Labels Field consists of priority flags, and
single 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
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
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 is given below. This format uses The general format for a label set is given below. This format uses
the Action concept from [RFC3471] with an additional Action to 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 define a "bit map" type of label set. Labels are variable in length
base label used as a starting point in many of the specific formats. The second 32 bit field is a part of the base label used as a
starting point in many of the specific formats.
0 1 2 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 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 | | Action| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label | | Base Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action | | Additional fields as necessary per action |
| | |
Action: Action:
0 - Inclusive List 0 - Inclusive List
1 - Exclusive List 1 - Exclusive List
2 - Inclusive Range 2 - Inclusive Range
3 - Exclusive Range 3 - Exclusive Range
4 - Bitmap Set Internet-Draft General Network Element Constraint Encoding November
2013
Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 4 - Bitmap Set
indicates the number of labels represented by the bit map. See more
detail in section 3.2.3.
Length is the length in bytes of the entire field. Length is the length in bytes of the entire field.
2.2.1. Inclusive/Exclusive Label Lists 2.6.1. Inclusive/Exclusive Label Lists
In the case of the inclusive/exclusive lists the wavelength set In the case of the inclusive/exclusive lists the wavelength set
format is given by: format is given by:
0 1 2 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 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) | Length | |0 or 1 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label | | Label #1 |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Label | | Label #N |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
Num Labels is not used in this particular format since the Length Label #1 is the first Label to be included/excluded and Label #N is
parameter is sufficient to determine the number of labels in the the last Label to be included/excluded. Num Labels MUST match with
list. N.
2.2.2. Inclusive/Exclusive Label Ranges 2.6.2. Inclusive/Exclusive Label Ranges
In the case of inclusive/exclusive ranges the label set format is In the case of inclusive/exclusive ranges the label set format is
given by: given by:
Internet-Draft General Network Element Constraint Encoding November
2013
0 1 2 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 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) | Length | |2 or 3 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the start and end label must in some sense "compatible" in Note that that Start Label is the first Label in the range to be
the technology being used. included/excluded and End Label is the last label in the same range.
Num Labels MUST be two.
2.2.3. Bitmap Label Set 2.6.3. Bitmap Label Set
In the case of Action = 4, the bitmap the label set format is given In the case of Action = 4, the bitmap the label set format is given
by: by:
0 1 2 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 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 | | 4 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label | | Base Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map Word #1 (Lowest numerical labels) | | Bit Map Word #1 (Lowest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map Word #N (Highest numerical labels) | | Bit Map Word #N (Highest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Num Labels in this case tells us the number of labels Where Num Labels in this case tells us the number of labels
represented by the bit map. Each bit in the bit map represents a 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 is particular label with a value of 1/0 indicating whether the label is
in the set or not. Bit position zero represents the lowest label and in the set or not. Bit position zero represents the lowest label and
corresponds to the base label, while each succeeding bit position corresponds to the base label, while each succeeding bit position
represents the next label logically above the previous. 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 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 TLV is a multiple of 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 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 positions (Num Labels) and beyond SHOULD be set to zero and MUST be
ignored. 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:
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
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 of priority flags, and
single 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
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.
2.5. Connectivity Matrix Sub-TLV
The Connectivity Matrix represents how ingress ports are connected
to egress ports for network elements. The switch and fixed
connectivity matrices can be compactly represented in terms of a
minimal list 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 that involves the fewest additional nodes and
links.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connectivity | MatrixID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set A #1 |
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set B #1 :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Link set pairs as needed |
: 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 the connectivity matrix and is an 8
bit integer. The value of 0xFF is reserved for use with port
wavelength 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. There are two permitted combinations for the link set field
parameter "dir" for Link Set A and B pairs:
o Link Set A dir=ingress, Link Set B dir=egress
The meaning of the pair of link sets A and B in this case is that
any signal that ingresses a link in set A can be potentially
switched out of an egress link in set B.
o Link Set A dir=bidirectional, Link Set B dir=bidirectional
The meaning of the pair of link sets A and B in this case is that
any signal that ingresses on the links in set A can potentially
egress on a link in set B, and any ingress signal on the links in
set B can potentially egress on a link 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 or may not be used
on a link.
The port label restriction of section 1.2. can be encoded as a sub-
TLV as follows. More than one of these sub-TLVs may be needed to
fully specify a complex port constraint. When more than one of these
sub-TLVs are present the resulting restriction is the intersection
of the restrictions expressed in each sub-TLV. To indicate that a
restriction applies to the port in general and not to a specific
connectivity matrix use the reserved value of 0xFF for the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID |RestrictionType| Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Restriction Parameters per RestrictionType |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
MatrixID: either is the value in the corresponding Connectivity
Matrix sub-TLV or takes the value OxFF to indicate the restriction
applies to the port regardless of any Connectivity Matrix.
RestrictionType can take 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 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.6.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 0 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set indicates the labels
permitted on the port.
2.6.2. CHANNEL_COUNT
In the case of the CHANNEL_COUNT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 1 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxNumChannels indicates the maximum
number of channels (labels) that can be simultaneously used on the
port/matrix.
2.6.3. LABEL_RANGE1
In the case of the LABEL_RANGE1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 2 |Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxLabelRange |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxLabelRange indicates the maximum
range of the labels. The corresponding label set 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.6.4. SIMPLE_LABEL & CHANNEL_COUNT
In the case of the SIMPLE_LABEL & CHANNEL_COUNT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 3 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set and MaxNumChannels indicate
labels permitted on the port and the maximum number of labels that
can be simultaneously used on the port.
2.6.5. Link Label Exclusivity
In the case of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 4 | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying port set indicate that a label may be
used at most once among the ports in the link set field.
3. Security Considerations 3. Security Considerations
This document defines protocol-independent encodings for WSON This document defines protocol-independent encodings for WSON
information and does not introduce any security issues. information and does not introduce any security issues.
However, other documents that make use of these encodings within However, other documents that make use of these encodings within
protocol extensions need to consider the issues and risks associated protocol extensions need to consider the issues and risks associated
with, inspection, interception, modification, or spoofing of any of with, inspection, interception, modification, or spoofing of any of
this information. It is expected that any such documents will this information. It is expected that any such documents will
describe the necessary security measures to provide adequate describe the necessary security measures to provide adequate
protection. protection. A general discussion on security in GMPLS networks can
be found in [RFC5920].
4. IANA Considerations 4. IANA Considerations
TBD. Once our approach is finalized we may need identifiers for the This document provides general protocol independent information
various TLVs and sub-TLVs. encodings. There is no IANA allocation request for the information
elements defined in this document. IANA allocation requests will be
addressed in protocol specific documents based on the encodings
defined here.
5. Acknowledgments 5. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Internet-Draft General Network Element Constraint Encoding November
2013
APPENDIX A: Encoding Examples APPENDIX A: Encoding Examples
Here we give examples of the general encoding extensions applied to Here we give examples of the general encoding extensions applied to
some simple ROADM network elements and links. some simple ROADM network elements and links.
A.1. Link Set Field A.1. Link Set Field
Suppose that we wish to describe a set of ingress ports that are Suppose that we wish to describe a set of input ports that are have
have link local identifiers number 3 through 42. In the link set link local identifiers number 3 through 42. In the link set field we
field we set the Action = 1 to denote an inclusive range; the Dir = set the Action = 1 to denote an inclusive range; the Dir = 1 to
1 to denote ingress links; and, the Format = 0 to denote link local denote input links; and, the Format = 0 to denote link local
identifiers. In particular we have: identifiers. In particular we have:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 1|0 0 0 0 0 0| Length = 12 | | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #3 | | Link Local Identifier = #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #42 | | Link Local Identifier = #42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 45 skipping to change at page 18, line 48
Frequency (THz) n Value bit map position Frequency (THz) n Value bit map position
-------------------------------------------------- --------------------------------------------------
192.0 -11 0 192.0 -11 0
192.5 -6 5 192.5 -6 5
193.1 0 11 193.1 0 11
193.9 8 19 193.9 8 19
194.0 9 20 194.0 9 20
195.2 21 32 195.2 21 32
195.8 27 38 195.8 27 38
With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. Using the label format defined in [RFC 6205], with the Grid value
set to indicate 100GHz this lambda bit map set would then be encoded set to indicate an ITU-T G.694.1 DWDM grid, C.S. set to indicate
as follows: 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
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 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 = 40 | Length = 16 bytes | | 4 | Num Labels = 40 | Length = 16 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = -11 | |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 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) | |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: To encode this same set as an inclusive list we would have:
0 1 2 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 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 = 40 | Length = 20 bytes | | 0 | Num Labels = 7 | Length = 20 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = -11 | |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 = -6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = -0 | |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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = 9 | |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 = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = 27 | |Grid | C.S. | Reserved | n for lowest frequency = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.3. Connectivity Matrix Sub-TLV A.3. Connectivity Matrix
Example: Example:
Suppose we have a typical 2-degree 40 channel ROADM. In addition to 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 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 below illustrates how a typical 2-degree ROADM system that works
with bi-directional fiber pairs is a highly asymmetrical system with bi-directional fiber pairs is a highly asymmetrical system
composed of two unidirectional ROADM subsystems. composed of two unidirectional ROADM subsystems.
(Tributary) Ports #3-#42 (Tributary) Ports #3-#42
Ingress added to Egress dropped from Input added to Output dropped from
West Line Egress East Line Ingress West Line Output East Line Input
vvvvv ^^^^^ vvvvv ^^^^^
| |||.| | |||.| | |||.| | |||.|
+-----| |||.|--------| |||.|------+ +-----| |||.|--------| |||.|------+
| +----------------------+ | | +----------------------+ |
| | | | | | | |
Egress | | Unidirectional ROADM | | Ingress Output | | Unidirectional ROADM | | Input
-----------------+ | | +-------------- -----------------+ | | +--------------
<=====================| |===================< <=====================| |===================<
-----------------+ +----------------------+ +-------------- -----------------+ +----------------------+ +--------------
| | | |
Port #1 | | Port #2 Port #1 | | Port #2
(West Line Side) | |(East Line Side) (West Line Side) | |(East Line Side)
-----------------+ +----------------------+ +-------------- -----------------+ +----------------------+ +--------------
>=====================| |===================> >=====================| |===================>
-----------------+ | Unidirectional ROADM | +-------------- -----------------+ | Unidirectional ROADM | +--------------
Ingress | | | | Egress Input | | | | Output
| | _ | | | | _ | |
| +----------------------+ | | +----------------------+ |
+-----| |||.|--------| |||.|------+ +-----| |||.|--------| |||.|------+
| |||.| | |||.| | |||.| | |||.|
vvvvv ^^^^^ vvvvv ^^^^^
(Tributary) Ports #43-#82 (Tributary) Ports #43-#82
Egress dropped from Ingress added to Output dropped from Input added to
West Line ingress East Line egress West Line Input East Line Output
Referring to the figure we see that the ingress direction of ports Referring to the figure we see that the Input direction of ports #3-
#3-#42 (add ports) can only connect to the egress on port #1. While #42 (add ports) can only connect to the output on port #1. While the
the ingress side of port #2 (line side) can only connect to the Input side of port #2 (line side) can only connect to the output on
egress on ports #3-#42 (drop) and to the egress on port #1 (pass ports #3-#42 (drop) and to the output on port #1 (pass through).
through). Similarly, the ingress direction of ports #43-#82 can only Similarly, the input direction of ports #43-#82 can only connect to
connect to the egress on port #2 (line). While the ingress direction the output on port #2 (line). While the input direction of port #1
of port #1 can only connect to the egress on ports #43-#82 (drop) or can only connect to the output on ports #43-#82 (drop) or port #2
port #2 (pass through). We can now represent this potential (pass through). We can now represent this potential connectivity
connectivity matrix as follows. This representation uses only 30 32- matrix as follows. This representation uses only 30 32-bit words.
bit words.
Internet-Draft General Network Element Constraint Encoding November
2013
0 1 2 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 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 | | Conn = 1 | MatrixID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: adds to line Note: adds to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 1|0 0 0 0 0 0| Length = 12 | | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 49 skipping to change at page 22, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 | | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 | | Link Local Identifier = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: adds to line Note: adds to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 1|0 0 0 0 0 0| Length = 12 | | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #43 | | Link Local Identifier = #43 |
Internet-Draft General Network Element Constraint Encoding November
2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #82 | | Link Local Identifier = #82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 | | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 | | Link Local Identifier = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to drops Note: line to drops
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |
skipping to change at page 23, line 5 skipping to change at page 23, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4. Connectivity Matrix with Bi-directional Symmetry A.4. Connectivity Matrix with Bi-directional Symmetry
If one has the ability to renumber the ports of the previous example 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- as shown in the next figure then we can take advantage of the bi-
directional symmetry and use bi-directional encoding of the directional symmetry and use bi-directional encoding of the
connectivity matrix. Note that we set dir=bidirectional in the link connectivity matrix. Note that we set dir=bidirectional in the link
set fields. set fields.
Internet-Draft General Network Element Constraint Encoding November
2013
(Tributary) (Tributary)
Ports #3-42 Ports #43-82 Ports #3-42 Ports #43-82
West Line Egress East Line Ingress West Line Output East Line Input
vvvvv ^^^^^ vvvvv ^^^^^
| |||.| | |||.| | |||.| | |||.|
+-----| |||.|--------| |||.|------+ +-----| |||.|--------| |||.|------+
| +----------------------+ | | +----------------------+ |
| | | | | | | |
Egress | | Unidirectional ROADM | | Ingress Output | | Unidirectional ROADM | | Input
-----------------+ | | +-------------- -----------------+ | | +--------------
<=====================| |===================< <=====================| |===================<
-----------------+ +----------------------+ +-------------- -----------------+ +----------------------+ +--------------
| | | |
Port #1 | | Port #2 Port #1 | | Port #2
(West Line Side) | |(East Line Side) (West Line Side) | |(East Line Side)
-----------------+ +----------------------+ +-------------- -----------------+ +----------------------+ +--------------
>=====================| |===================> >=====================| |===================>
-----------------+ | Unidirectional ROADM | +-------------- -----------------+ | Unidirectional ROADM | +--------------
Ingress | | | | Egress Input | | | | Output
| | _ | | | | _ | |
| +----------------------+ | | +----------------------+ |
+-----| |||.|--------| |||.|------+ +-----| |||.|--------| |||.|------+
| |||.| | |||.| | |||.| | |||.|
vvvvv ^^^^^ vvvvv ^^^^^
Ports #3-#42 Ports #43-82 Ports #3-#42 Ports #43-82
Egress dropped from Ingress added to Output dropped from Input added to
West Line ingress East Line egress West Line Input East Line Output
Internet-Draft General Network Element Constraint Encoding November
2013
0 1 2 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 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 | | Conn = 1 | MatrixID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Add/Drops #3-42 to Line side #1 Add/Drops #3-42 to Line side #1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 0|0 0 0 0 0 0| Length = 12 | | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 45 skipping to change at page 24, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 | | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 | | Link Local Identifier = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 | | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 | | Link Local Identifier = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5. Priority Flags in Available/Shared Backup Labels sub-TLV A.5. Priority Flags in Available/Shared Backup Labels
If one wants to make a set of labels (indicated by Label Set Field If one wants to make a set of labels (indicated by Label Set Field
#1) available only for highest priority level (Priority Level 0) #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) while allowing a set of labels (indicated by Label Set Field #2)
available to all priority levels (Priority Level 7), the following available to all priority levels, the following encoding will
encoding will express such need. express such need.
0 1 2 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 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 | |0 0 0 1 0 0 0 0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field #1 | | Label Set Field #1 |
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 0 0| Reserved | |1 1 1 1 0 0 0 0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field #2 | | Label Set Field #2 |
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet-Draft General Network Element Constraint Encoding November
2013
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
skipping to change at page 26, line 30 skipping to change at page 26, line 33
applications: DWDM frequency grid", June, 2002. applications: DWDM frequency grid", June, 2002.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005 Switching (GMPLS)", RFC 4202, October 2005
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
6.2. Informative References 6.2. Informative References
[G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
applications: DWDM frequency grid, June 2002. applications: DWDM frequency grid, June 2002.
[G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
applications: CWDM wavelength grid, December 2003. applications: CWDM wavelength grid, December 2003.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008. (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 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling
WDM Wavelength Switching Systems for Use in GMPLS and WDM Wavelength Switching Systems for Use in GMPLS and
Automated Path Computation", Journal of Optical Communications Automated Path Computation", Journal of Optical Communications
and Networking, vol. 1, June, 2009, pp. 187-195. 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 Constraint Encoding November
Element (PCE) communication Protocol (PCEP) - Version 1", 2013
RFC5440.
7. Contributors 7. Contributors
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
Genoa Italy Genoa Italy
Phone: +39 010 600 3736 Phone: +39 010 600 3736
Email: diego.caviglia@(marconi.com, ericsson.com) Email: diego.caviglia@ericsson.com
Anders Gavler Anders Gavler
Acreo AB Acreo AB
Electrum 236 Electrum 236
SE - 164 40 Kista Sweden SE - 164 40 Kista Sweden
Email: Anders.Gavler@acreo.se Email: Anders.Gavler@acreo.se
Jonas Martensson Jonas Martensson
Acreo AB Acreo AB
skipping to change at page 28, line 48 skipping to change at page 29, line 4
Infinera Infinera
Email: rrao@infinera.com Email: rrao@infinera.com
Giovanni Martinelli Giovanni Martinelli
CISCO CISCO
Email: giomarti@cisco.com Email: giomarti@cisco.com
Remi Theillaud Remi Theillaud
Internet-Draft General Network Element Constraint Encoding November
2013
Marben Marben
remi.theillaud@marben-products.com remi.theillaud@marben-products.com
Authors' Addresses Authors' Addresses
Greg M. Bernstein (ed.) Greg M. Bernstein (ed.)
Grotto Networking Grotto Networking
Fremont California, USA Fremont California, USA
Phone: (510) 573-2237 Phone: (510) 573-2237
skipping to change at page 30, line 4 skipping to change at page 30, line 4
Phone: +86-755-28973237 Phone: +86-755-28973237
Email: danli@huawei.com Email: danli@huawei.com
Wataru Imajuku Wataru Imajuku
NTT Network Innovation Labs NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa 1-1 Hikari-no-oka, Yokosuka, Kanagawa
Japan Japan
Phone: +81-(46) 859-4315 Phone: +81-(46) 859-4315
Email: imajuku.wataru@lab.ntt.co.jp Email: imajuku.wataru@lab.ntt.co.jp
Internet-Draft General Network Element Constraint Encoding November
2013
Jianrui Han Jianrui Han
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972916 Phone: +86-755-28972916
Email: hanjianrui@huawei.com Email: hanjianrui@huawei.com
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 31, line 5 skipping to change at page 31, line 5
All IETF Documents and the information contained therein are All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Internet-Draft General Network Element Constraint Encoding November
2013
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 95 change blocks. 
379 lines changed or deleted 473 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/