idnits 2.13.01
tmp/draft-ietf-ccamp-rwa-info-20.txt:
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:
----------------------------------------------------------------------------
== Line 396 has weird spacing: '...t fiber eac...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.)
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group Y. Lee
2 Internet Draft Huawei
3 Intended status: Informational G. Bernstein
4 Expires: July 2014 Grotto Networking
5 D. Li
6 Huawei
7 W. Imajuku
8 NTT
10 January 29, 2014
12 Routing and Wavelength Assignment Information Model for Wavelength
13 Switched Optical Networks
15 draft-ietf-ccamp-rwa-info-20.txt
17 Status of this Memo
19 This Internet-Draft is submitted to IETF in full conformance with
20 the provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six
28 months and may be updated, replaced, or obsoleted by other documents
29 at any time. It is inappropriate to use Internet-Drafts as
30 reference material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html
38 This Internet-Draft will expire on July 29, 2014.
40 Copyright Notice
42 Copyright (c) 2014 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with
50 respect to this document. Code Components extracted from this
51 document must include Simplified BSD License text as described in
52 Section 4.e of the Trust Legal Provisions and are provided without
53 warranty as described in the Simplified BSD License.
55 Abstract
57 This document provides a model of information needed by the routing
58 and wavelength assignment (RWA) process in wavelength switched
59 optical networks (WSONs). The purpose of the information described
60 in this model is to facilitate constrained lightpath computation in
61 WSONs. This model takes into account compatibility constraints
62 between WSON signal attributes and network elements but does not
63 include constraints due to optical impairments. Aspects of this
64 information that may be of use to other technologies utilizing a
65 GMPLS control plane are discussed.
67 Table of Contents
69 1. Introduction...................................................3
70 2. Terminology....................................................3
71 3. Routing and Wavelength Assignment Information Model............4
72 3.1. Dynamic and Relatively Static Information.................4
73 4. Node Information (General).....................................4
74 4.1. Connectivity Matrix.......................................5
75 5. Node Information (WSON specific)...............................6
76 5.1. Resource Accessibility/Availability.......................7
77 5.2. Resource Signal Constraints and Processing Capabilities..11
78 5.3. Compatibility and Capability Details.....................12
79 5.3.1. Shared Input or Output Indication...................12
80 5.3.2. Optical Interface Class List........................12
81 5.3.3. Acceptable Client Signal List.......................12
82 5.3.4. Processing Capability List..........................12
83 6. Link Information (General)....................................13
84 6.1. Administrative Group.....................................13
85 6.2. Interface Switching Capability Descriptor................14
86 6.3. Link Protection Type (for this link).....................14
87 6.4. Shared Risk Link Group Information.......................14
88 6.5. Traffic Engineering Metric...............................14
89 6.6. Port Label Restrictions..................................14
90 6.6.1. Port-Wavelength Exclusivity Example.................17
91 7. Dynamic Components of the Information Model...................18
92 7.1. Dynamic Link Information (General).......................19
93 7.2. Dynamic Node Information (WSON Specific).................19
94 8. Security Considerations.......................................19
95 9. IANA Considerations...........................................20
96 10. Acknowledgments..............................................20
97 11. References...................................................21
98 11.1. Normative References....................................21
99 11.2. Informative References..................................22
100 12. Contributors.................................................23
101 Author's Addresses...............................................24
102 Intellectual Property Statement..................................24
103 Disclaimer of Validity...........................................25
105 1. Introduction
107 The purpose of the following information model for WSONs is to
108 facilitate constrained lightpath computation and as such is not a
109 general purpose network management information model. This
110 constraint is frequently referred to as the "wavelength continuity"
111 constraint, and the corresponding constrained lightpath computation
112 is known as the routing and wavelength assignment (RWA) problem.
113 Hence the information model must provide sufficient topology and
114 wavelength restriction and availability information to support this
115 computation. More details on the RWA process and WSON subsystems and
116 their properties can be found in [RFC6163]. The model defined here
117 includes constraints between WSON signal attributes and network
118 elements, but does not include optical impairments.
120 In addition to presenting an information model suitable for path
121 computation in WSON, this document also highlights model aspects
122 that may have general applicability to other technologies utilizing
123 a GMPLS control plane. The portion of the information model
124 applicable to other technologies beyond WSON is referred to as
125 "general" to distinguish it from the "WSON-specific" portion that is
126 applicable only to WSON technology.
128 2. Terminology
130 Refer to [RFC6163] for ROADM, RWA, Wavelength Conversion, WDM and
131 WSON.
133 3. Routing and Wavelength Assignment Information Model
135 The following WSON RWA information model is grouped into four
136 categories regardless of whether they stem from a switching
137 subsystem or from a line subsystem:
139 o Node Information
141 o Link Information
143 o Dynamic Node Information
145 o Dynamic Link Information
147 Note that this is roughly the categorization used in [G.7715]
148 section 7.
150 In the following, where applicable, the reduced Backus-Naur form
151 (RBNF) syntax of [RBNF] is used to aid in defining the RWA
152 information model.
154 3.1. Dynamic and Relatively Static Information
156 All the RWA information of concern in a WSON network is subject to
157 change over time. Equipment can be upgraded; links may be placed in
158 or out of service and the like. However, from the point of view of
159 RWA computations there is a difference between information that can
160 change with each successive connection establishment in the network
161 and that information that is relatively static and independent of
162 connection establishment. A key example of the former is link
163 wavelength usage since this can change with connection
164 setup/teardown and this information is a key input to the RWA
165 process. Examples of relatively static information are the
166 potential port connectivity of a WDM ROADM, and the channel spacing
167 on a WDM link.
169 This document separates, where possible, dynamic and static
170 information so that these can be kept separate in possible encodings
171 and hence allowing for separate updates of these two types of
172 information thereby reducing processing and traffic load caused by
173 the timely distribution of the more dynamic RWA WSON information.
175 4. Node Information (General)
177 The node information described here contains the relatively static
178 information related to a WSON node. This includes connectivity
179 constraints amongst ports and wavelengths since WSON switches can
180 exhibit asymmetric switching properties. Additional information
181 could include properties of wavelength converters in the node if any
182 are present. In [Switch] it was shown that the wavelength
183 connectivity constraints for a large class of practical WSON devices
184 can be modeled via switched and fixed connectivity matrices along
185 with corresponding switched and fixed port constraints. These
186 connectivity matrices are included with the node information while
187 the switched and fixed port wavelength constraints are included with
188 the link information.
190 Formally,
192 <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]
194 Where the Node_ID would be an appropriate identifier for the node
195 within the WSON RWA context.
197 Note that multiple connectivity matrices are allowed and hence can
198 fully support the most general cases enumerated in [Switch].
200 4.1. Connectivity Matrix
202 The connectivity matrix (ConnectivityMatrix) represents either the
203 potential connectivity matrix for asymmetric switches (e.g. ROADMs
204 and such) or fixed connectivity for an asymmetric device such as a
205 multiplexer. Note that this matrix does not represent any particular
206 internal blocking behavior but indicates which input ports and
207 wavelengths could possibly be connected to a particular output port.
208 Representing internal state dependent blocking for a switch or ROADM
209 is beyond the scope of this document and due to its highly
210 implementation dependent nature would most likely not be subject to
211 standardization in the future. The connectivity matrix is a
212 conceptual M by N matrix representing the potential switched or
213 fixed connectivity, where M represents the number of input ports and
214 N the number of output ports. This is a "conceptual" matrix since
215 the matrix tends to exhibit structure that allows for very compact
216 representations that are useful for both transmission and path
217 computation.
219 Note that the connectivity matrix information element can be useful
220 in any technology context where asymmetric switches are utilized.
222 <ConnectivityMatrix> ::= <MatrixID> <ConnType> <Matrix>
224 Where
225 <MatrixID> is a unique identifier for the matrix.
227 <ConnType> can be either 0 or 1 depending upon whether the
228 connectivity is either fixed or switched.
230 <Matrix> represents the fixed or switched connectivity in that
231 Matrix(i, j) = 0 or 1 depending on whether input port i can connect
232 to output port j for one or more wavelengths.
234 5. Node Information (WSON specific)
236 As discussed in [RFC6163] a WSON node may contain electro-optical
237 subsystems such as regenerators, wavelength converters or entire
238 switching subsystems. The model present here can be used in
239 characterizing the accessibility and availability of limited
240 resources such as regenerators or wavelength converters as well as
241 WSON signal attribute constraints of electro-optical subsystems. As
242 such this information element is fairly specific to WSON
243 technologies.
245 A WSON node may include regenerators or wavelength converters
246 arranged in a shared pool. As discussed in [RFC6163] this can
247 include OEO based WDM switches as well. There are a number of
248 different approaches used in the design of WDM switches containing
249 regenerator or converter pools. However, from the point of view of
250 path computation the following need to be known:
252 1. The nodes that support regeneration or wavelength conversion.
254 2. The accessibility and availability of a wavelength converter to
255 convert from a given input wavelength on a particular input port
256 to a desired output wavelength on a particular output port.
258 3. Limitations on the types of signals that can be converted and the
259 conversions that can be performed.
261 Since resources tend to be packaged together in blocks of similar
262 devices, e.g., on line cards or other types of modules, the
263 fundamental unit of identifiable resource in this document is the
264 "resource block". A resource block may contain one or more
265 resources. A resource is the smallest identifiable unit of
266 processing allocation. One can group together resources into blocks
267 if they have similar characteristics relevant to the optical system
268 being modeled, e.g., processing properties, accessibility, etc.
270 This leads to the following formal high level model:
272 <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]
273 [<ResourcePool>]
275 Where
277 <ResourcePool> ::= <ResourceBlockInfo>...
278 [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
279 [<RBPoolState>]
281 First the accessibility of resource blocks is addressed then their
282 properties are discussed.
284 5.1. Resource Accessibility/Availability
286 A similar technique as used to model ROADMs and optical switches can
287 be used to model regenerator/converter accessibility. This technique
288 was generally discussed in [RFC6163] and consisted of a matrix to
289 indicate possible connectivity along with wavelength constraints for
290 links/ports. Since regenerators or wavelength converters may be
291 considered a scarce resource it is desirable that the model include,
292 if desired, the usage state (availability) of individual
293 regenerators or converters in the pool. Models that incorporate more
294 state to further reveal blocking conditions on input or output to
295 particular converters are for further study and not included here.
297 The three stage model is shown schematically in Figure 1 and Figure
298 2. The difference between the two figures is that Figure 1 assumes
299 that each signal that can get to a resource block may do so, while
300 in Figure 2 the access to sets of resource blocks is via a shared
301 fiber which imposes its own wavelength collision constraint. The
302 representation of Figure 1 can have more than one input to each
303 resource block since each input represents a single wavelength
304 signal, while in Figure 2 shows a single multiplexed WDM input or
305 output, e.g., a fiber, to/from each set of block.
307 This model assumes N input ports (fibers), P resource blocks
308 containing one or more identical resources (e.g. wavelength
309 converters), and M output ports (fibers). Since not all input ports
310 can necessarily reach each resource block, the model starts with a
311 resource pool input matrix RI(i,p) = {0,1} whether input port i can
312 reach potentially reach resource block p.
314 Since not all wavelengths can necessarily reach all the resources or
315 the resources may have limited input wavelength range the model has
316 a set of relatively static input port constraints for each resource.
317 In addition, if the access to a set of resource blocks is via a
318 shared fiber (Figure 2) this would impose a dynamic wavelength
319 availability constraint on that shared fiber. The resource block
320 input port constraint is modeled via a static wavelength set
321 mechanism and the case of shared access to a set of blocks is
322 modeled via a dynamic wavelength set mechanism.
324 Next a state vector RA(j) = {0,...,k} is used to track the number of
325 resources in resource block j in use. This is the only state kept in
326 the resource pool model. This state is not necessary for modeling
327 "fixed" transponder system or full OEO switches with WDM interfaces,
328 i.e., systems where there is no sharing.
330 After that, a set of static resource output wavelength constraints
331 and possibly dynamic shared output fiber constraints maybe used. The
332 static constraints indicate what wavelengths a particular resource
333 block can generate or are restricted to generating e.g., a fixed
334 regenerator would be limited to a single lambda. The dynamic
335 constraints would be used in the case where a single shared fiber is
336 used to output the resource block (Figure 2).
338 Finally, to complete the model, a resource pool output matrix
339 RE(p,k) = {0,1} depending on whether the output from resource block
340 p can reach output port k, may be used.
342 I1 +-------------+ +-------------+ O1
343 ----->| | +--------+ | |----->
344 I2 | +------+ Rb #1 +-------+ | O2
345 ----->| | +--------+ | |----->
346 | | | |
347 | Resource | +--------+ | Resource |
348 | Pool +------+ +-------+ Pool |
349 | | + Rb #2 + | |
350 | Input +------+ +-------| Output |
351 | Connection | +--------+ | Connection |
352 | Matrix | . | Matrix |
353 | | . | |
354 | | . | |
355 IN | | +--------+ | | OM
356 ----->| +------+ Rb #P +-------+ |----->
357 | | +--------+ | |
358 +-------------+ ^ ^ +-------------+
359 | |
360 | |
361 | |
362 | |
364 Input wavelength Output wavelength
365 constraints for constraints for
366 each resource each resource
368 Figure 1 Schematic diagram of resource pool model.
370 I1 +-------------+ +-------------+ O1
371 ----->| | +--------+ | |----->
372 I2 | +======+ Rb #1 +-+ + | O2
373 ----->| | +--------+ | | |----->
374 | | |=====| |
375 | Resource | +--------+ | | Resource |
376 | Pool | +-+ Rb #2 +-+ | Pool |
377 | | | +--------+ + |
378 | Input |====| | Output |
379 | Connection | | +--------+ | Connection |
380 | Matrix | +-| Rb #3 |=======| Matrix |
381 | | +--------+ | |
382 | | . | |
383 | | . | |
384 | | . | |
385 IN | | +--------+ | | OM
386 ----->| +======+ Rb #P +=======+ |----->
387 | | +--------+ | |
388 +-------------+ ^ ^ +-------------+
389 | |
390 | |
391 | |
392 Single (shared) fibers for block input and output
394 Input wavelength Output wavelength
395 availability for availability for
396 each block input fiber each block output fiber
398 Figure 2 Schematic diagram of resource pool model with shared block
399 accessibility.
401 Formally the model can be specified as:
403 <ResourceAccessibility ::= <PoolInputMatrix> <PoolOutputMatrix>
405 <ResourceWaveConstraints> ::= <InputWaveConstraints>
406 <OutputOutputWaveConstraints>
408 <RBPoolState> ::=<ResourceBlockID> <NumResourcesInUse>
409 [<InAvailableWavelengths>] [<OutAvailableWavelengths>]
410 [<RBPoolState>]
411 Note that except for <RBPoolState> all the other components of
412 <ResourcePool> are relatively static. Also the
413 <InAvailableWavelengths> and <OutAvailableWavelengths> are only used
414 in the cases of shared input or output access to the particular
415 block. See the resource block information in the next section to see
416 how this is specified.
418 5.2. Resource Signal Constraints and Processing Capabilities
420 The wavelength conversion abilities of a resource (e.g. regenerator,
421 wavelength converter) were modeled in the <OutputWaveConstraints>
422 previously discussed. As discussed in [RFC6163] the constraints on
423 an electro-optical resource can be modeled in terms of input
424 constraints, processing capabilities, and output constraints:
426 <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>]
427 [<ProcessingCapabilities>] [<OutputConstraints>]
429 Where <ResourceBlockSet> is a list of resource block identifiers
430 with the same characteristics. If this set is missing the
431 constraints are applied to the entire network element.
433 The <InputConstraints> are signal compatibility based constraints
434 and/or shared access constraint indication. The details of these
435 constraints are defined in section 5.3.
437 <InputConstraints> ::= <SharedInput> [<OpticalInterfaceClassList>]
438 [<ClientSignalList>]
440 The <ProcessingCapabilities> are important operations that the
441 resource (or network element) can perform on the signal. The details
442 of these capabilities are defined in section 5.3.
444 <ProcessingCapabilities> ::= [<NumResources>]
445 [<RegenerationCapabilities>] [<FaultPerfMon>] [<VendorSpecific>]
447 The <OutputConstraints> are either restrictions on the properties of
448 the signal leaving the block, options concerning the signal
449 properties when leaving the resource or shared fiber output
450 constraint indication.
452 <OutputConstraints> := <SharedOutput>
453 [<OpticalInterfaceClassList>][<ClientSignalList>]
454 5.3. Compatibility and Capability Details
456 5.3.1. Shared Input or Output Indication
458 As discussed in the previous section and shown in Figure 2 the input
459 or output access to a resource block may be via a shared fiber. The
460 <SharedInput> and <SharedOutput> elements are indicators for this
461 condition with respect to the block being described.
463 5.3.2. Optical Interface Class List
465 <OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ...
467 The Optical Interface Class is a unique number that identifies
468 all information related to optical characteristics of a physical
469 interface. The class may include other optical parameters
470 related to other interface properties. A class always includes
471 signal compatibility information.
473 The content of each class is out of the scope of this draft and
474 can be defined by other entities (e.g. ITU, optical equipment
475 vendors, etc.).
477 Since even current implementation of physical interfaces may
478 support different optical characteristics, a single interface may
479 support multiple interface classes. Which optical interface
480 class is used among all the ones available for an interface is
481 out of the scope of this draft but is an output of the RWA
482 process.
484 5.3.3. Acceptable Client Signal List
486 The list is simply:
488 < ClientSignalList>::=[<G-PID>]...
490 Where the Generalized Protocol Identifiers (G-PID) object
491 represents one of the IETF standardized G-PID values as defined
492 in [RFC3471] and [RFC4328].
494 5.3.4. Processing Capability List
496 The ProcessingCapabilities were defined in Section 5.2.
498 The processing capability list sub-TLV is a list of processing
499 functions that the WSON network element (NE) can perform on the
500 signal including:
502 1. Number of Resources within the block
504 2. Regeneration capability
506 3. Fault and performance monitoring
508 4. Vendor Specific capability
510 Note that the code points for Fault and performance monitoring and
511 vendor specific capability are subject to further study.
513 6. Link Information (General)
515 MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630],
516 [RFC5305] along with GMPLS routing protocol extensions for OSPF and
517 IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static
518 link information needed by the RWA process. However, WSON networks
519 bring in additional link related constraints. These stem from WDM
520 line system characterization, laser transmitter tuning restrictions,
521 and switching subsystem port wavelength constraints, e.g., colored
522 ROADM drop ports.
524 In the following summarize both information from existing GMPLS
525 route protocols and new information that maybe needed by the RWA
526 process.
528 <LinkInfo> ::= <LinkID> [<AdministrativeGroup>]
529 [<InterfaceCapDesc>] [<Protection>] [<SRLG>...]
530 [<TrafficEngineeringMetric>] [<PortLabelRestriction>...]
532 Note that these additional link characteristics only applies to line
533 side ports of WDM system or add/drop ports pertaining to Resource
534 Pool (e.g., Regenerator or Wavelength Converter Pool). The
535 advertisement of input/output tributary ports is not intended here.
537 6.1. Administrative Group
539 AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds
540 to one administrative group assigned to the interface. A link may
541 belong to multiple groups. This is a configured quantity and can be
542 used to influence routing decisions.
544 6.2. Interface Switching Capability Descriptor
546 InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different
547 switching capabilities on this GMPLS interface. In both [RFC4203]
548 and [RFC5307] this information gets combined with the maximum LSP
549 bandwidth that can be used on this link at eight different priority
550 levels.
552 6.3. Link Protection Type (for this link)
554 Protection: Defined in [RFC4202] and implemented in [RFC4203,
555 RFC5307]. Used to indicate what protection, if any, is guarding this
556 link.
558 6.4. Shared Risk Link Group Information
560 SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307].
561 This allows for the grouping of links into shared risk groups, i.e.,
562 those links that are likely, for some reason, to fail at the same
563 time.
565 6.5. Traffic Engineering Metric
567 TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the
568 identification of a data channel link metric value for traffic
569 engineering that is separate from the metric used for path cost
570 computation of the control plane.
572 Note that multiple "link metric values" could find use in optical
573 networks, however it would be more useful to the RWA process to
574 assign these specific meanings such as link mile metric, or
575 probability of failure metric, etc...
577 6.6. Port Label Restrictions
579 Port label restrictions could be applied generally to any label
580 types in GMPLS by adding new kinds of restrictions. Wavelength is a
581 type of label.
583 Port label (wavelength) restrictions (PortLabelRestriction) model
584 the label (wavelength) restrictions that the link and various
585 optical devices such as OXCs, ROADMs, and waveband multiplexers may
586 impose on a port. These restrictions tell us what wavelength may or
587 may not be used on a link and are relatively static. This plays an
588 important role in fully characterizing a WSON switching device
589 [Switch]. Port wavelength restrictions are specified relative to the
590 port in general or to a specific connectivity matrix (section 4.1.
592 Reference [Switch] gives an example where both switch and fixed
593 connectivity matrices are used and both types of constraints occur
594 on the same port.
596 <PortLabelRestriction> ::= <MatrixID> <RestrictionType>
597 <Restriction parameters list>
599 <Restriction parameters list> ::=
600 <Simple label restriction parameters> |
601 <Channel count restriction parameters> |
602 <Label range restriction parameters> |
603 <Simple+channel restriction parameters> |
604 <Exclusive label restriction parameters>
606 <Simple label restriction parameters> ::= <LabelSet> ...
608 <Channel count restriction parameters> ::= <MaxNumChannels>
610 <Label range restriction parameters> ::=
611 <MaxLabelRange> (<LabelSet> ...)
613 <Simple+channel restriction parameters> ::=
614 <MaxNumChannels> (<LabelSet> ...)
616 <Exclusive label restriction parameters> ::= <LabelSet> ...
618 Where
620 MatrixID is the ID of the corresponding connectivity matrix (section
621 4.1.
623 The RestrictionType parameter is used to specify general port
624 restrictions and matrix specific restrictions. It can take the
625 following values and meanings:
627 SIMPLE_LABEL: Simple label (wavelength) set restriction; The label
628 set parameter is required.
630 CHANNEL_COUNT: The number of channels is restricted to be less than
631 or equal to the Max number of channels parameter (which is
632 required).
634 LABEL_RANGE: Used to indicate a restriction on a range of labels
635 that can be switched. For example, a waveband device with a tunable
636 center frequency and passband. This constraint is characterized by
637 the MaxLabelRange parameter which indicates the maximum range of the
638 labels, e.g., which may represent a waveband in terms of channels.
639 Note that an additional parameter can be used to indicate the
640 overall tuning range. Specific center frequency tuning information
641 can be obtained from dynamic channel in use information. It is
642 assumed that both center frequency and bandwidth (Q) tuning can be
643 done without causing faults in existing signals.
645 SIMPLE LABEL & CHANNEL COUNT: In this case, the accompanying label
646 set and MaxNumChannels indicate labels permitted on the port and the
647 maximum number of labels that can be simultaneously used on the
648 port.
650 LINK LABEL_EXCLUSIVITY: A label (wavelength) can be used at most
651 once among a given set of ports. The set of ports is specified as a
652 parameter to this constraint.
654 Restriction specific parameters are used with one or more of the
655 previously listed restriction types. The currently defined
656 parameters are:
658 LabelSet is a conceptual set of labels (wavelengths).
660 MaxNumChannels is the maximum number of channels that can be
661 simultaneously used (relative to either a port or a matrix).
663 LinkSet is a conceptual set of ports.
665 MaxLabelRange indicates the maximum range of the labels.
667 For example, if the port is a "colored" drop port of a ROADM then
668 there are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels =
669 1, and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of
670 a single member corresponding to the frequency of the permitted
671 wavelength. See [Switch] for a complete waveband example.
673 This information model for port wavelength (label) restrictions is
674 fairly general in that it can be applied to ports that have label
675 restrictions only or to ports that are part of an asymmetric switch
676 and have label restrictions. In addition, the types of label
677 restrictions that can be supported are extensible.
679 6.6.1. Port-Wavelength Exclusivity Example
681 Although there can be many different ROADM or switch architectures
682 that can lead to the constraint where a lambda (label) maybe used at
683 most once on a set of ports Figure 3 shows a ROADM architecture
684 based on components known as a Wavelength Selective Switch
685 (WSS)[OFC08]. This ROADM is composed of splitters, combiners, and
686 WSSes. This ROADM has 11 output ports, which are numbered in the
687 diagram. Output ports 1-8 are known as drop ports and are intended
688 to support a single wavelength. Drop ports 1-4 output from WSS #2,
689 which is fed from WSS #1 via a single fiber. Due to this internal
690 structure a constraint is placed on the output ports 1-4 that a
691 lambda can be only used once over the group of ports (assuming uni-
692 cast and not multi-cast operation). Similarly the output ports 5-8
693 have a similar constraint due to the internal structure.
695 | A
696 v 10 |
697 +-------+ +-------+
698 | Split | |WSS 6 |
699 +-------+ +-------+
700 +----+ | | | | | | | |
701 | W | | | | | | | | +-------+ +----+
702 | S |--------------+ | | | +-----+ | +----+ | | S |
703 9 | S |----------------|---|----|-------|------|----|---| p |
704 <--| |----------------|---|----|-------|----+ | +---| l |<
705 | 5 |--------------+ | | | +-----+ | | +--| i |
706 +----+ | | | | | +------|-|-----|--| t |
707 +--------|-+ +----|-|---|------|----+ | +----+
708 +----+ | | | | | | | | |
709 | S |-----|--------|----------+ | | | | | | +----+
710 | p |-----|--------|------------|---|------|----|--|--| W |
711 -->| l |-----|-----+ | +----------+ | | | +--|--| S |11
712 | i |---+ | | | | +------------|------|-------|--| S |->
713 | t | | | | | | | | | | +---|--| |
714 +----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 |
715 | | | +--|-|-|--------+ | | | | | +----+
716 | | | | | | | | | | | |
717 +------+ +------+ +------+ +------+
718 | WSS 1| | Split| | WSS 3| | Split|
719 +--+---+ +--+---+ +--+---+ +--+---+
720 | A | A
721 v | v |
722 +-------+ +--+----+ +-------+ +--+----+
723 | WSS 2 | | Comb. | | WSS 4 | | Comb. |
724 +-------+ +-------+ +-------+ +-------+
725 1|2|3|4| A A A A 5|6|7|8| A A A A
726 v v v v | | | | v v v v | | | |
728 Figure 3 A ROADM composed from splitter, combiners, and WSSs.
730 7. Dynamic Components of the Information Model
732 In the previously presented information model there are a limited
733 number of information elements that are dynamic, i.e., subject to
734 change with subsequent establishment and teardown of connections.
735 Depending on the protocol used to convey this overall information
736 model it may be possible to send this dynamic information separate
737 from the relatively larger amount of static information needed to
738 characterize WSON's and their network elements.
740 7.1. Dynamic Link Information (General)
742 For WSON links wavelength availability and wavelengths in use for
743 shared backup purposes can be considered dynamic information and
744 hence are grouped with the dynamic information in the following set:
746 <DynamicLinkInfo> ::= <LinkID> <AvailableLabels>
747 [<SharedBackupLabels>]
749 AvailableLabels is a set of labels (wavelengths) currently available
750 on the link. Given this information and the port wavelength
751 restrictions one can also determine which wavelengths are currently
752 in use. This parameter could potential be used with other
753 technologies that GMPLS currently covers or may cover in the future.
755 SharedBackupLabels is a set of labels (wavelengths) currently used
756 for shared backup protection on the link. An example usage of this
757 information in a WSON setting is given in [Shared]. This parameter
758 could potential be used with other technologies that GMPLS currently
759 covers or may cover in the future.
761 Note that the above does not dictate a particular encoding or
762 placement for available label information. In some routing protocols
763 it may be advantageous or required to place this information within
764 another information element such as the interface switching
765 capability descriptor (ISCD). Consult routing protocol specific
766 extensions for details of placement of information elements.
768 7.2. Dynamic Node Information (WSON Specific)
770 Currently the only node information that can be considered dynamic
771 is the resource pool state and can be isolated into a dynamic node
772 information element as follows:
774 <DynamicNodeInfo> ::= <NodeID> [<ResourcePool>]
776 8. Security Considerations
778 This document discussed an information model for RWA computation in
779 WSONs. Such a model is very similar from a security standpoint of
780 the information that can be currently conveyed via GMPLS routing
781 protocols. Such information includes network topology, link state
782 and current utilization, and well as the capabilities of switches
783 and routers within the network. As such this information should be
784 protected from disclosure to unintended recipients. In addition,
785 the intentional modification of this information can significantly
786 affect network operations, particularly due to the large capacity of
787 the optical infrastructure to be controlled. A general discussion on
788 security in GMPLS networks can be found in [RFC5920].
790 9. IANA Considerations
792 This informational document does not make any requests for IANA
793 action.
795 10. Acknowledgments
797 This document was prepared using 2-Word-v2.0.template.dot.
799 11. References
801 11.1. Normative References
803 [G.707] ITU-T Recommendation G.707, Network node interface for the
804 synchronous digital hierarchy (SDH), January 2007.
806 [G.709] ITU-T Recommendation G.709, Interfaces for the Optical
807 Transport Network(OTN), March 2003.
809 [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for
810 high bit-rate DWDM submarine systems, February 2004.
812 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used
813 in Various Protocol Specifications", RFC 5511, April 2009.
815 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
816 Switching (GMPLS) Signaling Functional Description", RFC
817 3471, January 2003.
819 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
820 (TE) Extensions to OSPF Version 2", RFC 3630, September
821 2003.
823 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
824 Extensions in Support of Generalized Multi-Protocol Label
825 Switching (GMPLS)", RFC 4202, October 2005
827 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
828 in Support of Generalized Multi-Protocol Label Switching
829 (GMPLS)", RFC 4203, October 2005.
831 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
832 Switching (GMPLS) Signaling Extensions for G.709 Optical
833 Transport Networks Control", RFC 4328, January 2006.
835 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
836 Engineering", RFC 5305, October 2008.
838 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
839 in Support of Generalized Multi-Protocol Label Switching
840 (GMPLS)", RFC 5307, October 2008.
842 11.2. Informative References
844 [OFC08] P. Roorda and B. Collings, "Evolution to Colorless and
845 Directionless ROADM Architectures," Optical Fiber
846 communication/National Fiber Optic Engineers Conference,
847 2008. OFC/NFOEC 2008. Conference on, 2008, pp. 1-3.
849 [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in
850 PCE-based WSON Networks", iPOP 2008.
852 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, "Modeling
853 WDM Wavelength Switching Systems for Use in GMPLS and
854 Automated Path Computation", Journal of Optical
855 Communications and Networking, vol. 1, June, 2009, pp.
856 187-195.
858 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and
859 engineering considerations, February 2006.
861 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS
862 Networks", RFC 5920, July 2010.
864 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and
865 PCE Control of Wavelength Switched Optical Networks", RFC
866 6163, April 2011.
868 12. Contributors
870 Diego Caviglia
871 Ericsson
872 Via A. Negrone 1/A 16153
873 Genoa Italy
875 Phone: +39 010 600 3736
876 Email: diego.caviglia@(marconi.com, ericsson.com)
878 Anders Gavler
879 Acreo AB
880 Electrum 236
881 SE - 164 40 Kista Sweden
883 Email: Anders.Gavler@acreo.se
885 Jonas Martensson
886 Acreo AB
887 Electrum 236
888 SE - 164 40 Kista, Sweden
890 Email: Jonas.Martensson@acreo.se
892 Itaru Nishioka
893 NEC Corp.
894 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666
895 Japan
897 Phone: +81 44 396 3287
898 Email: i-nishioka@cb.jp.nec.com
900 Lyndon Ong
901 Ciena
902 Email: lyong@ciena.com
904 Cyril Margaria
905 Email: cyril.margaria@gmail.com
907 Author's Addresses
909 Greg M. Bernstein (ed.)
910 Grotto Networking
911 Fremont California, USA
913 Phone: (510) 573-2237
914 Email: gregb@grotto-networking.com
916 Young Lee (ed.)
917 Huawei Technologies
918 5369 Legacy Drive, Building 3
919 Plano, TX 75023
920 USA
922 Phone: (469) 277-5838
923 Email: leeyoung@huawei.com
925 Dan Li
926 Huawei Technologies Co., Ltd.
927 F3-5-B R&D Center, Huawei Base,
928 Bantian, Longgang District
929 Shenzhen 518129 P.R.China
931 Phone: +86-755-28973237
932 Email: danli@huawei.com
934 Wataru Imajuku
935 NTT Network Innovation Labs
936 1-1 Hikari-no-oka, Yokosuka, Kanagawa
937 Japan
939 Phone: +81-(46) 859-4315
940 Email: imajuku.wataru@lab.ntt.co.jp
942 Intellectual Property Statement
944 The IETF Trust takes no position regarding the validity or scope of
945 any Intellectual Property Rights or other rights that might be
946 claimed to pertain to the implementation or use of the technology
947 described in any IETF Document or the extent to which any license
948 under such rights might or might not be available; nor does it
949 represent that it has made any independent effort to identify any
950 such rights.
952 Copies of Intellectual Property disclosures made to the IETF
953 Secretariat and any assurances of licenses to be made available, or
954 the result of an attempt made to obtain a general license or
955 permission for the use of such proprietary rights by implementers or
956 users of this specification can be obtained from the IETF on-line
957 IPR repository at http://www.ietf.org/ipr
959 The IETF invites any interested party to bring to its attention any
960 copyrights, patents or patent applications, or other proprietary
961 rights that may cover technology that may be required to implement
962 any standard or specification contained in an IETF Document. Please
963 address the information to the IETF at ietf-ipr@ietf.org.
965 Disclaimer of Validity
967 All IETF Documents and the information contained therein are
968 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
969 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
970 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
971 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
972 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
973 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
974 FOR A PARTICULAR PURPOSE.
976 Acknowledgment
978 Funding for the RFC Editor function is currently provided by the
979 Internet Society.