idnits 2.13.01
tmp/draft-ietf-ccamp-general-constraint-encode-14.txt:
tmp/draft-ietf-ccamp-general-constraint-encode-14.txt(1061): Possible code comment in line: #42 (add ports) can only connect to the output on port #1. While the.
tmp/draft-ietf-ccamp-general-constraint-encode-14.txt(1289): Possible code comment in line: #1) available only for the highest priority level (Priority Level 0).
Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- Found something which looks like a code comment -- if you have code
sections in the document, please surround them with '<CODE BEGINS>' and
'<CODE ENDS>' lines.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).
--------------------------------------------------------------------------------
1 Network Working Group G. Bernstein
2 Internet Draft Grotto Networking
3 Intended status: Standards Track Y. Lee
4 Expires: July 2014 D. Li
5 Huawei
6 W. Imajuku
7 NTT
9 January 30, 2014
11 General Network Element Constraint Encoding for GMPLS Controlled
12 Networks
14 draft-ietf-ccamp-general-constraint-encode-14.txt
16 Status of this Memo
18 This Internet-Draft is submitted to IETF in full conformance with
19 the provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six
27 months and may be updated, replaced, or obsoleted by other documents
28 at any time. It is inappropriate to use Internet-Drafts as
29 reference material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html
37 This Internet-Draft will expire on July 30, 2014.
39 Copyright Notice
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with
49 respect to this document. Code Components extracted from this
50 document must include Simplified BSD License text as described in
51 Section 4.e of the Trust Legal Provisions and are provided without
52 warranty as described in the Simplified BSD License.
54 Abstract
56 Generalized Multiprotocol Label Switching can be used to control a
57 wide variety of technologies. In some of these technologies network
58 elements and links may impose additional routing constraints such as
59 asymmetric switch connectivity, non-local label assignment, and
60 label range limitations on links.
62 This document provides efficient, protocol-agnostic encodings for
63 general information elements representing connectivity and label
64 constraints as well as label availability. It is intended that
65 protocol-specific documents will reference this memo to describe how
66 information is carried for specific uses.
68 Conventions used in this document
70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
72 document are to be interpreted as described in RFC-2119 [RFC2119].
74 Table of Contents
76 1. Introduction...................................................3
77 1.1. Node Switching Asymmetry Constraints......................3
78 1.2. Non-Local Label Assignment Constraints....................4
79 2. Encoding.......................................................5
80 2.1. Connectivity Matrix Field.................................5
81 2.2. Port Label Restriction Field..............................7
82 2.2.1. SIMPLE_LABEL.........................................8
83 2.2.2. CHANNEL_COUNT........................................8
84 2.2.3. LABEL_RANGE1.........................................9
85 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT.........................9
86 2.2.5. Link Label Exclusivity..............................10
88 2.3. Link Set Field...........................................10
89 2.4. Available Labels Field...................................12
90 2.5. Shared Backup Labels Field...............................13
91 2.6. Label Set Field..........................................13
92 2.6.1. Inclusive/Exclusive Label Lists.....................14
93 2.6.2. Inclusive/Exclusive Label Ranges....................15
94 2.6.3. Bitmap Label Set....................................16
95 3. Security Considerations.......................................16
96 4. IANA Considerations...........................................17
97 5. Acknowledgments...............................................17
98 APPENDIX A: Encoding Examples....................................18
99 A.1. Link Set Field...........................................18
100 A.2. Label Set Field..........................................18
101 A.3. Connectivity Matrix......................................19
102 A.4. Connectivity Matrix with Bi-directional Symmetry.........22
103 A.5. Priority Flags in Available/Shared Backup Labels.........24
104 6. References....................................................26
105 6.1. Normative References.....................................26
106 6.2. Informative References...................................26
107 7. Contributors..................................................28
108 Authors' Addresses...............................................29
109 Intellectual Property Statement..................................30
110 Disclaimer of Validity...........................................30
112 1. Introduction
114 Some data plane technologies that wish to make use of a GMPLS
115 control plane contain additional constraints on switching capability
116 and label assignment. In addition, some of these technologies must
117 perform non-local label assignment based on the nature of the
118 technology, e.g., wavelength continuity constraint in WSON [WSON-
119 Frame]. Such constraints can lead to the requirement for link by
120 link label availability in path computation and label assignment.
122 This document provides efficient encodings of information needed by
123 the routing and label assignment process in technologies such as
124 WSON and are potentially applicable to a wider range of
125 technologies. Such encodings can be used to extend GMPLS signaling
126 and routing protocols. In addition these encodings could be used by
127 other mechanisms to convey this same information to a path
128 computation element (PCE).
130 1.1. Node Switching Asymmetry Constraints
132 For some network elements the ability of a signal or packet on a
133 particular input port to reach a particular output port may be
134 limited. In addition, in some network elements the connectivity
135 between some input ports and output ports may be fixed, e.g., a
136 simple multiplexer. To take into account such constraints during
137 path computation we model this aspect of a network element via a
138 connectivity matrix.
140 The connectivity matrix (ConnectivityMatrix) represents either the
141 potential connectivity matrix for asymmetric switches or fixed
142 connectivity for an asymmetric device such as a multiplexer. Note
143 that this matrix does not represent any particular internal blocking
144 behavior but indicates which input ports and labels (e.g.,
145 wavelengths) could possibly be connected to a particular output
146 port. Representing internal state dependent blocking for a node is
147 beyond the scope of this document and due to it's highly
148 implementation dependent nature would most likely not be subject to
149 standardization in the future. The connectivity matrix is a
150 conceptual M by N matrix representing the potential switched or
151 fixed connectivity, where M represents the number of input ports and
152 N the number of output ports.
154 1.2. Non-Local Label Assignment Constraints
156 If the nature of the equipment involved in a network results in a
157 requirement for non-local label assignment we can have constraints
158 based on limits imposed by the ports themselves and those that are
159 implied by the current label usage. Note that constraints such as
160 these only become important when label assignment has a non-local
161 character. For example in MPLS an LSR may have a limited range of
162 labels available for use on an output port and a set of labels
163 already in use on that port and hence unavailable for use. This
164 information, however, does not need to be shared unless there is
165 some limitation on the LSR's label swapping ability. For example if
166 a TDM node lacks the ability to perform time-slot interchange or a
167 WSON lacks the ability to perform wavelength conversion then the
168 label assignment process is not local to a single node and it may be
169 advantageous to share the label assignment constraint information
170 for use in path computation.
172 Port label restrictions (PortLabelRestriction) model the label
173 restrictions that the network element (node) and link may impose on
174 a port. These restrictions tell us what labels may or may not be
175 used on a link and are intended to be relatively static. More
176 dynamic information is contained in the information on available
177 labels. Port label restrictions are specified relative to the port
178 in general or to a specific connectivity matrix for increased
179 modeling flexibility. Reference [Switch] gives an example where both
180 switch and fixed connectivity matrices are used and both types of
181 constraints occur on the same port.
183 2. Encoding
185 This section provides encodings for the information elements defined
186 in [RWA-Info] that have applicability to WSON. The encodings are
187 designed to be suitable for use in the GMPLS routing protocols OSPF
188 [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP)
189 [RFC5440]. Note that the information distributed in [RFC4203] and
190 [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
191 this document defines elements to be used within such constructs.
192 Specific constructs of sub-TLVs and the nesting of sub-TLVs of the
193 information element defined by this document will be defined in the
194 respective protocol enhancement documents.
196 2.1. Connectivity Matrix Field
198 The Connectivity Matrix Field represents how input ports are
199 connected to output ports for network elements. The switch and fixed
200 connectivity matrices can be compactly represented in terms of a
201 minimal list of input and output port set pairs that have mutual
202 connectivity. As described in [Switch] such a minimal list
203 representation leads naturally to a graph representation for path
204 computation purposes that involves the fewest additional nodes and
205 links.
207 A TLV encoding of this list of link set pairs is:
209 0 1 2 3
210 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
211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
212 | Connectivity | MatrixID | Reserved |
213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
214 | Link Set A #1 |
215 : : :
216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
217 | Link Set B #1 :
218 : : :
219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
220 | Additional Link set pairs as needed |
221 : to specify connectivity :
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224 Where
226 Connectivity is the device type.
228 0 -- the device is fixed
230 1 -- the device is switched(e.g., ROADM/OXC)
232 MatrixID represents the ID of the connectivity matrix and is an 8
233 bit integer. The value of 0xFF is reserved for use with port
234 wavelength constraints and should not be used to identify a
235 connectivity matrix.
237 Link Set A #1 and Link Set B #1 together represent a pair of link
238 sets. See Section 2.3. for a detail description of the link set
239 field. There are two permitted combinations for the link set field
240 parameter "dir" for Link Set A and B pairs:
242 o Link Set A dir=input, Link Set B dir=output
244 The meaning of the pair of link sets A and B in this case is that
245 any signal that inputs a link in set A can be potentially switched
246 out of an output link in set B.
248 o Link Set A dir=bidirectional, Link Set B dir=bidirectional
250 The meaning of the pair of link sets A and B in this case is that
251 any signal that inputs on the links in set A can potentially
252 output on a link in set B, and any input signal on the links in
253 set B can potentially output on a link in set A.
255 See Appendix A for both types of encodings as applied to a ROADM
256 example.
258 2.2. Port Label Restriction Field
260 Port Label Restriction Field tells us what labels may or may not be
261 used on a link.
263 The port label restriction can be encoded as follows: More than one
264 of these fields may be needed to fully specify a complex port
265 constraint. When more than one of these fields are present the
266 resulting restriction is the intersection of the restrictions
267 expressed in each field. To indicate that a restriction applies to
268 the port in general and not to a specific connectivity matrix use
269 the reserved value of 0xFF for the MatrixID.
271 0 1 2 3
272 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
273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
274 | MatrixID |RestrictionType| Switching Cap | Encoding |
275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
276 | Additional Restriction Parameters per RestrictionType |
277 : :
278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
280 Where:
282 MatrixID: either is the value in the corresponding Connectivity
283 Matrix field or takes the value OxFF to indicate the restriction
284 applies to the port regardless of any Connectivity Matrix.
286 RestrictionType can take the following values and meanings:
288 0: SIMPLE_LABEL (Simple label selective restriction)
290 1: CHANNEL_COUNT (Channel count restriction)
292 2: LABEL_RANGE (Label range device with a movable center label
293 and width)
295 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL
296 and CHANNEL_COUNT restriction. The accompanying label set and
297 channel count indicate labels permitted on the port and the
298 maximum number of channels that can be simultaneously used on
299 the port)
301 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once
302 amongst a set of specified ports)
304 Switching Capability is defined in [RFC4203] and Encoding in
305 [RFC3471]. The combination of these fields defines the type of
306 labels used in specifying the port label restrictions as well as the
307 interface type to which these restrictions apply.
309 2.2.1. SIMPLE_LABEL
311 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
312 MatrixSpecificRestrictions) format is given by:
314 0 1 2 3
315 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
316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
317 | MatrixID | RstType = 0 | Switching Cap | Encoding |
318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319 | Label Set Field |
320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322 In this case the accompanying label set indicates the labels
323 permitted on the port.
325 2.2.2. CHANNEL_COUNT
327 In the case of the CHANNEL_COUNT the format is given by:
329 0 1 2 3
330 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
331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
332 | MatrixID | RstType = 1 | Switching Cap | Encoding |
333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
334 | MaxNumChannels |
335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
337 In this case the accompanying MaxNumChannels indicates the maximum
338 number of channels (labels) that can be simultaneously used on the
339 port/matrix.
341 2.2.3. LABEL_RANGE
343 In the case of the LABEL_RANGE the GeneralPortRestrictions (or
344 MatrixSpecificRestrictions) format is given by:
346 0 1 2 3
347 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
348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
349 | MatrixID | RstType = 2 |Switching Cap | Encoding |
350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
351 | MaxLabelRange |
352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
353 | Label Set Field |
354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
356 In this case the accompanying MaxLabelRange indicates the maximum
357 range of the labels. The corresponding label set is used to indicate
358 the overall label range. Specific center label information can be
359 obtained from dynamic label in use information. It is assumed that
360 both center label and range tuning can be done without causing
361 faults to existing signals.
363 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT
365 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given
366 by:
368 0 1 2 3
369 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
370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
371 | MatrixID | RstType = 3 | Switching Cap | Encoding |
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 | MaxNumChannels |
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 | Label Set Field |
376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378 In this case the accompanying label set and MaxNumChannels indicate
379 labels permitted on the port and the maximum number of labels that
380 can be simultaneously used on the port.
382 2.2.5. Link Label Exclusivity
384 In the case of the Link Label Exclusivity the format is given by:
386 0 1 2 3
387 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
388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
389 | MatrixID | RstType = 4 | Switching Cap | Encoding |
390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
391 | Link Set Field |
392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
394 In this case the accompanying port set indicate that a label may be
395 used at most once among the ports in the link set field.
397 2.3. Link Set Field
399 We will frequently need to describe properties of groups of links.
400 To do so efficiently we can make use of a link set concept similar
401 to the label set concept of [RFC3471]. This Link Set Field is used
402 in the <ConnectivityMatrix>, which is defined in Section 2.1. The
403 information carried in a Link Set is defined by:
405 0 1 2 3
406 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
407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408 | Action |Dir| Format | Length |
409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410 | Link Identifier 1 |
411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
412 : : :
413 : : :
414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
415 | Link Identifier N |
416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
418 Action: 8 bits
420 0 - Inclusive List
422 Indicates that one or more link identifiers are included in the Link
423 Set. Each identifies a separate link that is part of the set.
425 1 - Inclusive Range
427 Indicates that the Link Set defines a range of links. It contains
428 two link identifiers. The first identifier indicates the start of
429 the range (inclusive). The second identifier indicates the end of
430 the range (inclusive). All links with numeric values between the
431 bounds are considered to be part of the set. A value of zero in
432 either position indicates that there is no bound on the
433 corresponding portion of the range. Note that the Action field can
434 be set to 0x01(Inclusive Range) only when unnumbered link identifier
435 is used.
437 Dir: Directionality of the Link Set (2 bits)
439 0 -- bidirectional
441 1 -- input
443 2 -- output
445 For example in optical networks we think in terms of unidirectional
446 as well as bidirectional links. For example, label restrictions or
447 connectivity may be different for an input port, than for its
448 "companion" output port if one exists. Note that "interfaces" such
449 as those discussed in the Interfaces MIB [RFC2863] are assumed to be
450 bidirectional. This also applies to the links advertised in various
451 link state routing protocols.
453 Format: The format of the link identifier (6 bits)
455 0 -- Link Local Identifier
457 Indicates that the links in the Link Set are identified by link
458 local identifiers. All link local identifiers are supplied in the
459 context of the advertising node.
461 1 -- Local Interface IPv4 Address
463 2 -- Local Interface IPv6 Address
465 Indicates that the links in the Link Set are identified by Local
466 Interface IP Address. All Local Interface IP Address are supplied in
467 the context of the advertising node.
469 Others TBD.
471 Note that all link identifiers in the same list must be of the same
472 type.
474 Length: 16 bits
476 This field indicates the total length in bytes of the Link Set field.
478 Link Identifier: length is dependent on the link format
480 The link identifier represents the port which is being described
481 either for connectivity or label restrictions. This can be the link
482 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF
483 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link
484 local identifier format can result in more compact encodings when
485 the assignments are done in a reasonable fashion.
487 2.4. Available Labels Field
489 The Available Labels Field consists of priority flags, and a single
490 variable length label set field as follows:
492 0 1 2 3
493 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
494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
495 | PRI | Reserved |
496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
497 | Label Set Field |
498 : :
499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
501 Where
503 PRI (Priority Flags, 8 bits): A bitmap used to indicate which
504 priorities are being advertised. The bitmap is in ascending order,
505 with the leftmost bit representing priority level 0 (i.e., the
506 highest) and the rightmost bit representing priority level 7 (i.e.,
507 the lowest). A bit MUST be set (1) corresponding to each priority
508 represented in the sub-TLV, and MUST NOT be set (0) when the
509 corresponding priority is not represented. At least one priority
510 level MUST be advertised that, unless overridden by local policy,
511 SHALL be at priority level 0.
513 Note that Label Set Field is defined in Section 2.6. See Appendix
514 A.5. for illustrative examples.
516 2.5. Shared Backup Labels Field
518 The Shared Backup Labels Field consists of priority flags, and
519 single variable length label set field as follows:
521 0 1 2 3
522 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
523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
524 | PRI | Reserved |
525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
526 | Label Set Field |
527 : :
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 Where
532 PRI (Priority Flags, 8 bits): A bitmap used to indicate which
533 priorities are being advertised. The bitmap is in ascending order,
534 with the leftmost bit representing priority level 0 (i.e., the
535 highest) and the rightmost bit representing priority level 7 (i.e.,
536 the lowest). A bit MUST be set (1) corresponding to each priority
537 represented in the sub-TLV, and MUST NOT be set (0) when the
538 corresponding priority is not represented. At least one priority
539 level MUST be advertised that, unless overridden by local policy,
540 SHALL be at priority level 0.
542 Note that Label Set Field is defined in Section 2.6. See Appendix
543 A.5. for illustrative examples.
545 2.6. Label Set Field
547 Label Set Field is used within the <AvailableLabels> or the
548 <SharedBackupLabels>, which is defined in Section 2.4. and 2.5.,
549 respectively.
551 The general format for a label set is given below. This format uses
552 the Action concept from [RFC3471] with an additional Action to
553 define a "bit map" type of label set. Labels are variable in length.
554 Action specific fields are defined below.
556 0 1 2 3
558 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
559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
560 | Action| Num Labels | Length |
561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
562 | Base Label |
563 | . . . |
564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
565 | (Action specific fields) |
566 | . . . . |
567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
569 Action:
571 0 - Inclusive List
573 1 - Exclusive List
575 2 - Inclusive Range
577 3 - Exclusive Range
579 4 - Bitmap Set
581 Length is the length in bytes of the entire field.
583 2.6.1. Inclusive/Exclusive Label Lists
585 In the case of the inclusive/exclusive lists the wavelength set
586 format is given by:
588 0 1 2 3
589 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
590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
591 |0 or 1 | Num Labels | Length |
592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
593 | Label #1 |
594 | . . . |
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 : :
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 | Label #N |
599 | . . . |
600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
602 Where:
604 Label #1 is the first Label to be included/excluded and Label #N is
605 the last Label to be included/excluded. Num Labels MUST match with
606 N.
608 2.6.2. Inclusive/Exclusive Label Ranges
610 In the case of inclusive/exclusive ranges the label set format is
611 given by:
613 0 1 2 3
614 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
615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
616 |2 or 3 | Num Labels | Length |
617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
618 | Start Label |
619 | . . . |
620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
621 | End Label |
622 | . . . |
623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
625 Note that that Start Label is the first Label in the range to be
626 included/excluded and End Label is the last label in the same range.
627 Num Labels MUST be two.
629 2.6.3. Bitmap Label Set
631 In the case of Action = 4, the bitmap the label set format is given
632 by:
634 0 1 2 3
635 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
636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
637 | 4 | Num Labels | Length |
638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639 | Base Label |
640 | . . . |
641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
642 | Bit Map Word #1 (Lowest numerical labels) |
643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
644 : :
645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
646 | Bit Map Word #N (Highest numerical labels) |
647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
649 Where Num Labels in this case tells us the number of labels
650 represented by the bit map. Each bit in the bit map represents a
651 particular label with a value of 1/0 indicating whether the label is
652 in the set or not. Bit position zero represents the lowest label and
653 corresponds to the base label, while each succeeding bit position
654 represents the next label logically above the previous.
656 The size of the bit map is Num Label bits, but the bit map is padded
657 out to a full multiple of 32 bits so that the field is a multiple of
658 four bytes. Bits that do not represent labels (i.e., those in
659 positions (Num Labels) and beyond SHOULD be set to zero and MUST be
660 ignored.
662 3. Security Considerations
664 This document defines protocol-independent encodings for WSON
665 information and does not introduce any security issues.
667 However, other documents that make use of these encodings within
668 protocol extensions need to consider the issues and risks associated
669 with, inspection, interception, modification, or spoofing of any of
670 this information. It is expected that any such documents will
671 describe the necessary security measures to provide adequate
672 protection. A general discussion on security in GMPLS networks can
673 be found in [RFC5920].
675 4. IANA Considerations
677 This document provides general protocol independent information
678 encodings. There is no IANA allocation request for the information
679 elements defined in this document. IANA allocation requests will be
680 addressed in protocol specific documents based on the encodings
681 defined here.
683 5. Acknowledgments
685 This document was prepared using 2-Word-v2.0.template.dot.
687 APPENDIX A: Encoding Examples
689 Here we give examples of the general encoding extensions applied to
690 some simple ROADM network elements and links.
692 A.1. Link Set Field
694 Suppose that we wish to describe a set of input ports that are have
695 link local identifiers number 3 through 42. In the link set field we
696 set the Action = 1 to denote an inclusive range; the Dir = 1 to
697 denote input links; and, the Format = 0 to denote link local
698 identifiers. In particular we have:
700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
701 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
703 | Link Local Identifier = #3 |
704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
705 | Link Local Identifier = #42 |
706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
708 A.2. Label Set Field
710 Example:
712 A 40 channel C-Band DWDM system with 100GHz spacing with lowest
713 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz
714 (1530.3nm). These frequencies correspond to n = -11, and n = 28
715 respectively. Now suppose the following channels are available:
717 Frequency (THz) n Value bit map position
718 --------------------------------------------------
719 192.0 -11 0
720 192.5 -6 5
721 193.1 0 11
722 193.9 8 19
723 194.0 9 20
724 195.2 21 32
725 195.8 27 38
727 Using the label format defined in [RFC6205], with the Grid value set
728 to indicate an ITU-T G.694.1 DWDM grid, C.S. set to indicate 100GHz
729 this lambda bit map set would then be encoded as follows:
731 0 1 2 3
732 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
733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
734 | 4 | Num Labels = 40 | Length = 16 bytes |
735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
736 |Grid | C.S. | Reserved | n for lowest frequency = -11 |
737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738 |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|
739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) |
741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
743 To encode this same set as an inclusive list we would have:
745 0 1 2 3
746 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
747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748 | 0 | Num Labels = 7 | Length = 20 bytes |
749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
750 |Grid | C.S. | Reserved | n for lowest frequency = -11 |
751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
752 |Grid | C.S. | Reserved | n for lowest frequency = -6 |
753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
754 |Grid | C.S. | Reserved | n for lowest frequency = -0 |
755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
756 |Grid | C.S. | Reserved | n for lowest frequency = 8 |
757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
758 |Grid | C.S. | Reserved | n for lowest frequency = 9 |
759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
760 |Grid | C.S. | Reserved | n for lowest frequency = 21 |
761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
762 |Grid | C.S. | Reserved | n for lowest frequency = 27 |
763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
765 A.3. Connectivity Matrix
767 Example:
769 Suppose we have a typical 2-degree 40 channel ROADM. In addition to
770 its two line side ports it has 80 add and 80 drop ports. The picture
771 below illustrates how a typical 2-degree ROADM system that works
772 with bi-directional fiber pairs is a highly asymmetrical system
773 composed of two unidirectional ROADM subsystems.
775 (Tributary) Ports #3-#42
776 Input added to Output dropped from
777 West Line Output East Line Input
778 vvvvv ^^^^^
779 | |||.| | |||.|
780 +-----| |||.|--------| |||.|------+
781 | +----------------------+ |
782 | | | |
783 Output | | Unidirectional ROADM | | Input
784 -----------------+ | | +--------------
785 <=====================| |===================<
786 -----------------+ +----------------------+ +--------------
787 | |
788 Port #1 | | Port #2
789 (West Line Side) | |(East Line Side)
790 -----------------+ +----------------------+ +--------------
791 >=====================| |===================>
792 -----------------+ | Unidirectional ROADM | +--------------
793 Input | | | | Output
794 | | _ | |
795 | +----------------------+ |
796 +-----| |||.|--------| |||.|------+
797 | |||.| | |||.|
798 vvvvv ^^^^^
799 (Tributary) Ports #43-#82
800 Output dropped from Input added to
801 West Line Input East Line Output
803 Referring to the figure we see that the Input direction of ports #3-
804 #42 (add ports) can only connect to the output on port #1. While the
805 Input side of port #2 (line side) can only connect to the output on
806 ports #3-#42 (drop) and to the output on port #1 (pass through).
807 Similarly, the input direction of ports #43-#82 can only connect to
808 the output on port #2 (line). While the input direction of port #1
809 can only connect to the output on ports #43-#82 (drop) or port #2
810 (pass through). We can now represent this potential connectivity
811 matrix as follows. This representation uses only 30 32-bit words.
813 0 1 2 3
814 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
815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
816 | Conn = 1 | MatrixID | Reserved |
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
818 Note: adds to line
819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
820 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
822 | Link Local Identifier = #3 |
823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
824 | Link Local Identifier = #42 |
825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
826 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
828 | Link Local Identifier = #1 |
829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
830 Note: line to drops
831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
832 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |
833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
834 | Link Local Identifier = #2 |
835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
836 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |
837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
838 | Link Local Identifier = #3 |
839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
840 | Link Local Identifier = #42 |
841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
842 Note: line to line
843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
844 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |
845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
846 | Link Local Identifier = #2 |
847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
848 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
850 | Link Local Identifier = #1 |
851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
852 Note: adds to line
853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
854 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |
855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
856 | Link Local Identifier = #43 |
857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858 | Link Local Identifier = #82 |
859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
860 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
862 | Link Local Identifier = #2 |
863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 Note: line to drops
865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |
867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
868 | Link Local Identifier = #1 |
869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
870 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |
871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
872 | Link Local Identifier = #43 |
873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
874 | Link Local Identifier = #82 |
875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
876 Note: line to line
877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
878 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |
879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
880 | Link Local Identifier = #1 |
881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
882 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |
883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
884 | Link Local Identifier = #2 |
885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
887 A.4. Connectivity Matrix with Bi-directional Symmetry
889 If one has the ability to renumber the ports of the previous example
890 as shown in the next figure then we can take advantage of the bi-
891 directional symmetry and use bi-directional encoding of the
892 connectivity matrix. Note that we set dir=bidirectional in the link
893 set fields.
895 (Tributary)
896 Ports #3-42 Ports #43-82
897 West Line Output East Line Input
898 vvvvv ^^^^^
899 | |||.| | |||.|
900 +-----| |||.|--------| |||.|------+
901 | +----------------------+ |
902 | | | |
903 Output | | Unidirectional ROADM | | Input
904 -----------------+ | | +--------------
905 <=====================| |===================<
906 -----------------+ +----------------------+ +--------------
907 | |
908 Port #1 | | Port #2
909 (West Line Side) | |(East Line Side)
910 -----------------+ +----------------------+ +--------------
911 >=====================| |===================>
912 -----------------+ | Unidirectional ROADM | +--------------
913 Input | | | | Output
914 | | _ | |
915 | +----------------------+ |
916 +-----| |||.|--------| |||.|------+
917 | |||.| | |||.|
918 vvvvv ^^^^^
919 Ports #3-#42 Ports #43-82
920 Output dropped from Input added to
921 West Line Input East Line Output
923 0 1 2 3
924 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
925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
926 | Conn = 1 | MatrixID | Reserved |
927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
928 Add/Drops #3-42 to Line side #1
929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
930 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |
931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
932 | Link Local Identifier = #3 |
933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
934 | Link Local Identifier = #42 |
935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
936 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
938 | Link Local Identifier = #1 |
939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
940 Note: line #2 to add/drops #43-82
941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
942 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
944 | Link Local Identifier = #2 |
945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
946 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |
947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
948 | Link Local Identifier = #43 |
949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
950 | Link Local Identifier = #82 |
951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
952 Note: line to line
953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
954 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
956 | Link Local Identifier = #1 |
957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
958 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |
959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
960 | Link Local Identifier = #2 |
961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
963 A.5. Priority Flags in Available/Shared Backup Labels
965 If one wants to make a set of labels (indicated by Label Set Field
966 #1) available only for the highest priority level (Priority Level 0)
967 while allowing a set of labels (indicated by Label Set Field #2)
968 available to all priority levels, the following encoding will
969 express such need.
971 0 1 2 3
972 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
973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
974 |0 0 0 1 0 0 0 0| Reserved |
975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
976 | Label Set Field #1 |
977 : :
978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
979 |1 1 1 1 0 0 0 0| Reserved |
980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
981 | Label Set Field #2 |
982 : :
983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
985 6. References
987 6.1. Normative References
989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
990 Requirement Levels", BCP 14, RFC 2119, March 1997.
992 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
993 MIB", RFC 2863, June 2000.
995 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
996 (GMPLS) Signaling Functional Description", RFC 3471,
997 January 2003.
999 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
1000 applications: DWDM frequency grid", June, 2002.
1002 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
1003 Extensions in Support of Generalized Multi-Protocol Label
1004 Switching (GMPLS)", RFC 4202, October 2005
1006 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
1007 in Support of Generalized Multi-Protocol Label Switching
1008 (GMPLS)", RFC 4203, October 2005.
1010 [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for
1011 Lambda-Switch-Capable (LSC) Label Switching Routers", RFC
1012 6205, March 2011.
1014 6.2. Informative References
1016 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
1017 applications: DWDM frequency grid, June 2002.
1019 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
1020 applications: CWDM wavelength grid, December 2003.
1022 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
1023 in Support of Generalized Multi-Protocol Label Switching
1024 (GMPLS)", RFC 5307, October 2008.
1026 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path
1027 Computation Element (PCE) communication Protocol (PCEP) -
1028 Version 1", RFC5440.
1030 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS
1031 Networks", RFC 5920, July 2010.
1033 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling
1034 WDM Wavelength Switching Systems for Use in GMPLS and
1035 Automated Path Computation", Journal of Optical
1036 Communications and Networking, vol. 1, June, 2009, pp.
1037 187-195.
1039 [RWA-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
1040 Wavelength Assignment Information Model for Wavelength
1041 Switched Optical Networks", work in progress: draft-ietf-
1042 ccamp-rwa-info.
1044 7. Contributors
1046 Diego Caviglia
1047 Ericsson
1048 Via A. Negrone 1/A 16153
1049 Genoa Italy
1051 Phone: +39 010 600 3736
1052 Email: diego.caviglia@ericsson.com
1054 Anders Gavler
1055 Acreo AB
1056 Electrum 236
1057 SE - 164 40 Kista Sweden
1059 Email: Anders.Gavler@acreo.se
1061 Jonas Martensson
1062 Acreo AB
1063 Electrum 236
1064 SE - 164 40 Kista, Sweden
1066 Email: Jonas.Martensson@acreo.se
1068 Itaru Nishioka
1069 NEC Corp.
1070 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666
1071 Japan
1073 Phone: +81 44 396 3287
1074 Email: i-nishioka@cb.jp.nec.com
1076 Rao Rajan
1077 Infinera
1079 Email: rrao@infinera.com
1081 Giovanni Martinelli
1082 CISCO
1084 Email: giomarti@cisco.com
1086 Remi Theillaud
1087 Marben
1088 remi.theillaud@marben-products.com
1090 Authors' Addresses
1092 Greg M. Bernstein (ed.)
1093 Grotto Networking
1094 Fremont California, USA
1096 Phone: (510) 573-2237
1097 Email: gregb@grotto-networking.com
1099 Young Lee (ed.)
1100 Huawei Technologies
1101 1700 Alma Drive, Suite 100
1102 Plano, TX 75075
1103 USA
1105 Phone: (972) 509-5599 (x2240)
1106 Email: ylee@huawei.com
1108 Dan Li
1109 Huawei Technologies Co., Ltd.
1110 F3-5-B R&D Center, Huawei Base,
1111 Bantian, Longgang District
1112 Shenzhen 518129 P.R.China
1114 Phone: +86-755-28973237
1115 Email: danli@huawei.com
1117 Wataru Imajuku
1118 NTT Network Innovation Labs
1119 1-1 Hikari-no-oka, Yokosuka, Kanagawa
1120 Japan
1122 Phone: +81-(46) 859-4315
1123 Email: imajuku.wataru@lab.ntt.co.jp
1124 Jianrui Han
1125 Huawei Technologies Co., Ltd.
1126 F3-5-B R&D Center, Huawei Base,
1127 Bantian, Longgang District
1128 Shenzhen 518129 P.R.China
1130 Phone: +86-755-28972916
1131 Email: hanjianrui@huawei.com
1133 Intellectual Property Statement
1135 The IETF Trust takes no position regarding the validity or scope of
1136 any Intellectual Property Rights or other rights that might be
1137 claimed to pertain to the implementation or use of the technology
1138 described in any IETF Document or the extent to which any license
1139 under such rights might or might not be available; nor does it
1140 represent that it has made any independent effort to identify any
1141 such rights.
1143 Copies of Intellectual Property disclosures made to the IETF
1144 Secretariat and any assurances of licenses to be made available, or
1145 the result of an attempt made to obtain a general license or
1146 permission for the use of such proprietary rights by implementers or
1147 users of this specification can be obtained from the IETF on-line
1148 IPR repository at http://www.ietf.org/ipr
1150 The IETF invites any interested party to bring to its attention any
1151 copyrights, patents or patent applications, or other proprietary
1152 rights that may cover technology that may be required to implement
1153 any standard or specification contained in an IETF Document. Please
1154 address the information to the IETF at ietf-ipr@ietf.org.
1156 Disclaimer of Validity
1158 All IETF Documents and the information contained therein are
1159 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
1160 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
1161 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
1162 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
1163 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
1164 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
1165 FOR A PARTICULAR PURPOSE.
1167 Acknowledgment
1169 Funding for the RFC Editor function is currently provided by the
1170 Internet Society.