idnits 2.17.1 draft-ietf-ccamp-rwa-info-14.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 (March 6, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.7715' is mentioned on line 403, but not defined == Unused Reference: 'G.Sup39' is defined on line 1038, 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: September 2012 Grotto Networking 5 D. Li 6 Huawei 7 W. Imajuku 8 NTT 10 March 6, 2012 12 Routing and Wavelength Assignment Information Model for Wavelength 13 Switched Optical Networks 15 draft-ietf-ccamp-rwa-info-14.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 September 6, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 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......................................5 74 1.1.4. Changes from 04......................................5 75 1.1.5. Changes from 05......................................5 76 1.1.6. Changes from 06......................................5 77 1.1.7. Changes from 07......................................5 78 1.1.8. Changes from 08......................................5 79 1.1.9. Changes from 09......................................5 80 1.1.10. Changes from 10.....................................6 81 1.1.11. Changes from 11.....................................6 82 1.1.12. Changes from 12.....................................6 83 1.1.13. Changes from 13.....................................6 84 2. Terminology....................................................6 85 3. Routing and Wavelength Assignment Information Model............7 86 3.1. Dynamic and Relatively Static Information.................7 88 4. Node Information (General).....................................8 89 4.1. Connectivity Matrix.......................................8 90 4.2. Shared Risk Node Group....................................9 91 5. Node Information (WSON specific)...............................9 92 5.1. Resource Accessibility/Availability......................11 93 5.2. Resource Signal Constraints and Processing Capabilities..14 94 5.3. Compatibility and Capability Details.....................15 95 5.3.1. Shared Input or Output Indication...................15 96 5.3.2. Modulation Type List................................15 97 5.3.3. FEC Type List.......................................15 98 5.3.4. Bit Rate Range List.................................15 99 5.3.5. Acceptable Client Signal List.......................16 100 5.3.6. Processing Capability List..........................16 101 6. Link Information (General)....................................16 102 6.1. Administrative Group.....................................17 103 6.2. Interface Switching Capability Descriptor................17 104 6.3. Link Protection Type (for this link).....................17 105 6.4. Shared Risk Link Group Information.......................17 106 6.5. Traffic Engineering Metric...............................17 107 6.6. Port Label (Wavelength) Restrictions.....................18 108 6.6.1. Port-Wavelength Exclusivity Example.................19 109 7. Dynamic Components of the Information Model...................21 110 7.1. Dynamic Link Information (General).......................21 111 7.2. Dynamic Node Information (WSON Specific).................21 112 8. Security Considerations.......................................22 113 9. IANA Considerations...........................................22 114 10. Acknowledgments..............................................22 115 11. References...................................................23 116 11.1. Normative References....................................23 117 11.2. Informative References..................................24 118 12. Contributors.................................................25 119 Author's Addresses...............................................26 120 Intellectual Property Statement..................................26 121 Disclaimer of Validity...........................................27 123 1. Introduction 125 The purpose of the following information model for WSONs is to 126 facilitate constrained lightpath computation and as such is not a 127 general purpose network management information model. This 128 constraint is frequently referred to as the "wavelength continuity" 129 constraint, and the corresponding constrained lightpath computation 130 is known as the routing and wavelength assignment (RWA) problem. 131 Hence the information model must provide sufficient topology and 132 wavelength restriction and availability information to support this 133 computation. More details on the RWA process and WSON subsystems and 134 their properties can be found in [RFC6163]. The model defined here 135 includes constraints between WSON signal attributes and network 136 elements, but does not include optical impairments. 138 In addition to presenting an information model suitable for path 139 computation in WSON, this document also highlights model aspects 140 that may have general applicability to other technologies utilizing 141 a GMPLS control plane. The portion of the information model 142 applicable to other technologies beyond WSON is referred to as 143 "general" to distinguish it from the "WSON-specific" portion that is 144 applicable only to WSON technology. 146 1.1. Revision History 148 1.1.1. Changes from 01 150 Added text on multiple fixed and switched connectivity matrices. 152 Added text on the relationship between SRNG and SRLG and encoding 153 considerations. 155 Added clarifying text on the meaning and use of port/wavelength 156 restrictions. 158 Added clarifying text on wavelength availability information and how 159 to derive wavelengths currently in use. 161 1.1.2. Changes from 02 163 Integrated switched and fixed connectivity matrices into a single 164 "connectivity matrix" model. Added numbering of matrices to allow 165 for wavelength (time slot, label) dependence of the connectivity. 166 Discussed general use of this node parameter beyond WSON. 168 Integrated switched and fixed port wavelength restrictions into a 169 single port wavelength restriction of which there can be more than 170 one and added a reference to the corresponding connectivity matrix 171 if there is one. Also took into account port wavelength restrictions 172 in the case of symmetric switches, developed a uniform model and 173 specified how general label restrictions could be taken into account 174 with this model. 176 Removed the Shared Risk Node Group parameter from the node info, but 177 left explanation of how the same functionality can be achieved with 178 existing GMPLS SRLG constructs. 180 Removed Maximum bandwidth per channel parameter from link 181 information. 183 1.1.3. Changes from 03 185 Removed signal related text from section 3.2.4 as signal related 186 information is deferred to a new signal compatibility draft. 188 Removed encoding specific text from Section 3.3.1 of version 03. 190 1.1.4. Changes from 04 192 Removed encoding specific text from Section 4.1. 194 Removed encoding specific text from Section 3.4. 196 1.1.5. Changes from 05 198 Renumbered sections for clarity. 200 Updated abstract and introduction to encompass signal 201 compatibility/generalization. 203 Generalized Section on wavelength converter pools to include electro 204 optical subsystems in general. This is where signal compatibility 205 modeling was added. 207 1.1.6. Changes from 06 209 Simplified information model for WSON specifics, by combining 210 similar fields and introducing simpler aggregate information 211 elements. 213 1.1.7. Changes from 07 215 Added shared fiber connectivity to resource pool modeling. This 216 includes information for determining wavelength collision on an 217 internal fiber providing access to resource blocks. 219 1.1.8. Changes from 08 221 Added PORT_WAVELENGTH_EXCLUSIVITY in the RestrictionType parameter. 222 Added section 6.6.1 that has an example of the port wavelength 223 exclusivity constraint. 225 1.1.9. Changes from 09 227 Section 5: clarified the way that the resource pool is modeled from 228 blocks of identical resources. 230 Section 5.1: grammar fixes. Removed reference to "academic" modeling 231 pre-print. Clarified RBNF resource pool model details. 233 Section 5.2: Formatting fixes. 235 1.1.10. Changes from 10 237 Enhanced the explanation of shared fiber access to resources and 238 updated Figure 2 to show a more general situation to be modeled. 240 Removed all 1st person idioms. 242 1.1.11. Changes from 11 244 Replace all instances of "ingress" with "input" and all instances of 245 "egress" with "output". Added clarifying text on relationship 246 between resource block model and physical entities such as line 247 cards. 249 1.1.12. Changes from 12 251 Section 5.2: Clarified RBNF optional elements for several 252 definitions. 254 Section 5.3.6: Clarified RBNF optional elements for 255 . 257 Editorial changes for clarity. 259 Update the contributor list. 261 1.1.13. Changes from 13 263 Section 7.1: Clarified that this information model does not dictate 264 placement of information elements in protocols. In particular, added 265 a caveat that the available label information element may be placed 266 within the ISCD information element in the case of OSPF. 268 2. Terminology 270 CWDM: Coarse Wavelength Division Multiplexing. 272 DWDM: Dense Wavelength Division Multiplexing. 274 FOADM: Fixed Optical Add/Drop Multiplexer. 276 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 277 count wavelength selective switching element featuring input and 278 output line side ports as well as add/drop side ports. 280 RWA: Routing and Wavelength Assignment. 282 Wavelength Conversion. The process of converting an information 283 bearing optical signal centered at a given wavelength to one with 284 "equivalent" content centered at a different wavelength. Wavelength 285 conversion can be implemented via an optical-electronic-optical 286 (OEO) process or via a strictly optical process. 288 WDM: Wavelength Division Multiplexing. 290 Wavelength Switched Optical Network (WSON): A WDM based optical 291 network in which switching is performed selectively based on the 292 center wavelength of an optical signal. 294 3. Routing and Wavelength Assignment Information Model 296 The following WSON RWA information model is grouped into four 297 categories regardless of whether they stem from a switching 298 subsystem or from a line subsystem: 300 o Node Information 302 o Link Information 304 o Dynamic Node Information 306 o Dynamic Link Information 308 Note that this is roughly the categorization used in [G.7715] 309 section 7. 311 In the following, where applicable, the reduced Backus-Naur form 312 (RBNF) syntax of [RBNF] is used to aid in defining the RWA 313 information model. 315 3.1. Dynamic and Relatively Static Information 317 All the RWA information of concern in a WSON network is subject to 318 change over time. Equipment can be upgraded; links may be placed in 319 or out of service and the like. However, from the point of view of 320 RWA computations there is a difference between information that can 321 change with each successive connection establishment in the network 322 and that information that is relatively static on the time scales of 323 connection establishment. A key example of the former is link 324 wavelength usage since this can change with connection 325 setup/teardown and this information is a key input to the RWA 326 process. Examples of relatively static information are the 327 potential port connectivity of a WDM ROADM, and the channel spacing 328 on a WDM link. 330 This document separates, where possible, dynamic and static 331 information so that these can be kept separate in possible encodings 332 and hence allowing for separate updates of these two types of 333 information thereby reducing processing and traffic load caused by 334 the timely distribution of the more dynamic RWA WSON information. 336 4. Node Information (General) 338 The node information described here contains the relatively static 339 information related to a WSON node. This includes connectivity 340 constraints amongst ports and wavelengths since WSON switches can 341 exhibit asymmetric switching properties. Additional information 342 could include properties of wavelength converters in the node if any 343 are present. In [Switch] it was shown that the wavelength 344 connectivity constraints for a large class of practical WSON devices 345 can be modeled via switched and fixed connectivity matrices along 346 with corresponding switched and fixed port constraints. These 347 connectivity matrices are included with the node information while 348 the switched and fixed port wavelength constraints are included with 349 the link information. 351 Formally, 353 ::= [...] 355 Where the Node_ID would be an appropriate identifier for the node 356 within the WSON RWA context. 358 Note that multiple connectivity matrices are allowed and hence can 359 fully support the most general cases enumerated in [Switch]. 361 4.1. Connectivity Matrix 363 The connectivity matrix (ConnectivityMatrix) represents either the 364 potential connectivity matrix for asymmetric switches (e.g. ROADMs 365 and such) or fixed connectivity for an asymmetric device such as a 366 multiplexer. Note that this matrix does not represent any particular 367 internal blocking behavior but indicates which inputinput ports and 368 wavelengths could possibly be connected to a particular output port. 370 Representing internal state dependent blocking for a switch or ROADM 371 is beyond the scope of this document and due to its highly 372 implementation dependent nature would most likely not be subject to 373 standardization in the future. The connectivity matrix is a 374 conceptual M by N matrix representing the potential switched or 375 fixed connectivity, where M represents the number of inputinput 376 ports and N the number of outputoutput ports. This is a "conceptual" 377 matrix since the matrix tends to exhibit structure that allows for 378 very compact representations that are useful for both transmission 379 and path computation [Encode]. 381 Note that the connectivity matrix information element can be useful 382 in any technology context where asymmetric switches are utilized. 384 ConnectivityMatrix ::= 386 Where 388 is a unique identifier for the matrix. 390 can be either 0 or 1 depending upon whether the 391 connectivity is either fixed or potentially switched. 393 represents the fixed or switched connectivity in that 394 Matrix(i, j) = 0 or 1 depending on whether inputinput port i can 395 connect to outputoutput port j for one or more wavelengths. 397 4.2. Shared Risk Node Group 399 SRNG: Shared risk group for nodes. The concept of a shared risk link 400 group was defined in [RFC4202]. This can be used to achieve a 401 desired "amount" of link diversity. It is also desirable to have a 402 similar capability to achieve various degrees of node diversity. 403 This is explained in [G.7715]. Typical risk groupings for nodes can 404 include those nodes in the same building, within the same city, or 405 geographic region. 407 Since the failure of a node implies the failure of all links 408 associated with that node a sufficiently general shared risk link 409 group (SRLG) encoding, such as that used in GMPLS routing extensions 410 can explicitly incorporate SRNG information. 412 5. Node Information (WSON specific) 414 As discussed in [RFC6163] a WSON node may contain electro-optical 415 subsystems such as regenerators, wavelength converters or entire 416 switching subsystems. The model present here can be used in 417 characterizing the accessibility and availability of limited 418 resources such as regenerators or wavelength converters as well as 419 WSON signal attribute constraints of electro-optical subsystems. As 420 such this information element is fairly specific to WSON 421 technologies. 423 A WSON node may include regenerators or wavelength converters 424 arranged in a shared pool. As discussed in [RFC6163] this can 425 include OEO based WDM switches as well. There are a number of 426 different approaches used in the design of WDM switches containing 427 regenerator or converter pools. However, from the point of view of 428 path computation the following need to be known: 430 1. The nodes that support regeneration or wavelength conversion. 432 2. The accessibility and availability of a wavelength converter to 433 convert from a given inputinput wavelength on a particular 434 inputinput port to a desired outputoutput wavelength on a 435 particular outputoutput port. 437 3. Limitations on the types of signals that can be converted and the 438 conversions that can be performed. 440 Since resources tend to be packaged together in blocks of similar 441 devices, e.g., on line cards or other types of modules, the 442 fundamental unit of identifiable resource in this document is the 443 "resource block". A resource block may contain one or more 444 resources. As resources are the smallest identifiable unit of 445 processing resource, one can group together resources into blocks if 446 they have similar characteristics relevant to the optical system 447 being modeled, e.g., processing properties, accessibility, etc. 449 This leads to the following formal high level model: 451 ::= [...] 452 [] 454 Where 456 ::= ... 457 [...] [...] 458 [] 460 First the accessibility of resource blocks is addressed then their 461 properties are discussed. 463 5.1. Resource Accessibility/Availability 465 A similar technique as used to model ROADMs and optical switches can 466 be used to model regenerator/converter accessibility. This technique 467 was generally discussed in [RFC6163] and consisted of a matrix to 468 indicate possible connectivity along with wavelength constraints for 469 links/ports. Since regenerators or wavelength converters may be 470 considered a scarce resource it is desirable that the model include, 471 if desired, the usage state (availability) of individual 472 regenerators or converters in the pool. Models that incorporate more 473 state to further reveal blocking conditions on input or output to 474 particular converters are for further study and not included here. 476 The three stage model is shown schematically in Figure 1 and Figure 477 2. The difference between the two figures is that Figure 1 assumes 478 that each signal that can get to a resource block may do so, while 479 in Figure 2 the access to sets of resource blocks is via a shared 480 fiber which imposes its own wavelength collision constraint. The 481 representation of Figure 1 can have more than one input to each 482 resource block since each input represents a single wavelength 483 signal, while in Figure 2 shows a single multiplexed WDM inputinput 484 or output, e.g., a fiber, to/from each set of block. 486 This model assumes N input ports (fibers), P resource blocks 487 containing one or more identical resources (e.g. wavelength 488 converters), and M output ports (fibers). Since not all input ports 489 can necessarily reach each resource block, the model starts with a 490 resource pool input matrix RI(i,p) = {0,1} whether input port i can 491 reach potentially reach resource block p. 493 Since not all wavelengths can necessarily reach all the resources or 494 the resources may have limited input wavelength range the model has 495 a set of relatively static input port constraints for each resource. 496 In addition, if the access to a set of resource blocks is via a 497 shared fiber (Figure 2) this would impose a dynamic wavelength 498 availability constraint on that shared fiber. The resource block 499 input port constraint is modeled via a static wavelength set 500 mechanism and the case of shared access to a set of blocks is 501 modeled via a dynamic wavelength set mechanism. 503 Next a state vector RA(j) = {0,...,k} is used to track the number of 504 resources in resource block j in use. This is the only state kept in 505 the resource pool model. This state is not necessary for modeling 506 "fixed" transponder system or full OEO switches with WDM interfaces, 507 i.e., systems where there is no sharing. 509 After that, a set of static resource output wavelength constraints 510 and possibly dynamic shared output fiber constraints maybe used. The 511 static constraints indicate what wavelengths a particular resource 512 block can generate or are restricted to generating e.g., a fixed 513 regenerator would be limited to a single lambda. The dynamic 514 constraints would be used in the case where a single shared fiber is 515 used to output the resource block (Figure 2). 517 Finally, to complete the model, a resource pool output matrix 518 RE(p,k) = {0,1} depending on whether the output from resource block 519 p can reach output port k, may be used. 521 I1 +-------------+ +-------------+ E1 522 ----->| | +--------+ | |-----> 523 I2 | +------+ Rb #1 +-------+ | E2 524 ----->| | +--------+ | |-----> 525 | | | | 526 | Resource | +--------+ | Resource | 527 | Pool +------+ +-------+ Pool | 528 | | + Rb #2 + | | 529 | Input +------+ +-------| Output | 530 | Connection | +--------+ | Connection | 531 | Matrix | . | Matrix | 532 | | . | | 533 | | . | | 534 IN | | +--------+ | | EM 535 ----->| +------+ Rb #P +-------+ |-----> 536 | | +--------+ | | 537 +-------------+ ^ ^ +-------------+ 538 | | 539 | | 540 | | 541 | | 543 Input wavelength Output wavelength 544 constraints for constraints for 545 each resource each resource 547 Figure 1 Schematic diagram of resource pool model. 549 I1 +-------------+ +-------------+ E1 550 ----->| | +--------+ | |-----> 551 I2 | +======+ Rb #1 +-+ + | E2 552 ----->| | +--------+ | | |-----> 553 | | |=====| | 554 | Resource | +--------+ | | Resource | 555 | Pool | +-+ Rb #2 +-+ | Pool | 556 | | | +--------+ + | 557 | Input |====| | Output | 558 | Connection | | +--------+ | Connection | 559 | Matrix | +-| Rb #3 |=======| Matrix | 560 | | +--------+ | | 561 | | . | | 562 | | . | | 563 | | . | | 564 IN | | +--------+ | | EM 565 ----->| +======+ Rb #P +=======+ |-----> 566 | | +--------+ | | 567 +-------------+ ^ ^ +-------------+ 568 | | 569 | | 570 | | 571 Single (shared) fibers for block input and output 573 Input wavelength Output wavelength 574 availability for availability for 575 each block input fiber each block output fiber 577 Figure 2 Schematic diagram of resource pool model with shared block 578 accessibility. 580 Formally the model can be specified as: 582 584 ::= 585 587 588 ::=()... 591 Note that except for all the other components of 592 are relatively static. Also the 593 and are only used 594 in the cases of shared input or output access to the particular 595 block. See the resource block information in the next section to see 596 how this is specified. 598 5.2. Resource Signal Constraints and Processing Capabilities 600 The wavelength conversion abilities of a resource (e.g. regenerator, 601 wavelength converter) were modeled in the 602 previously discussed. As discussed in [RFC6163] the constraints on 603 an electro-optical resource can be modeled in terms of input 604 constraints, processing capabilities, and output constraints: 606 ::= ([] 607 [] )* 609 Where is a list of resource block identifiers with 610 the same characteristics. If this set is missing the constraints are 611 applied to the entire network element. 613 The are signal compatibility based constraints 614 and/or shared access constraint indication. The details of these 615 constraints are defined in section 5.3. 617 ::= [] 618 [] [] [] 620 The are important operations that the 621 resource (or network element) can perform on the signal. The details 622 of these capabilities are defined in section 5.3. 624 ::= [] 625 [] [] [] 627 The are either restrictions on the properties of 628 the signal leaving the block, options concerning the signal 629 properties when leaving the resource or shared fiber output 630 constraint indication. 632 := [] 633 [] 634 5.3. Compatibility and Capability Details 636 5.3.1. Shared Input or Output Indication 638 As discussed in the previous section and shown in Figure 2 the input 639 or output access to a resource block may be via a shared fiber. The 640 and elements are indicators for this 641 condition with respect to the block being described. 643 5.3.2. Modulation Type List 645 Modulation type, also known as optical tributary signal class, 646 comes in two distinct flavors: (i) ITU-T standardized types; (ii) 647 vendor specific types. The permitted modulation type list can 648 include any mixture of standardized and vendor specific types. 650 ::= 651 [|]... 653 Where the STANDARD_MODULATION object just represents one of the 654 ITU-T standardized optical tributary signal class and the 655 VENDOR_MODULATION object identifies one vendor specific 656 modulation type. 658 5.3.3. FEC Type List 660 Some devices can handle more than one FEC type and hence a list 661 is needed. 663 ::= [] 665 Where the FEC object represents one of the ITU-T standardized 666 FECs defined in [G.709], [G.707], [G.975.1] or a vendor-specific 667 FEC. 669 5.3.4. Bit Rate Range List 671 Some devices can handle more than one particular bit rate range 672 and hence a list is needed. 674 ::= []... 676 ::= 678 Where the START_RATE object represents the lower end of the range 679 and the END_RATE object represents the higher end of the range. 681 5.3.5. Acceptable Client Signal List 683 The list is simply: 685 ::=[]... 687 Where the Generalized Protocol Identifiers (GPID) object 688 represents one of the IETF standardized GPID values as defined in 689 [RFC3471] and [RFC4328]. 691 5.3.6. Processing Capability List 693 The ProcessingCapabilities were defined in Section 5.2 as follows: 695 ::= [] 696 [] [] [] 698 The processing capability list sub-TLV is a list of processing 699 functions that the WSON network element (NE) can perform on the 700 signal including: 702 1. Number of Resources within the block 704 2. Regeneration capability 706 3. Fault and performance monitoring 708 4. Vendor Specific capability 710 Note that the code points for Fault and performance monitoring and 711 vendor specific capability are subject to further study. 713 6. Link Information (General) 715 MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630], 716 [RFC5305] along with GMPLS routing protocol extensions for OSPF and 717 IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static 718 link information needed by the RWA process. However, WSON networks 719 bring in additional link related constraints. These stem from WDM 720 line system characterization, laser transmitter tuning restrictions, 721 and switching subsystem port wavelength constraints, e.g., colored 722 ROADM drop ports. 724 In the following summarize both information from existing GMPLS 725 route protocols and new information that maybe needed by the RWA 726 process. 728 ::= [] 729 [] [] []... 730 [] [] 732 6.1. Administrative Group 734 AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds 735 to one administrative group assigned to the interface. A link may 736 belong to multiple groups. This is a configured quantity and can be 737 used to influence routing decisions. 739 6.2. Interface Switching Capability Descriptor 741 InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different 742 switching capabilities on this GMPLS interface. In both [RFC4203] 743 and [RFC5307] this information gets combined with the maximum LSP 744 bandwidth that can be used on this link at eight different priority 745 levels. 747 6.3. Link Protection Type (for this link) 749 Protection: Defined in [RFC4202] and implemented in [RFC4203, 750 RFC5307]. Used to indicate what protection, if any, is guarding this 751 link. 753 6.4. Shared Risk Link Group Information 755 SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. 756 This allows for the grouping of links into shared risk groups, i.e., 757 those links that are likely, for some reason, to fail at the same 758 time. 760 6.5. Traffic Engineering Metric 762 TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the 763 definition of one additional link metric value for traffic 764 engineering separate from the IP link state routing protocols link 765 metric. Note that multiple "link metric values" could find use in 766 optical networks, however it would be more useful to the RWA process 767 to assign these specific meanings such as link mile metric, or 768 probability of failure metric, etc... 770 6.6. Port Label (Wavelength) Restrictions 772 Port label (wavelength) restrictions (PortLabelRestriction) model 773 the label (wavelength) restrictions that the link and various 774 optical devices such as OXCs, ROADMs, and waveband multiplexers may 775 impose on a port. These restrictions tell us what wavelength may or 776 may not be used on a link and are relatively static. This plays an 777 important role in fully characterizing a WSON switching device 778 [Switch]. Port wavelength restrictions are specified relative to the 779 port in general or to a specific connectivity matrix (section 4.1. 780 Reference [Switch] gives an example where both switch and fixed 781 connectivity matrices are used and both types of constraints occur 782 on the same port. Such restrictions could be applied generally to 783 other label types in GMPLS by adding new kinds of restrictions. 785 ::= [...] 786 [...] 788 ::= 789 [] 791 ::= 792 [] 794 ::= [...] [] 795 [] 797 Where 799 MatrixID is the ID of the corresponding connectivity matrix (section 800 4.1. 802 The RestrictionType parameter is used to specify general port 803 restrictions and matrix specific restrictions. It can take the 804 following values and meanings: 806 SIMPLE_WAVELENGTH: Simple wavelength set restriction; The 807 wavelength set parameter is required. 809 CHANNEL_COUNT: The number of channels is restricted to be less than 810 or equal to the Max number of channels parameter (which is 811 required). 813 PORT_WAVELENGTH_EXCLUSIVITY: A wavelength can be used at most once 814 among a given set of ports. The set of ports is specified as a 815 parameter to this constraint. 817 WAVEBAND1: Waveband device with a tunable center frequency and 818 passband. This constraint is characterized by the MaxWaveBandWidth 819 parameters which indicates the maximum width of the waveband in 820 terms of channels. Note that an additional wavelength set can be 821 used to indicate the overall tuning range. Specific center frequency 822 tuning information can be obtained from dynamic channel in use 823 information. It is assumed that both center frequency and bandwidth 824 (Q) tuning can be done without causing faults in existing signals. 826 Restriction specific parameters are used with one or more of the 827 previously listed restriction types. The currently defined 828 parameters are: 830 LabelSet is a conceptual set of labels (wavelengths). 832 MaxNumChannels is the maximum number of channels that can be 833 simultaneously used (relative to either a port or a matrix). 835 MaxWaveBandWidth is the maximum width of a tunable waveband 836 switching device. 838 PortSet is a conceptual set of ports. 840 For example, if the port is a "colored" drop port of a ROADM then 841 there are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 842 1, and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of 843 a single member corresponding to the frequency of the permitted 844 wavelength. See [Switch] for a complete waveband example. 846 This information model for port wavelength (label) restrictions is 847 fairly general in that it can be applied to ports that have label 848 restrictions only or to ports that are part of an asymmetric switch 849 and have label restrictions. In addition, the types of label 850 restrictions that can be supported are extensible. 852 6.6.1. Port-Wavelength Exclusivity Example 854 Although there can be many different ROADM or switch architectures 855 that can lead to the constraint where a lambda (label) maybe used at 856 most once on a set of ports Figure 3 shows a ROADM architecture 857 based on components known as a Wavelength Selective Switch 858 (WSS)[OFC08]. This ROADM is composed of splitters, combiners, and 859 WSSes. This ROADM has 11 output ports, which are numbered in the 860 diagram. Output ports 1-8 are known as drop ports and are intended 861 to support a single wavelength. Drop ports 1-4 output from WSS #2, 862 which is fed from WSS #1 via a single fiber. Due to this internal 863 structure a constraint is placed on the output ports 1-4 that a 864 lambda can be only used once over the group of ports (assuming uni- 865 cast and not multi-cast operation). Similarly the output ports 5-8 866 have a similar constraint due to the internal structure. 868 | A 869 v 10 | 870 +-------+ +-------+ 871 | Split | |WSS 6 | 872 +-------+ +-------+ 873 +----+ | | | | | | | | 874 | W | | | | | | | | +-------+ +----+ 875 | S |--------------+ | | | +-----+ | +----+ | | S | 876 9 | S |----------------|---|----|-------|------|----|---| p | 877 <--| |----------------|---|----|-------|----+ | +---| l |<- 878 - 879 | 5 |--------------+ | | | +-----+ | | +--| i | 880 +----+ | | | | | +------|-|-----|--| t | 881 +--------|-+ +----|-|---|------|----+ | +----+ 882 +----+ | | | | | | | | | 883 | S |-----|--------|----------+ | | | | | | +----+ 884 | p |-----|--------|------------|---|------|----|--|--| W | 885 -->| l |-----|-----+ | +----------+ | | | +--|--| S |11 886 | i |---+ | | | | +------------|------|-------|--| S |-- 887 > 888 | t | | | | | | | | | | +---|--| | 889 +----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 | 890 | | | +--|-|-|--------+ | | | | | +----+ 891 | | | | | | | | | | | | 892 +------+ +------+ +------+ +------+ 893 | WSS 1| | Split| | WSS 3| | Split| 894 +--+---+ +--+---+ +--+---+ +--+---+ 895 | A | A 896 v | v | 897 +-------+ +--+----+ +-------+ +--+----+ 898 | WSS 2 | | Comb. | | WSS 4 | | Comb. | 899 +-------+ +-------+ +-------+ +-------+ 900 1|2|3|4| A A A A 5|6|7|8| A A A A 901 v v v v | | | | v v v v | | | | 903 Figure 3 A ROADM composed from splitter, combiners, and WSSs. 905 7. Dynamic Components of the Information Model 907 In the previously presented information model there are a limited 908 number of information elements that are dynamic, i.e., subject to 909 change with subsequent establishment and teardown of connections. 910 Depending on the protocol used to convey this overall information 911 model it may be possible to send this dynamic information separate 912 from the relatively larger amount of static information needed to 913 characterize WSON's and their network elements. 915 7.1. Dynamic Link Information (General) 917 For WSON links wavelength availability and wavelengths in use for 918 shared backup purposes can be considered dynamic information and 919 hence are grouped with the dynamic information in the following set: 921 ::= 922 [] 924 AvailableLabels is a set of labels (wavelengths) currently available 925 on the link. Given this information and the port wavelength 926 restrictions one can also determine which wavelengths are currently 927 in use. This parameter could potential be used with other 928 technologies that GMPLS currently covers or may cover in the future. 930 SharedBackupLabels is a set of labels (wavelengths) currently used 931 for shared backup protection on the link. An example usage of this 932 information in a WSON setting is given in [Shared]. This parameter 933 could potential be used with other technologies that GMPLS currently 934 covers or may cover in the future. 936 Note that the above does not dictate a particular encoding or 937 placement for available label information. In some routing protocols 938 it may be advantageous or required to place this information within 939 another information element such as the interface switching 940 capability descriptor (ISCD). Consult routing protocol specific 941 extensions for details of placement of information elements. 943 7.2. Dynamic Node Information (WSON Specific) 945 Currently the only node information that can be considered dynamic 946 is the resource pool state and can be isolated into a dynamic node 947 information element as follows: 949 ::= [] 951 8. Security Considerations 953 This document discussed an information model for RWA computation in 954 WSONs. Such a model is very similar from a security standpoint of 955 the information that can be currently conveyed via GMPLS routing 956 protocols. Such information includes network topology, link state 957 and current utilization, and well as the capabilities of switches 958 and routers within the network. As such this information should be 959 protected from disclosure to unintended recipients. In addition, 960 the intentional modification of this information can significantly 961 affect network operations, particularly due to the large capacity of 962 the optical infrastructure to be controlled. 964 9. IANA Considerations 966 This informational document does not make any requests for IANA 967 action. 969 10. Acknowledgments 971 This document was prepared using 2-Word-v2.0.template.dot. 973 11. References 975 11.1. Normative References 977 [Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 978 Wavelength Assignment Information Encoding for Wavelength 979 Switched Optical Networks", work in progress: draft-ietf- 980 ccamp-rwa-wson-encode. 982 [G.707] ITU-T Recommendation G.707, Network node interface for the 983 synchronous digital hierarchy (SDH), January 2007. 985 [G.709] ITU-T Recommendation G.709, Interfaces for the Optical 986 Transport Network(OTN), March 2003. 988 [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for 989 high bit-rate DWDM submarine systems, February 2004. 991 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used 992 in Various Protocol Specifications", RFC 5511, April 2009. 994 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 995 Switching (GMPLS) Signaling Functional Description", RFC 996 3471, January 2003. 998 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 999 (TE) Extensions to OSPF Version 2", RFC 3630, September 1000 2003. 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 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1011 Switching (GMPLS) Signaling Extensions for G.709 Optical 1012 Transport Networks Control", RFC 4328, January 2006. 1014 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1015 Engineering", RFC 5305, October 2008. 1017 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1018 in Support of Generalized Multi-Protocol Label Switching 1019 (GMPLS)", RFC 5307, October 2008. 1021 11.2. Informative References 1023 [OFC08] P. Roorda and B. Collings, "Evolution to Colorless and 1024 Directionless ROADM Architectures," Optical Fiber 1025 communication/National Fiber Optic Engineers Conference, 1026 2008. OFC/NFOEC 2008. Conference on, 2008, pp. 1-3. 1028 [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in 1029 PCE-based WSON Networks", iPOP 2008, http://www.grotto- 1030 networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . 1032 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1033 WDM Wavelength Switching Systems for Use in GMPLS and 1034 Automated Path Computation", Journal of Optical 1035 Communications and Networking, vol. 1, June, 2009, pp. 1036 187-195. 1038 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 1039 engineering considerations, February 2006. 1041 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 1042 and PCE Control of Wavelength Switched Optical Networks", 1043 RFC 6163, April 2011. 1045 12. Contributors 1047 Diego Caviglia 1048 Ericsson 1049 Via A. Negrone 1/A 16153 1050 Genoa Italy 1052 Phone: +39 010 600 3736 1053 Email: diego.caviglia@(marconi.com, ericsson.com) 1055 Anders Gavler 1056 Acreo AB 1057 Electrum 236 1058 SE - 164 40 Kista Sweden 1060 Email: Anders.Gavler@acreo.se 1062 Jonas Martensson 1063 Acreo AB 1064 Electrum 236 1065 SE - 164 40 Kista, Sweden 1067 Email: Jonas.Martensson@acreo.se 1069 Itaru Nishioka 1070 NEC Corp. 1071 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1072 Japan 1074 Phone: +81 44 396 3287 1075 Email: i-nishioka@cb.jp.nec.com 1077 Lyndon Ong 1078 Ciena 1079 Email: lyong@ciena.com 1081 Cyril Margaria 1082 Nokia Siemens Networks 1083 St Martin Strasse 76 1084 Munich, 81541 1085 Germany 1086 Phone: +49 89 5159 16934 1087 Email: cyril.margaria@nsn.com 1089 Author's Addresses 1091 Greg M. Bernstein (ed.) 1092 Grotto Networking 1093 Fremont California, USA 1095 Phone: (510) 573-2237 1096 Email: gregb@grotto-networking.com 1098 Young Lee (ed.) 1099 Huawei Technologies 1100 1700 Alma Drive, Suite 100 1101 Plano, TX 75075 1102 USA 1104 Phone: (972) 509-5599 (x2240) 1105 Email: ylee@huawei.com 1107 Dan Li 1108 Huawei Technologies Co., Ltd. 1109 F3-5-B R&D Center, Huawei Base, 1110 Bantian, Longgang District 1111 Shenzhen 518129 P.R.China 1113 Phone: +86-755-28973237 1114 Email: danli@huawei.com 1116 Wataru Imajuku 1117 NTT Network Innovation Labs 1118 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1119 Japan 1121 Phone: +81-(46) 859-4315 1122 Email: imajuku.wataru@lab.ntt.co.jp 1124 Intellectual Property Statement 1126 The IETF Trust takes no position regarding the validity or scope of 1127 any Intellectual Property Rights or other rights that might be 1128 claimed to pertain to the implementation or use of the technology 1129 described in any IETF Document or the extent to which any license 1130 under such rights might or might not be available; nor does it 1131 represent that it has made any independent effort to identify any 1132 such rights. 1134 Copies of Intellectual Property disclosures made to the IETF 1135 Secretariat and any assurances of licenses to be made available, or 1136 the result of an attempt made to obtain a general license or 1137 permission for the use of such proprietary rights by implementers or 1138 users of this specification can be obtained from the IETF on-line 1139 IPR repository at http://www.ietf.org/ipr 1141 The IETF invites any interested party to bring to its attention any 1142 copyrights, patents or patent applications, or other proprietary 1143 rights that may cover technology that may be required to implement 1144 any standard or specification contained in an IETF Document. Please 1145 address the information to the IETF at ietf-ipr@ietf.org. 1147 Disclaimer of Validity 1149 All IETF Documents and the information contained therein are 1150 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1151 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1152 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1153 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1154 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1155 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1156 FOR A PARTICULAR PURPOSE. 1158 Acknowledgment 1160 Funding for the RFC Editor function is currently provided by the 1161 Internet Society.