General Network Element Constraint Encoding for GMPLS Controlled Networks
draft-ietf-ccamp-general-constraint-encode-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7579.
|
|
|---|---|---|---|
| Authors | Greg M. Bernstein , Young Lee , Dan Li , Wataru Imajuku | ||
| Last updated | 2011-12-13 (Latest revision 2011-05-25) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7579 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ccamp-general-constraint-encode-06
Network Working Group G. Bernstein
Internet Draft Grotto Networking
Intended status: Standards Track Y. Lee
Expires: June 2012 D. Li
Huawei
W. Imajuku
NTT
December 13, 2011
General Network Element Constraint Encoding for GMPLS Controlled
Networks
draft-ietf-ccamp-general-constraint-encode-06.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 June 13, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bernstein and Lee Expires June 13, 2012 [Page 1]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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......................3
1.2. Non-Local Label Assignment Constraints....................4
1.3. Change Log................................................5
2. Encoding.......................................................5
2.1. Link Set Field............................................5
2.2. Label Set Field...........................................7
2.2.1. Inclusive/Exclusive Label Lists......................8
2.2.2. Inclusive/Exclusive Label Ranges.....................9
2.2.3. Bitmap Label Set.....................................9
2.3. Available Labels Sub-TLV.................................10
Bernstein and Lee Expires June 13, 2012 [Page 2]
Internet-Draft General Network Element Constraint EncodingDecember 2011
2.4. Shared Backup Labels Sub-TLV.............................11
2.5. Connectivity Matrix Sub-TLV..............................11
2.6. Port Label Restriction sub-TLV...........................12
2.6.1. SIMPLE_LABEL........................................13
2.6.2. CHANNEL_COUNT.......................................14
2.6.3. LABEL_RANGE1........................................14
2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................15
2.6.5. Link Label Exclusivity..............................15
3. Security Considerations.......................................15
4. IANA Considerations...........................................16
5. Acknowledgments...............................................16
APPENDIX A: Encoding Examples....................................17
A.1. Link Set Field...........................................17
A.2. Label Set Field..........................................17
A.3. Connectivity Matrix Sub-TLV..............................18
A.4. Connectivity Matrix with Bi-directional Symmetry.........21
6. References....................................................24
6.1. Normative References.....................................24
6.2. Informative References...................................24
7. Contributors..................................................25
Authors' Addresses...............................................26
Intellectual Property Statement..................................27
Disclaimer of Validity...........................................27
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).
1.1. Node Switching Asymmetry Constraints
For some network elements the ability of a signal or packet on a
particular ingress port to reach a particular egress port may be
Bernstein and Lee Expires June 13, 2012 [Page 3]
Internet-Draft General Network Element Constraint EncodingDecember 2011
limited. In addition, in some network elements the connectivity
between some ingress ports and egress 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 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 ports and N the number of egress
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 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.
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
Bernstein and Lee Expires June 13, 2012 [Page 4]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 Encoding Usage Recommendations"
Changes from 04,05 versions:
No changes just refreshed document that was expiring.
2. Encoding
A type-length-value (TLV) encoding of the general connectivity and
label restrictions and availability extensions is given in this
section. This encoding is designed to be suitable for use in the
GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in 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
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
the label set concept 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:
Bernstein and Lee Expires June 13, 2012 [Page 5]
Internet-Draft General Network Element Constraint EncodingDecember 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Dir| Format | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
0 - Inclusive List
Indicates that one or more link identifiers are included in the Link
Set. Each identifies a 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 first identifier indicates the start of 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 set to
0x02(Inclusive Range) only when unnumbered link identifier is used.
Dir: Directionality of the Link Set (2 bits)
0 -- bidirectional
1 -- ingress
2 -- egress
For example in optical networks we think in terms of unidirectional
as well as bidirectional links. For example, label restrictions or
connectivity may be different for an ingress port, than for its
"companion" egress port if one exists. Note that "interfaces" such as
those discussed in the Interfaces MIB [RFC2863] are assumed to be
Bernstein and Lee Expires June 13, 2012 [Page 6]
Internet-Draft General Network Element Constraint EncodingDecember 2011
bidirectional. This also applies to the links advertised in various
link state routing protocols.
Format: The format of the link identifier (6 bits)
0 -- Link Local Identifier
Indicates that the links in the Link Set are 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 link format
The link identifier represents the port which is being described
either for connectivity or label restrictions. This can be the link
local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF
routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local
identifier format can result in more compact encodings when the
assignments are done in a reasonable fashion.
2.2. Label Set Field
Label Set Field is used within the <AvailableLabels> sub-TLV or the
<SharedBackupLabels> sub-TLV, which is defined in Section 2.3. and
2.4. , respectively.
The general format for a label set is given below. This format uses
the Action concept from [RFC3471] with an additional Action to define
Bernstein and Lee Expires June 13, 2012 [Page 7]
Internet-Draft General Network Element Constraint EncodingDecember 2011
a "bit map" type of label set. The second 32 bit field is a base
label used as a starting point in many 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 fields as necessary per action |
|
Action:
0 - Inclusive List
1 - Exclusive List
2 - Inclusive Range
3 - Exclusive Range
4 - Bitmap Set
Num Labels is only meaningful for Action value of 4 (Bitmap Set). It
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.
2.2.1. Inclusive/Exclusive Label Lists
In the case of the inclusive/exclusive lists the wavelength set
format is given by:
Bernstein and Lee Expires June 13, 2012 [Page 8]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Num Labels is not used in this particular format since the Length
parameter is sufficient to determine the number of labels in the
list.
2.2.2. Inclusive/Exclusive Label Ranges
In the case of inclusive/exclusive ranges 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|2 or 3 | Num Labels(not used) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the start and end label must in some sense "compatible" in
the technology being used.
2.2.3. Bitmap Label Set
In the case of Action = 4, the bitmap the label set format is given
by:
Bernstein and Lee Expires June 13, 2012 [Page 9]
Internet-Draft General Network Element Constraint EncodingDecember 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map Word #1 (Lowest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map Word #N (Highest numerical 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
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
corresponds to the base label, while each succeeding bit position
represents the next label logically above the previous.
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
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
To indicate the labels available for use on a link the Available
Labels sub-TLV consists of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that Label Set Field is defined in Section 3.2.
Bernstein and Lee Expires June 13, 2012 [Page 10]
Internet-Draft General Network Element Constraint EncodingDecember 2011
2.4. Shared Backup Labels Sub-TLV
To indicate the labels available for shared backup use on a link the
Shared Backup Labels sub-TLV consists of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Bernstein and Lee Expires June 13, 2012 [Page 11]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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.
Bernstein and Lee Expires June 13, 2012 [Page 12]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 | Reserved/Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
2.6.1. SIMPLE_LABEL
In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
MatrixSpecificRestrictions) format is given by:
Bernstein and Lee Expires June 13, 2012 [Page 13]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | 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 | 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
Bernstein and Lee Expires June 13, 2012 [Page 14]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 | 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 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 = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
This document defines protocol-independent encodings for WSON
information and does not introduce any security issues.
Bernstein and Lee Expires June 13, 2012 [Page 15]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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.
4. IANA Considerations
TBD. Once our approach is finalized we may need identifiers for the
various TLVs and sub-TLVs.
5. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Bernstein and Lee Expires June 13, 2012 [Page 16]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 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 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 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:
Bernstein and Lee Expires June 13, 2012 [Page 17]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 = 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 = 40 | 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
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.
Bernstein and Lee Expires June 13, 2012 [Page 18]
Internet-Draft General Network Element Constraint EncodingDecember 2011
(Tributary) Ports #3-#42
Ingress added to Egress dropped from
West Line Egress East Line Ingress
vvvvv ^^^^^
| |||.| | |||.|
+-----| |||.|--------| |||.|------+
| +----------------------+ |
| | | |
Egress | | Unidirectional ROADM | | Ingress
-----------------+ | | +--------------
<=====================| |===================<
-----------------+ +----------------------+ +--------------
| |
Port #1 | | Port #2
(West Line Side) | |(East Line Side)
-----------------+ +----------------------+ +--------------
>=====================| |===================>
-----------------+ | Unidirectional ROADM | +--------------
Ingress | | | | Egress
| | _ | |
| +----------------------+ |
+-----| |||.|--------| |||.|------+
| |||.| | |||.|
vvvvv ^^^^^
(Tributary) Ports #43-#82
Egress dropped from Ingress added to
West Line ingress East Line egress
Referring to the figure we see that the ingress direction of ports
#3-#42 (add ports) can only connect to the egress on port #1. While
the ingress side of port #2 (line side) can only connect to the
egress on ports #3-#42 (drop) and to the egress on port #1 (pass
through). Similarly, the ingress direction of ports #43-#82 can only
connect to the egress on port #2 (line). While the ingress direction
of port #1 can only connect to the egress 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 words.
Bernstein and Lee Expires June 13, 2012 [Page 19]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 |1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: adds to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #3 |3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #42 |4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to drops
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #3 |10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #42 |11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: adds to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #43 |17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bernstein and Lee Expires June 13, 2012 [Page 20]
Internet-Draft General Network Element Constraint EncodingDecember 2011
| Link Local Identifier = #82 |18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to drops
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #43 |24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #82 |25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Bernstein and Lee Expires June 13, 2012 [Page 21]
Internet-Draft General Network Element Constraint EncodingDecember 2011
(Tributary)
Ports #3-42 Ports #43-82
West Line Egress East Line Ingress
vvvvv ^^^^^
| |||.| | |||.|
+-----| |||.|--------| |||.|------+
| +----------------------+ |
| | | |
Egress | | Unidirectional ROADM | | Ingress
-----------------+ | | +--------------
<=====================| |===================<
-----------------+ +----------------------+ +--------------
| |
Port #1 | | Port #2
(West Line Side) | |(East Line Side)
-----------------+ +----------------------+ +--------------
>=====================| |===================>
-----------------+ | Unidirectional ROADM | +--------------
Ingress | | | | Egress
| | _ | |
| +----------------------+ |
+-----| |||.|--------| |||.|------+
| |||.| | |||.|
vvvvv ^^^^^
Ports #3-#42 Ports #43-82
Egress dropped from Ingress added to
West Line ingress East Line egress
Bernstein and Lee Expires June 13, 2012 [Page 22]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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 |1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Add/Drops #3-42 to Line side #1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #3 |3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #42 |4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line #2 to add/drops #43-82
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #43 |10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #82 |11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: line to line
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bernstein and Lee Expires June 13, 2012 [Page 23]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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.
Bernstein and Lee Expires June 13, 2012 [Page 24]
Internet-Draft General Network Element Constraint EncodingDecember 2011
[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
Element (PCE) communication Protocol (PCEP) - Version 1",
RFC5440.
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)
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
Bernstein and Lee Expires June 13, 2012 [Page 25]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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
Bernstein and Lee Expires June 13, 2012 [Page 26]
Internet-Draft General Network Element Constraint EncodingDecember 2011
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.
Bernstein and Lee Expires June 13, 2012 [Page 27]
Internet-Draft General Network Element Constraint EncodingDecember 2011
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernstein and Lee Expires June 13, 2012 [Page 28]