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