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