draft-ietf-ccamp-general-constraint-encode-01.txt   draft-ietf-ccamp-general-constraint-encode-02.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: September 2010 D. Li Expires: December 2010 D. Li
Huawei Huawei
W. Imajuku W. Imajuku
NTT NTT
March 2, 2010 June 9, 2010
General Network Element Constraint Encoding for GMPLS Controlled General Network Element Constraint Encoding for GMPLS Controlled
Networks Networks
draft-ietf-ccamp-general-constraint-encode-01.txt draft-ietf-ccamp-general-constraint-encode-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 September 2, 2010. This Internet-Draft will expire on December 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
Generalized Multiprotocol Label Switching can be used to control a Generalized Multiprotocol Label Switching can be used to control a
wide variety of technologies. In some of these technologies network wide variety of technologies. In some of these technologies network
elements and links may impose additional routing constraints such as elements and links may impose additional routing constraints such as
asymmetric switch connectivity, label limitation and label asymmetric switch connectivity, non-local label assignment, and label
availability on links. range limitations on links.
This document provides efficient, protocol-agnostic encodings for This document provides efficient, protocol-agnostic encodings for
general information elements representing connectivity and label general information elements representing connectivity and label
constraints as well as label availability. These encodings are constraints as well as label availability. It is intended that
applicable to a wide range of technologies and not limited to WSON. protocol-specific documents will reference this memo to describe how
It is intended that protocol-specific documents will reference this information is carried for specific uses.
memo to describe how information is carried for specific uses.
Conventions used in this document Conventions used in this document
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
2. Extension Encoding Usage Recommendations.......................4 1.1. Node Switching Asymmetry Constraints......................4
2.1. Extension Node TLV........................................4 1.2. Non-Local Label Assignment Constraints....................4
2.2. Extension Link TLV........................................4 2. Extension Encoding Usage Recommendations.......................5
2.3. Extension Dynamic Link TLV................................4 2.1. Extension Node TLV........................................6
3. Link Set Field.................................................4 2.2. Extension Link TLV........................................6
4. Label Set Field................................................6 2.3. Extension Dynamic Link TLV................................6
4.1. Inclusive/Exclusive Label Lists...........................7 3. Encoding.......................................................6
4.2. Inclusive/Exclusive Label Ranges..........................8 3.1. Link Set Field............................................6
4.3. Bitmap Label Set..........................................8 3.2. Label Set Field...........................................8
3.2.1. Inclusive/Exclusive Label Lists......................9
5. Label and Connectivity sub-TLV Encodings.......................9 3.2.2. Inclusive/Exclusive Label Ranges....................10
5.1. Available Labels Sub-TLV..................................9 3.2.3. Bitmap Label Set....................................10
5.2. Shared Backup Labels Sub-TLV.............................10 3.3. Available Labels Sub-TLV.................................11
5.3. Connectivity Matrix Sub-TLV..............................10 3.4. Shared Backup Labels Sub-TLV.............................12
5.4. Port Label Restriction sub-TLV...........................12 3.5. Connectivity Matrix Sub-TLV..............................12
5.4.1. SIMPLE_LABEL........................................13 3.6. Port Label Restriction sub-TLV...........................13
5.4.2. CHANNEL_COUNT.......................................13 3.6.1. SIMPLE_LABEL........................................14
5.4.3. LABEL_RANGE1........................................13 3.6.2. CHANNEL_COUNT.......................................15
5.4.4. SIMPLE_LABEL & CHANNEL_COUNT........................14 3.6.3. LABEL_RANGE1........................................15
6. Security Considerations.......................................14 3.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................15
7. IANA Considerations...........................................15 4. Security Considerations.......................................16
8. Acknowledgments...............................................15 5. IANA Considerations...........................................16
APPENDIX A: Encoding Examples....................................16 6. Acknowledgments...............................................16
A.1. Link Set Field...........................................16 APPENDIX A: Encoding Examples....................................17
A.2. Label Set Field..........................................16 A.1. Link Set Field...........................................17
A.3. Connectivity Matrix Sub-TLV..............................17 A.2. Label Set Field..........................................17
A.4. Connectivity Matrix with Bi-directional Symmetry.........20 A.3. Connectivity Matrix Sub-TLV..............................18
9. References....................................................23 A.4. Connectivity Matrix with Bi-directional Symmetry.........21
9.1. Normative References.....................................23 7. References....................................................24
9.2. Informative References...................................23 7.1. Normative References.....................................24
10. Contributors.................................................25 7.2. Informative References...................................24
Authors' Addresses...............................................25 8. Contributors..................................................26
Intellectual Property Statement..................................26 Authors' Addresses...............................................26
Disclaimer of Validity...........................................27 Intellectual Property Statement..................................27
Disclaimer of Validity...........................................28
1. Introduction 1. Introduction
Some data plane technologies that wish to make use of a GMPLS control Some data plane technologies that wish to make use of a GMPLS control
plane contain additional constraints on switching capability and plane contain additional constraints on switching capability and
label assignment. In addition, some of these technologies must label assignment. In addition, some of these technologies must
perform non-local label assignment based on the nature of the perform non-local label assignment based on the nature of the
technology, e.g., wavelength continuity constraint in WSON [WSON- technology, e.g., wavelength continuity constraint in WSON [WSON-
Frame]. Such constraints can lead to the requirement for link by link Frame]. Such constraints can lead to the requirement for link by link
label availability in path computation and label assignment. 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 WSON the routing and label assignment process in technologies such as WSON
but that are potentially applicable to a wider range of technologies. and are potentially applicable to a wider range of technologies. Such
Such encodings can be used to extend GMPLS signaling and routing encodings can be used to extend GMPLS signaling and routing
protocols. In addition these encodings could be used by other protocols. In addition these encodings could be used by other
mechanisms to convey this same information to a path computation mechanisms to convey this same information to a path computation
element (PCE). element (PCE).
Encodings of information needed by the routing and wavelength 1.1. Node Switching Asymmetry Constraints
assignment (RWA) process unique to WSON is addressed in a separate
document [WSON-Encode]. For some network elements the ability of a signal or packet on a
particular ingress port to reach a particular egress port may be
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.
ConnectivityMatrix(i, j) ::= <MatrixID> <ConnType> <Matrix>
Where
<MatrixID> is a unique identifier for the matrix.
<ConnType> can be either 0 or 1 depending upon whether the
connectivity is either fixed or potentially switched.
<Matrix> represents the fixed or switched connectivity in that
Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect
to egress port j for one or more labels.
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
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.
<PortLabelRestriction> ::= [<GeneralPortRestrictions>...]
[<MatrixSpecificRestrictions>...]
<GeneralPortRestrictions> ::= <RestrictionType>
[<RestrictionParameters>]
<MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType>
[<RestrictionParameters>]
Where
MatrixID is the ID of the corresponding connectivity matrix
The RestrictionType parameter is used to specify general port
restrictions and matrix specific restrictions.
2. Extension Encoding Usage Recommendations 2. Extension Encoding Usage Recommendations
In this section we give recommendations of typical usage of the sub- In this section we give recommendations of typical usage of the sub-
TLVs and composite TLVs. TLVs and composite TLVs.
2.1. Extension Node TLV 2.1. Extension Node TLV
The Extension Node TLV could consist of the following list of sub- The Extension Node TLV could consist of the following list of sub-
TLVs: TLVs:
<Node_Info> ::= <Node_ID>[Other GMPLS sub- <Node_Info> ::= <Node_ID>[Other GMPLS sub-TLVs]
TLVs][<ConnectivityMatrix>...] [<ConnectivityMatrix>...]
2.2. Extension Link TLV 2.2. Extension Link TLV
The new link related sub-TLVs could be incorporated into a composite The new link related sub-TLVs could be incorporated into a composite
link TLV as follows: link TLV as follows:
<LinkInfo> ::= <LinkID> [Other GMPLS sub-TLVs] <LinkInfo> ::= <LinkID> [Other GMPLS sub-TLVs]
[<PortLabelRestriction>...][<AvailableLabels>] [<SharedBackupLabels>] [<PortLabelRestriction>...][<AvailableLabels>] [<SharedBackupLabels>]
2.3. Extension Dynamic Link TLV 2.3. Extension Dynamic Link TLV
If the protocol supports the separation of dynamic information from If the protocol supports the separation of dynamic information from
relatively static information then the available wavelength and relatively static information then the available wavelength and
shared backup status can be separated from the general link TLV into shared backup status can be separated from the general link TLV into
a TLV for dynamic link information. a TLV for dynamic link information.
<DynamicLinkInfo> ::= <LinkID> <AvailableLabels> <DynamicLinkInfo> ::= <LinkID> <AvailableLabels>
[<SharedBackupLabels>] [<SharedBackupLabels>]
3. Link Set Field 3. 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.
3.1. Link Set Field
We will frequently need to describe properties of groups of links. To 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 in the label set concept of [RFC3471]. This Link Set Field is used in
the <ConnectivityMatrix> sub-TLV, which is defined in Section 6.3. the <ConnectivityMatrix> sub-TLV, which is defined in Section 6.3.
The information carried in a Link Set is defined by: The information carried in a Link Set is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 41 skipping to change at page 8, line 43
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 local routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local
identifier format can result in more compact encodings when the identifier format can result in more compact encodings when the
assignments are done in a reasonable fashion. assignments are done in a reasonable fashion.
4. Label Set Field 3.2. Label Set Field
Label Set Field is used within the <AvailableLabels> sub-TLV or the Label Set Field is used within the <AvailableLabels> sub-TLV or the
<SharedBackupLabels> sub-TLV, which is defined in Section 6.1 and <SharedBackupLabels> sub-TLV, which is defined in Section 6.1 and
6.2, respectively. 6.2, 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 define the Action concept from [RFC3471] with an additional Action to define
a "bit map" type of label set. The second 32 bit field is a base 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. label used as a starting point in many of the specific formats.
skipping to change at page 7, line 35 skipping to change at page 9, line 38
3 - Exclusive Range 3 - Exclusive Range
4 - Bitmap Set 4 - Bitmap Set
Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 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 indicates the number of labels represented by the bit map. See more
detail in section 3.2.3. 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.
4.1. Inclusive/Exclusive Label Lists 3.2.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 (not used) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label | | Base Label |
skipping to change at page 8, line 23 skipping to change at page 10, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Label | | Last Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
Num Labels is not used in this particular format since the Length Num Labels is not used in this particular format since the Length
parameter is sufficient to determine the number of labels in the parameter is sufficient to determine the number of labels in the
list. list.
4.2. Inclusive/Exclusive Label Ranges 3.2.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:
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(not used) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the start and end label must in some sense "compatible" in Note that the start and end label must in some sense "compatible" in
the technology being used. the technology being used.
4.3. Bitmap Label Set 3.2.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 |
skipping to change at page 9, line 32 skipping to change at page 11, line 32
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.
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 TLV 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.
5. Label and Connectivity sub-TLV Encodings 3.3. Available Labels Sub-TLV
A type-length-value (TLV) encoding of the general connectivity and
label restrictions and availability extensions is given in the
following sections. 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.
5.1. Available Labels Sub-TLV
To indicate the labels available for use on a link the Available To indicate the labels available for use on a link the Available
Labels sub-TLV consists of a single variable length label set field Labels sub-TLV consists of a single variable length label set field
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field | | Label Set Field |
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that Label Set Field is defined in Section 3.2. Note that Label Set Field is defined in Section 3.2.
5.2. Shared Backup Labels Sub-TLV 3.4. Shared Backup Labels Sub-TLV
To indicate the labels available for shared backup use on a link the To indicate the labels available for shared backup use on a link the
Shared Backup Labels sub-TLV consists of a single variable length Shared Backup Labels sub-TLV consists of a single variable length
label set field as follows: label set field as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field | | Label Set Field |
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Connectivity Matrix Sub-TLV 3.5. Connectivity Matrix Sub-TLV
Connectivity Matrix represents how ingress ports are connected to
egress ports for network elements.
The switch and fixed connectivity matrices of [WSON-Info] can be The switch and fixed connectivity matrices of [WSON-Info] can be
compactly represented in terms of a minimal list of ingress and compactly represented in terms of a minimal list of ingress and
egress port set pairs that have mutual connectivity. As described in egress port set pairs that have mutual connectivity. As described in
[Switch] such a minimal list representation leads naturally to a [Switch] such a minimal list representation leads naturally to a
graph representation for path computation purposes that involves the graph representation for path computation purposes that involves the
fewest additional nodes and links. fewest additional nodes and links.
A TLV encoding of this list of link set pairs is: A TLV encoding of this list of link set pairs is:
skipping to change at page 12, line 5 skipping to change at page 13, line 34
any signal that ingresses a link in set A can be potentially any signal that ingresses a link in set A can be potentially
switched out of an egress link in set B. switched out of an egress link in set B.
o Link Set A dir=bidirectional, Link Set B dir=bidirectional 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 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 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 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. set B can potentially egress on a link in set A.
See Appendix A for both types of encodings as applied to a WSON See Appendix A for both types of encodings as applied to a ROADM
example. example.
5.4. Port Label Restriction sub-TLV 3.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 [WSON-Info] can be encoded as a sub-TLV The port label restriction of [WSON-Info] can be encoded as a sub-TLV
as follows. More than one of these sub-TLVs may be needed to fully 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- specify a complex port constraint. When more than one of these sub-
TLVs are present the resulting restriction is the intersection of the TLVs are present the resulting restriction is the intersection of the
restrictions expressed in each sub-TLV. To indicate that a restrictions expressed in each sub-TLV. To indicate that a
restriction applies to the port in general and not to a specific restriction applies to the port in general and not to a specific
connectivity matrix use the reserved value of 0xFF for the MatrixID. connectivity matrix use the reserved value of 0xFF for the MatrixID.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 5 skipping to change at page 14, line 35
2: LABEL_RANGE1 (Label range device with a movable center label 2: LABEL_RANGE1 (Label range device with a movable center label
and width) and width)
3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL
and CHANNEL_COUNT restriction. The accompanying label set and and CHANNEL_COUNT restriction. The accompanying label set and
channel count indicate labels permitted on the port and the channel count indicate labels permitted on the port and the
maximum number of channels that can be simultaneously used on maximum number of channels that can be simultaneously used on
the port) the port)
5.4.1. SIMPLE_LABEL 3.6.1. SIMPLE_LABEL
In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
MatrixSpecificRestrictions) format is given by: MatrixSpecificRestrictions) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 0 | Reserved | | MatrixID | RstType = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field | | Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set indicates the labels In this case the accompanying label set indicates the labels
permitted on the port. permitted on the port.
5.4.2. CHANNEL_COUNT 3.6.2. CHANNEL_COUNT
In the case of the CHANNEL_COUNT the format is given by: In the case of the CHANNEL_COUNT the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 1 | MaxNumChannels | | MatrixID | RstType = 1 | MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxNumChannels indicates the maximum In this case the accompanying MaxNumChannels indicates the maximum
number of channels (labels) that can be simultaneously used on the number of channels (labels) that can be simultaneously used on the
port/matrix. port/matrix.
5.4.3. LABEL_RANGE1 3.6.3. LABEL_RANGE1
In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or
MatrixSpecificRestrictions) format is given by: MatrixSpecificRestrictions) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixID | RstType = 2 | MaxLabelRange | | MatrixID | RstType = 2 | MaxLabelRange |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field | | Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying MaxLabelRange indicates the maximum In this case the accompanying MaxLabelRange indicates the maximum
range of the labels. The corresponding label set is used to indicate range of the labels. The corresponding label set is used to indicate
the overall label range. Specific center label information can be the overall label range. Specific center label information can be
obtained from dynamic label in use information. It is assumed that obtained from dynamic label in use information. It is assumed that
both center label and range tuning can be done without causing faults both center label and range tuning can be done without causing faults
to existing signals. to existing signals.
5.4.4. SIMPLE_LABEL & CHANNEL_COUNT 3.6.4. SIMPLE_LABEL & CHANNEL_COUNT
In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given In the case of the SIMPLE_LABEL & CHANNEL_COUNT the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatrixInfo | RstType = 3 | MaxNumChannels | | MatrixInfo | RstType = 3 | MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set Field | | Label Set Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the accompanying label set and MaxNumChannels indicate In this case the accompanying label set and MaxNumChannels indicate
labels permitted on the port and the maximum number of labels that labels permitted on the port and the maximum number of labels that
can be simultaneously used on the port. can be simultaneously used on the port.
6. Security Considerations 4. 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.
7. IANA Considerations 5. IANA Considerations
TBD. Once our approach is finalized we may need identifiers for the TBD. Once our approach is finalized we may need identifiers for the
various TLVs and sub-TLVs. various TLVs and sub-TLVs.
8. Acknowledgments 6. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
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 WSON 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 have 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 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 set the Action = 1 to denote an inclusive range; the Dir = 1 to
denote ingress links; and, the Format = 0 to denote link local denote ingress links; and, the Format = 0 to denote link local
identifiers. In particular we have: identifiers. In particular we have:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 5 skipping to change at page 24, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |13 | Link Local Identifier = #1 |13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |15 | Link Local Identifier = #2 |15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. References 7. References
9.1. Normative References 7.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 23, line 30 skipping to change at page 24, line 30
applications: DWDM frequency grid", June, 2002. applications: DWDM frequency grid", June, 2002.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005 (GMPLS)", RFC 4202, October 2005
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
9.2. Informative References 7.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.
[Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized
Labels for G.694 Lambda-Switching Capable Label Switching Labels for G.694 Lambda-Switching Capable Label Switching
Routers", work in progress: draft-ietf-ccamp-gmpls-g-694- Routers", work in progress: draft-ietf-ccamp-gmpls-g-694-
skipping to change at page 25, line 5 skipping to change at page 26, line 5
[WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Encoding for Wavelength Wavelength Assignment Information Encoding for Wavelength
Switched Optical Networks", work in progress: draft-ietf- Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-wson-encode, Februsary, 2010. ccamp-rwa-wson-encode, Februsary, 2010.
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1", Element (PCE) communication Protocol (PCEP) - Version 1",
RFC5440. RFC5440.
10. Contributors 8. 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@(marconi.com, ericsson.com)
Anders Gavler Anders Gavler
 End of changes. 32 change blocks. 
83 lines changed or deleted 169 lines changed or added

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