idnits 2.17.1 draft-ietf-ccamp-rwa-info-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2010) is 5174 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.7715' is mentioned on line 333, but not defined == Unused Reference: 'G.Sup39' is defined on line 830, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: August 2010 Grotto Networking 5 D. Li 6 Huawei 7 W. Imajuku 8 NTT 10 February 18, 2010 12 Routing and Wavelength Assignment Information Model for Wavelength 13 Switched Optical Networks 15 draft-ietf-ccamp-rwa-info-07.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 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 months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 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 August 18, 2010. 40 Copyright Notice 42 Copyright (c) 2010 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 respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 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 1.1. Revision History..........................................4 71 1.1.1. Changes from 01......................................4 72 1.1.2. Changes from 02......................................4 73 1.1.3. Changes from 03......................................4 74 1.1.4. Changes from 04......................................4 75 1.1.5. Changes from 05......................................5 76 1.1.6. Changes from 06......................................5 77 2. Terminology....................................................5 78 3. Routing and Wavelength Assignment Information Model............6 79 3.1. Dynamic and Relatively Static Information.................6 80 4. Node Information (General).....................................6 81 4.1. Connectivity Matrix.......................................7 82 4.2. Shared Risk Node Group....................................8 83 5. Node Information (WSON specific)...............................8 84 5.1. Resource Accessibility/Availability.......................9 85 5.2. Resource Signal Constraints and Processing Capabilities..11 86 5.3. Compatibility and Capability Details.....................12 87 5.3.1. Modulation Type List................................12 88 5.3.2. FEC Type List.......................................12 89 5.3.3. Bit Rate Range List.................................12 90 5.3.4. Acceptable Client Signal List.......................12 91 5.3.5. Processing Capability List..........................13 92 6. Link Information (General)....................................13 93 6.1. Administrative Group.....................................13 94 6.2. Interface Switching Capability Descriptor................14 95 6.3. Link Protection Type (for this link).....................14 96 6.4. Shared Risk Link Group Information.......................14 97 6.5. Traffic Engineering Metric...............................14 98 6.6. Port Label (Wavelength) Restrictions.....................14 99 7. Dynamic Components of the Information Model...................16 100 7.1. Dynamic Link Information (General).......................16 101 7.2. Dynamic Node Information (WSON Specific).................16 102 8. Security Considerations.......................................17 103 9. IANA Considerations...........................................17 104 10. Acknowledgments..............................................17 105 11. References...................................................18 106 11.1. Normative References....................................18 107 11.2. Informative References..................................19 108 12. Contributors.................................................20 109 Author's Addresses...............................................20 110 Intellectual Property Statement..................................21 111 Disclaimer of Validity...........................................22 113 1. Introduction 115 The purpose of the following information model for WSONs is to 116 facilitate constrained lightpath computation and as such is not a 117 general purpose network management information model. This constraint 118 is frequently referred to as the "wavelength continuity" constraint, 119 and the corresponding constrained lightpath computation is known as 120 the routing and wavelength assignment (RWA) problem. Hence the 121 information model must provide sufficient topology and wavelength 122 restriction and availability information to support this computation. 123 More details on the RWA process and WSON subsystems and their 124 properties can be found in [WSON-Frame]. The model defined here 125 includes constraints between WSON signal attributes and network 126 elements, but does not include optical impairments. 128 In addition to presenting an information model suitable for path 129 computation in WSON, this document also highlights model aspects that 130 may have general applicability to other technologies utilizing a 131 GMPLS control plane. We refer to the information model applicable to 132 other technologies beyond WSON as "general" to distinguish from the 133 "WSON-specific" model that is applicable only to WSON technology. 135 1.1. Revision History 137 1.1.1. Changes from 01 139 Added text on multiple fixed and switched connectivity matrices. 141 Added text on the relationship between SRNG and SRLG and encoding 142 considerations. 144 Added clarifying text on the meaning and use of port/wavelength 145 restrictions. 147 Added clarifying text on wavelength availability information and how 148 to derive wavelengths currently in use. 150 1.1.2. Changes from 02 152 Integrated switched and fixed connectivity matrices into a single 153 "connectivity matrix" model. Added numbering of matrices to allow for 154 wavelength (time slot, label) dependence of the connectivity. 155 Discussed general use of this node parameter beyond WSON. 157 Integrated switched and fixed port wavelength restrictions into a 158 single port wavelength restriction of which there can be more than 159 one and added a reference to the corresponding connectivity matrix if 160 there is one. Also took into account port wavelength restrictions in 161 the case of symmetric switches, developed a uniform model and 162 specified how general label restrictions could be taken into account 163 with this model. 165 Removed the Shared Risk Node Group parameter from the node info, but 166 left explanation of how the same functionality can be achieved with 167 existing GMPLS SRLG constructs. 169 Removed Maximum bandwidth per channel parameter from link 170 information. 172 1.1.3. Changes from 03 174 Removed signal related text from section 3.2.4 as signal related 175 information is deferred to a new signal compatibility draft. 177 Removed encoding specific text from Section 3.3.1 of version 03. 179 1.1.4. Changes from 04 181 Removed encoding specific text from Section 4.1. 183 Removed encoding specific text from Section 3.4. 185 1.1.5. Changes from 05 187 Renumbered sections for clarity. 189 Updated abstract and introduction to encompass signal 190 compatibility/generalization. 192 Generalized Section on wavelength converter pools to include electro 193 optical subsystems in general. This is where we added signal 194 compatibility modeling. 196 1.1.6. Changes from 06 198 Simplified information model for WSON specifics, by combining similar 199 fields and introducing simpler aggregate information elements. 201 2. Terminology 203 CWDM: Coarse Wavelength Division Multiplexing. 205 DWDM: Dense Wavelength Division Multiplexing. 207 FOADM: Fixed Optical Add/Drop Multiplexer. 209 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 210 count wavelength selective switching element featuring ingress and 211 egress line side ports as well as add/drop side ports. 213 RWA: Routing and Wavelength Assignment. 215 Wavelength Conversion. The process of converting an information 216 bearing optical signal centered at a given wavelength to one with 217 "equivalent" content centered at a different wavelength. Wavelength 218 conversion can be implemented via an optical-electronic-optical (OEO) 219 process or via a strictly optical process. 221 WDM: Wavelength Division Multiplexing. 223 Wavelength Switched Optical Network (WSON): A WDM based optical 224 network in which switching is performed selectively based on the 225 center wavelength of an optical signal. 227 3. Routing and Wavelength Assignment Information Model 229 We group the following WSON RWA information model into four 230 categories regardless of whether they stem from a switching subsystem 231 or from a line subsystem: 233 o Node Information 235 o Link Information 237 o Dynamic Node Information 239 o Dynamic Link Information 241 Note that this is roughly the categorization used in [G.7715] section 242 7. 244 In the following we use, where applicable, the reduced Backus-Naur 245 form (RBNF) syntax of [RBNF] to aid in defining the RWA information 246 model. 248 3.1. Dynamic and Relatively Static Information 250 All the RWA information of concern in a WSON network is subject to 251 change over time. Equipment can be upgraded; links may be placed in 252 or out of service and the like. However, from the point of view of 253 RWA computations there is a difference between information that can 254 change with each successive connection establishment in the network 255 and that information that is relatively static on the time scales of 256 connection establishment. A key example of the former is link 257 wavelength usage since this can change with connection setup/teardown 258 and this information is a key input to the RWA process. Examples of 259 relatively static information are the potential port connectivity of 260 a WDM ROADM, and the channel spacing on a WDM link. 262 In this document we will separate, where possible, dynamic and static 263 information so that these can be kept separate in possible encodings 264 and hence allowing for separate updates of these two types of 265 information thereby reducing processing and traffic load caused by 266 the timely distribution of the more dynamic RWA WSON information. 268 4. Node Information (General) 270 The node information described here contains the relatively static 271 information related to a WSON node. This includes connectivity 272 constraints amongst ports and wavelengths since WSON switches can 273 exhibit asymmetric switching properties. Additional information could 274 include properties of wavelength converters in the node if any are 275 present. In [Switch] it was shown that the wavelength connectivity 276 constraints for a large class of practical WSON devices can be 277 modeled via switched and fixed connectivity matrices along with 278 corresponding switched and fixed port constraints. We include these 279 connectivity matrices with our node information the switched and 280 fixed port wavelength constraints with the link information. 282 Formally, 284 ::= [...] 286 Where the Node_ID would be an appropriate identifier for the node 287 within the WSON RWA context. 289 Note that multiple connectivity matrices are allowed and hence can 290 fully support the most general cases enumerated in [Switch]. 292 4.1. Connectivity Matrix 294 The connectivity matrix (ConnectivityMatrix) represents either the 295 potential connectivity matrix for asymmetric switches (e.g. ROADMs 296 and such) or fixed connectivity for an asymmetric device such as a 297 multiplexer. Note that this matrix does not represent any particular 298 internal blocking behavior but indicates which ingress ports and 299 wavelengths could possibly be connected to a particular output port. 300 Representing internal state dependent blocking for a switch or ROADM 301 is beyond the scope of this document and due to it's highly 302 implementation dependent nature would most likely not be subject to 303 standardization in the future. The connectivity matrix is a 304 conceptual M by N matrix representing the potential switched or fixed 305 connectivity, where M represents the number of ingress ports and N 306 the number of egress ports. We say this is a "conceptual" matrix 307 since this matrix tends to exhibit structure that allows for very 308 compact representations that are useful for both transmission and 309 path computation [Encode]. 311 Note that the connectivity matrix information element can be useful 312 in any technology context where asymmetric switches are utilized. 314 ConnectivityMatrix(i, j) ::= 316 Where 318 is a unique identifier for the matrix. 320 can be either 0 or 1 depending upon whether the 321 connectivity is either fixed or potentially switched. 323 represents the fixed or switched connectivity in that 324 Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect 325 to egress port j for one or more wavelengths. 327 4.2. Shared Risk Node Group 329 SRNG: Shared risk group for nodes. The concept of a shared risk link 330 group was defined in [RFC4202]. This can be used to achieve a desired 331 "amount" of link diversity. It is also desirable to have a similar 332 capability to achieve various degrees of node diversity. This is 333 explained in [G.7715]. Typical risk groupings for nodes can include 334 those nodes in the same building, within the same city, or geographic 335 region. 337 Since the failure of a node implies the failure of all links 338 associated with that node a sufficiently general shared risk link 339 group (SRLG) encoding, such as that used in GMPLS routing extensions 340 can explicitly incorporate SRNG information. 342 5. Node Information (WSON specific) 344 As discussed in [WSON-Frame] a WSON node may contain electro-optical 345 subsystems such as regenerators, wavelength converters or entire 346 switching subsystems. The model present here can be used in 347 characterizing the accessibility and availability of limited 348 resources such as regenerators or wavelength converters as well as 349 WSON signal attribute constraints of electro-optical subsystems. As 350 such this information element is fairly specific to WSON 351 technologies. We refer to regenerator block or wavelength converter 352 block as resource block. 354 A WSON node may include regenerators or wavelength converters 355 arranged in a shared pool. As discussed in [WSON-Frame] this can 356 include OEO based WDM switches as well. There are a number of 357 different approaches used in the design of WDM switches containing 358 regenerator or converter pools. However, from the point of view of 359 path computation we need to know the following: 361 1. The nodes that support regeneration or wavelength conversion. 363 2. The accessibility and availability of a wavelength converter to 364 convert from a given ingress wavelength on a particular ingress 365 port to a desired egress wavelength on a particular egress port. 367 3. Limitations on the types of signals that can be converted and the 368 conversions that can be performed. 370 This leads to the following formal high level model: 372 ::= [...] 373 [] 375 Where 377 ::= ... 378 [...] [...] 379 [] 381 First we will address the accessibility of resource blocks then we 382 will discuss their properties. 384 5.1. Resource Accessibility/Availability 386 A similar technique as used to model ROADMs and optical switches can 387 be used to model regenerator/converter accessibility. This technique 388 was generally discussed in [WSON-Frame] and consisted of a matrix to 389 indicate possible connectivity along with wavelength constraints for 390 links/ports. Since regenerators or wavelength converters may be 391 considered a scarce resource we will also want to our model to 392 include as a minimum the usage state (availability) of individual 393 regenerators or converters in the pool. Models that incorporate more 394 state to further reveal blocking conditions on ingress or egress to 395 particular converters are for further study and not included here. 397 The three stage model as shown schematically in Figure 1. In this 398 model we assume N ingress ports (fibers), P resource blocks 399 containing one or more identical resources (e.g. wavelength 400 converters), and M egress ports (fibers). Since not all ingress ports 401 can necessarily reach each resource block, the model starts with a 402 resource pool ingress matrix RI(i,p) = {0,1} whether ingress port i 403 can reach potentially reach resource block p. 405 Since not all wavelengths can necessarily reach all the resources or 406 the resources may have limited input wavelength range we have a set 407 of ingress port constraints for each resource. Currently we assume 408 that a resource with a resource block can only take a single 409 wavelength on input. We can model each resource block ingress port 410 constraint via a wavelength set mechanism. 412 Next we have a state vector RA(j) = {0,...,k} which tells us the 413 number of resources in resource block j in use. This is the only 414 state kept in the resource pool model. This state is not necessary 415 for modeling "fixed" transponder system or full OEO switches with WDM 416 interfaces, i.e., systems where there is no sharing. 418 After that, we have a set of resource egress wavelength constraints. 419 These constraints indicate what wavelengths a particular resource 420 block can generate or are restricted to generating e.g., a fixed 421 regenerator would be limited to a single lambda. 423 Finally, we have a resource pool egress matrix RE(p,k) = {0,1} 424 depending on whether the output from resource block p can reach 425 egress port k. Examples of this method being used to model wavelength 426 converter pools for several switch architectures from the literature 427 are given in reference [WC-Pool]. 429 I1 +-------------+ +-------------+ E1 430 ----->| | +--------+ | |-----> 431 I2 | +------+ Rb #1 +-------+ | E2 432 ----->| | +--------+ | |-----> 433 | | | | 434 | Resource | +--------+ | Resource | 435 | Pool +------+ +-------+ Pool | 436 | | + Rb #2 + | | 437 | Ingress +------+ +-------| Egress | 438 | Connection | +--------+ | Connection | 439 | Matrix | . | Matrix | 440 | | . | | 441 | | . | | 442 IN | | +--------+ | | EM 443 ----->| +------+ Rb #P +-------+ |-----> 444 | | +--------+ | | 445 +-------------+ ^ ^ +-------------+ 446 | | 447 | | 448 | | 449 | | 451 Ingress wavelength Egress wavelength 452 constraints for constraints for 453 each resource each resource 455 Figure 1 Schematic diagram of resource pool model. 457 Formally we can specify the model as: 459 460 462 [ ::= 463 465 ::=()... 467 Note that except for all the other components of 468 are relatively static. 470 5.2. Resource Signal Constraints and Processing Capabilities 472 The wavelength conversion abilities of a resource (e.g. regenerator, 473 wavelength converter) were modeled in the 474 previously discussed. As discussed in [WSON-Frame] we can model the 475 constraints on an electro-optical resource in terms of input 476 constraints, processing capabilities, and output constraints: 478 ::= 479 ([])* 482 Where is a list of resource block identifiers with the 483 same characteristics. If this set is missing the constraints are 484 applied to the entire network element. 486 The are signal compatibility based constraints. 487 The details of these constraints are defined in section 5.3. 489 ::= 490 492 The are important operations that the 493 resource (or network element) can perform on the signal. The details 494 of these capabilities are defined in section 5.3. 496 ::= 497 499 The are either restrictions on the properties of 500 the signal leaving the resource or network element or options 501 concerning the signal properties when leaving the resource or network 502 element. 504 := 505 5.3. Compatibility and Capability Details 507 5.3.1. Modulation Type List 509 Modulation type, also known as optical tributary signal class, 510 comes in two distinct flavors: (i) ITU-T standardized types; (ii) 511 vendor specific types. The permitted modulation type list can 512 include any mixture of standardized and vendor specific types. 514 ::= 515 [|]... 517 Where the STANDARD_MODULATION object just represents one of the 518 ITU-T standardized optical tributary signal class and the 519 VENDOR_MODULATION object identifies one vendor specific modulation 520 type. 522 5.3.2. FEC Type List 524 Some devices can handle more than one FEC type and hence a list is 525 needed. 527 ::= [] 529 Where the FEC object represents one of the ITU-T standardized FECs 530 defined in [G.709], [G.707], [G.975.1] or a vendor-specific FEC. 532 5.3.3. Bit Rate Range List 534 Some devices can handle more than one particular bit rate range 535 and hence a list is needed. 537 ::= []... 539 ::= 541 Where the START_RATE object represents the lower end of the range 542 and the END_RATE object represents the higher end of the range. 544 5.3.4. Acceptable Client Signal List 546 The list is simply: 548 ::=[]... 550 Where the Generalized Protocol Identifiers (GPID) object 551 represents one of the IETF standardized GPID values as defined in 552 [RFC3471] and [RFC4328]. 554 5.3.5. Processing Capability List 556 We have defined ProcessingCapabilities in Section 5.2 as follows: 558 ::= 559 561 The processing capability list sub-TLV is a list of processing 562 functions that the WSON network element (NE) can perform on the 563 signal including: 565 1. Number of Resources within the block 567 2. Regeneration capability 569 3. Fault and performance monitoring 571 4. Vendor Specific capability 573 Note that the code points for Fault and performance monitoring and 574 vendor specific capability are subject to further study. 576 6. Link Information (General) 578 MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630], 579 [RFC5305] along with GMPLS routing protocol extensions for OSPF and 580 IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static 581 link information needed by the RWA process. However, WSON networks 582 bring in additional link related constraints. These stem from WDM 583 line system characterization, laser transmitter tuning restrictions, 584 and switching subsystem port wavelength constraints, e.g., colored 585 ROADM drop ports. 587 In the following summarize both information from existing GMPLS route 588 protocols and new information that maybe needed by the RWA process. 590 ::= [] [] 591 [] []... [] 592 [] 594 6.1. Administrative Group 596 AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds 597 to one administrative group assigned to the interface. A link may 598 belong to multiple groups. This is a configured quantity and can be 599 used to influence routing decisions. 601 6.2. Interface Switching Capability Descriptor 603 InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different 604 switching capabilities on this GMPLS interface. In both [RFC4203] and 605 [RFC5307] this information gets combined with the maximum LSP 606 bandwidth that can be used on this link at eight different priority 607 levels. 609 6.3. Link Protection Type (for this link) 611 Protection: Defined in [RFC4202] and implemented in [RFC4203, 612 RFC5307]. Used to indicate what protection, if any, is guarding this 613 link. 615 6.4. Shared Risk Link Group Information 617 SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. 618 This allows for the grouping of links into shared risk groups, i.e., 619 those links that are likely, for some reason, to fail at the same 620 time. 622 6.5. Traffic Engineering Metric 624 TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the 625 definition of one additional link metric value for traffic 626 engineering separate from the IP link state routing protocols link 627 metric. Note that multiple "link metric values" could find use in 628 optical networks, however it would be more useful to the RWA process 629 to assign these specific meanings such as link mile metric, or 630 probability of failure metric, etc... 632 6.6. Port Label (Wavelength) Restrictions 634 Port label (wavelength) restrictions (PortLabelRestriction) model the 635 label (wavelength) restrictions that the link and various optical 636 devices such as OXCs, ROADMs, and waveband multiplexers may impose on 637 a port. These restrictions tell us what wavelength may or may not be 638 used on a link and are relatively static. This plays an important 639 role in fully characterizing a WSON switching device [Switch]. Port 640 wavelength restrictions are specified relative to the port in general 641 or to a specific connectivity matrix (section 4.1. Reference 642 [Switch] gives an example where both switch and fixed connectivity 643 matrices are used and both types of constraints occur on the same 644 port. Such restrictions could be applied generally to other label 645 types in GMPLS by adding new kinds of restrictions. 647 ::= [...] 648 [...] 649 ::= 650 [] 652 ::= 653 [] 655 ::= [...] [] 656 [] 658 Where 660 MatrixID is the ID of the corresponding connectivity matrix (section 661 4.1. 663 The RestrictionType parameter is used to specify general port 664 restrictions and matrix specific restrictions. It can take the 665 following values and meanings: 667 SIMPLE_WAVELENGTH: Simple wavelength set restriction; The 668 wavelength set parameter is required. 670 CHANNEL_COUNT: The number of channels is restricted to be less than 671 or equal to the Max number of channels parameter (which is required). 673 WAVEBAND1: Waveband device with a tunable center frequency and 674 passband. This constraint is characterized by the MaxWaveBandWidth 675 parameters which indicates the maximum width of the waveband in terms 676 of channels. Note that an additional wavelength set can be used to 677 indicate the overall tuning range. Specific center frequency tuning 678 information can be obtained from dynamic channel in use information. 679 It is assumed that both center frequency and bandwidth (Q) tuning can 680 be done without causing faults in existing signals. 682 Restriction specific parameters are used with one or more of the 683 previously listed restriction types. The currently defined parameters 684 are: 686 LabelSet is a conceptual set of labels (wavelengths). 688 MaxNumChannels is the maximum number of channels that can be 689 simultaneously used (relative to either a port or a matrix). 691 MaxWaveBandWidth is the maximum width of a tunable waveband 692 switching device. 694 For example, if the port is a "colored" drop port of a ROADM then we 695 have two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, 696 and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a 697 single member corresponding to the frequency of the permitted 698 wavelength. See [Switch] for a complete waveband example. 700 This information model for port wavelength (label) restrictions is 701 fairly general in that it can be applied to ports that have label 702 restrictions only or to ports that are part of an asymmetric switch 703 and have label restrictions. In addition, the types of label 704 restrictions that can be supported are extensible. 706 7. Dynamic Components of the Information Model 708 In the previously presented information model there are a limited 709 number of information elements that are dynamic, i.e., subject to 710 change with subsequent establishment and teardown of connections. 711 Depending on the protocol used to convey this overall information 712 model it may be possible to send this dynamic information separate 713 from the relatively larger amount of static information needed to 714 characterize WSON's and their network elements. 716 7.1. Dynamic Link Information (General) 718 For WSON links wavelength availability and wavelengths in use for 719 shared backup purposes can be considered dynamic information and 720 hence we can isolate the dynamic information in the following set: 722 ::= 723 [] 725 AvailableLabels is a set of labels (wavelengths) currently available 726 on the link. Given this information and the port wavelength 727 restrictions we can also determine which wavelengths are currently in 728 use. This parameter could potential be used with other technologies 729 that GMPLS currently covers or may cover in the future. 731 SharedBackupLabels is a set of labels (wavelengths)currently used for 732 shared backup protection on the link. An example usage of this 733 information in a WSON setting is given in [Shared]. This parameter 734 could potential be used with other technologies that GMPLS currently 735 covers or may cover in the future. 737 7.2. Dynamic Node Information (WSON Specific) 739 Currently the only node information that can be considered dynamic is 740 the resource pool state and can be isolated into a dynamic node 741 information element as follows: 743 ::= [] 745 8. Security Considerations 747 This document discussed an information model for RWA computation in 748 WSONs. Such a model is very similar from a security standpoint of the 749 information that can be currently conveyed via GMPLS routing 750 protocols. Such information includes network topology, link state 751 and current utilization, and well as the capabilities of switches and 752 routers within the network. As such this information should be 753 protected from disclosure to unintended recipients. In addition, the 754 intentional modification of this information can significantly affect 755 network operations, particularly due to the large capacity of the 756 optical infrastructure to be controlled. 758 9. IANA Considerations 760 This informational document does not make any requests for IANA 761 action. 763 10. Acknowledgments 765 This document was prepared using 2-Word-v2.0.template.dot. 767 11. References 769 11.1. Normative References 771 [Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 772 Wavelength Assignment Information Encoding for Wavelength 773 Switched Optical Networks", work in progress: draft-ietf- 774 ccamp-rwa-wson-encode. 776 [G.707] ITU-T Recommendation G.707, Network node interface for the 777 synchronous digital hierarchy (SDH), January 2007. 779 [G.709] ITU-T Recommendation G.709, Interfaces for the Optical 780 Transport Network(OTN), March 2003. 782 [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for 783 high bit-rate DWDM submarine systems, February 2004. 785 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used in 786 Various Protocol Specifications", RFC 5511, April 2009. 788 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 789 Switching (GMPLS) Signaling Functional Description", RFC 790 3471, January 2003. 792 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 793 (TE) Extensions to OSPF Version 2", RFC 3630, September 794 2003. 796 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 797 in Support of Generalized Multi-Protocol Label Switching 798 (GMPLS)", RFC 4202, October 2005 800 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 801 Support of Generalized Multi-Protocol Label Switching 802 (GMPLS)", RFC 4203, October 2005. 804 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 805 Switching (GMPLS) Signaling Extensions for G.709 Optical 806 Transport Networks Control", RFC 4328, January 2006. 808 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 809 Engineering", RFC 5305, October 2008. 811 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 812 in Support of Generalized Multi-Protocol Label Switching 813 (GMPLS)", RFC 5307, October 2008. 815 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 816 and PCE Control of Wavelength Switched Optical Networks", 817 work in progress: draft-ietf-ccamp-rwa-wson-framework. 819 11.2. Informative References 821 [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE- 822 based WSON Networks", iPOP 2008, http://www.grotto- 823 networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . 825 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 826 WDM Wavelength Switching Systems for Use in GMPLS and Automated 827 Path Computation", Journal of Optical Communications and 828 Networking, vol. 1, June, 2009, pp. 187-195. 830 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 831 engineering considerations, February 2006. 833 [WC-Pool] G. Bernstein, Y. Lee, "Modeling WDM Switching Systems 834 including Wavelength Converters" to appear www.grotto- 835 networking.com, 2008. 837 12. Contributors 839 Diego Caviglia 840 Ericsson 841 Via A. Negrone 1/A 16153 842 Genoa Italy 844 Phone: +39 010 600 3736 845 Email: diego.caviglia@(marconi.com, ericsson.com) 847 Anders Gavler 848 Acreo AB 849 Electrum 236 850 SE - 164 40 Kista Sweden 852 Email: Anders.Gavler@acreo.se 854 Jonas Martensson 855 Acreo AB 856 Electrum 236 857 SE - 164 40 Kista, Sweden 859 Email: Jonas.Martensson@acreo.se 861 Itaru Nishioka 862 NEC Corp. 863 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 864 Japan 866 Phone: +81 44 396 3287 867 Email: i-nishioka@cb.jp.nec.com 869 Lyndon Ong 870 Ciena 871 Email: lyong@ciena.com 873 Author's Addresses 875 Greg M. Bernstein (ed.) 876 Grotto Networking 877 Fremont California, USA 879 Phone: (510) 573-2237 880 Email: gregb@grotto-networking.com 881 Young Lee (ed.) 882 Huawei Technologies 883 1700 Alma Drive, Suite 100 884 Plano, TX 75075 885 USA 887 Phone: (972) 509-5599 (x2240) 888 Email: ylee@huawei.com 890 Dan Li 891 Huawei Technologies Co., Ltd. 892 F3-5-B R&D Center, Huawei Base, 893 Bantian, Longgang District 894 Shenzhen 518129 P.R.China 896 Phone: +86-755-28973237 897 Email: danli@huawei.com 899 Wataru Imajuku 900 NTT Network Innovation Labs 901 1-1 Hikari-no-oka, Yokosuka, Kanagawa 902 Japan 904 Phone: +81-(46) 859-4315 905 Email: imajuku.wataru@lab.ntt.co.jp 907 Intellectual Property Statement 909 The IETF Trust takes no position regarding the validity or scope of 910 any Intellectual Property Rights or other rights that might be 911 claimed to pertain to the implementation or use of the technology 912 described in any IETF Document or the extent to which any license 913 under such rights might or might not be available; nor does it 914 represent that it has made any independent effort to identify any 915 such rights. 917 Copies of Intellectual Property disclosures made to the IETF 918 Secretariat and any assurances of licenses to be made available, or 919 the result of an attempt made to obtain a general license or 920 permission for the use of such proprietary rights by implementers or 921 users of this specification can be obtained from the IETF on-line IPR 922 repository at http://www.ietf.org/ipr 924 The IETF invites any interested party to bring to its attention any 925 copyrights, patents or patent applications, or other proprietary 926 rights that may cover technology that may be required to implement 927 any standard or specification contained in an IETF Document. Please 928 address the information to the IETF at ietf-ipr@ietf.org. 930 Disclaimer of Validity 932 All IETF Documents and the information contained therein are provided 933 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 934 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 935 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 936 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 937 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 938 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 939 FOR A PARTICULAR PURPOSE. 941 Acknowledgment 943 Funding for the RFC Editor function is currently provided by the 944 Internet Society.