idnits 2.17.1 draft-peloso-ccamp-wson-ospf-oeo-04.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 == Line 844 has weird spacing: '...ulation see ...' -- The document date (July 11, 2011) is 4674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC4202' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 1257, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-general-constraint-encode-04 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-rwa-wson-encode-11 == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-wson-signal-compatibility-ospf-04 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-11 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Peloso, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track G. Martinelli 5 Expires: January 12, 2012 Cisco 6 J. Meuric 7 France Telecom 8 C. Margaria 9 Nokia Siemens Networks 10 July 11, 2011 12 OSPF-TE Extensions for WSON-specific Network Element Constraints 13 draft-peloso-ccamp-wson-ospf-oeo-04 15 Abstract 17 The original content of this internet draft was to propose some 18 extentions to OSPF encoding in the context of Wavelength Switched 19 Optical Networks, especially for internal constraints of optical 20 network elements. General description can be found in the framework 21 document. 23 This update of the document still aims at specifying the detailled 24 structure of OSPF LSAs for WSONs. Nevertheless, the proposed LSA 25 layout slightly differs from the current content of the information 26 model and encodings drafts. As a result, the following sections 27 highlight the differences between both approaches and summarize why 28 the authors think these CCAMP's drafts would benefit from an update 29 according to the proposed description. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 12, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Summary of Information Model Changes . . . . . . . . . . . 5 68 2.2. Node Information (WSON specific) . . . . . . . . . . . . . 6 69 2.2.1. Label Restrictions . . . . . . . . . . . . . . . . . . 6 70 2.2.2. Resource Pools, Resource Blocks and Resource 71 Description Containers . . . . . . . . . . . . . . . . 7 72 2.2.3. Resource Pool Accessibility . . . . . . . . . . . . . 11 73 2.2.4. Resource Pool ID . . . . . . . . . . . . . . . . . . . 12 74 2.2.5. Resource Block State . . . . . . . . . . . . . . . . . 12 75 2.2.6. Resource Description . . . . . . . . . . . . . . . . . 13 76 2.2.7. Resource Pool Wavelength Constraints . . . . . . . . . 14 77 2.2.8. Shared Access Available Wavelengths . . . . . . . . . 15 78 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 3.1. Node related generic encodings . . . . . . . . . . . . . . 15 80 3.2. Node related WSON specific encodings . . . . . . . . . . . 16 81 3.2.1. Label Restrictions . . . . . . . . . . . . . . . . . . 16 82 3.2.2. Id Set Field . . . . . . . . . . . . . . . . . . . . . 16 83 3.2.3. Resource Pool Accessibility . . . . . . . . . . . . . 17 84 3.2.4. Resource Block State . . . . . . . . . . . . . . . . . 18 85 3.2.5. Resource Description . . . . . . . . . . . . . . . . . 18 86 3.2.6. Resource Pool Wavelength Constraints . . . . . . . . . 21 87 3.2.7. Shared Access Available Wavelengths . . . . . . . . . 22 88 3.2.8. Resource Pool . . . . . . . . . . . . . . . . . . . . 22 89 3.2.9. Resource Description Container . . . . . . . . . . . . 23 90 3.3. Link related encodings . . . . . . . . . . . . . . . . . . 23 91 4. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 24 92 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24 93 4.2. Link top level TLV . . . . . . . . . . . . . . . . . . . . 25 94 4.3. Node Attribute top level TLV . . . . . . . . . . . . . . . 26 95 4.4. Resource Pool top level TLV . . . . . . . . . . . . . . . 26 96 4.5. Resource Description Container top level TLV . . . . . . . 26 97 4.5.1. Resource Description sub-TLV . . . . . . . . . . . . . 27 98 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 99 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 105 Appendix A. Solution(s) Evaluation . . . . . . . . . . . . . . . 29 106 A.1. RBNFs Comparison . . . . . . . . . . . . . . . . . . . . . 30 107 A.2. Depiction of the considered cases for evaluation . . . . . 32 108 A.3. Comparing evaluation of the solutions . . . . . . . . . . 34 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 111 1. Introduction 113 The original content of this internet draft was to propose some 114 extentions to OSPF encoding in the context of Wavelength Switched 115 Optical Networks, especially for internal constraints of optical 116 network elements. General description can be found in the framework 117 document [RFC6163]. 119 This update of the document still aims at specifying the detailled 120 structure of OSPF LSAs for WSONs. Nevertheless, the proposed LSA 121 layout slightly differs from the current content of the information 122 model [I-D.ietf-ccamp-rwa-info] and encodings 123 [I-D.ietf-ccamp-rwa-wson-encode] drafts. As a result, the following 124 sections highlight the differences between both approaches and 125 summarize why the authors think these CCAMP's drafts would benefit 126 from an update according to the proposed description. 128 More specifically, the sections below follow the scope of current 129 documents, namely information model, encodings and OSPF-TE 130 extensions. Building the latter allowed to identify some 131 improvements which are described in the two former parts. In both, 132 the line has been drawn between the optical information that can be 133 specified by using generic protocol extensions and the one requiring 134 some WSON-specific objects, as agreed by the working group. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Information Model 144 This section provides a model of information needed by the routing 145 and wavelength assignment (RWA) process in wavelength switched 146 optical networks (WSONs). The purpose of the information described 147 in this model is to facilitate constrained optical path computation 148 in WSONs. This model takes into account compatibility constraints 149 between WSON signal attributes and network elements but does not 150 include constraints due to optical impairments. 152 The reduced Backus-Naur form (RBNF) syntax of [RFC5511] is used to 153 aid in defining the RWA information model. 155 The text in the following reports every WSON information model 156 modification compared to [I-D.ietf-ccamp-rwa-info]. Whenever a RBNF 157 term is used without explicit definition we assume the same format 158 and semantic of the original information model. 160 An initial sub section here below reports a summary of changes 161 introduced by this document. 163 2.1. Summary of Information Model Changes 165 In this document, most of the concepts and definitions from 166 [I-D.ietf-ccamp-rwa-info] remain the same. For instance, a "Resource 167 Block" is still "a group of devices with same features and same 168 connectivity constraints". 170 Compared to the aforementioned document, the following main changes 171 should be noticed: 173 1. The Resource Pool entity is introduced into the model, allowing 174 the definition of several resource entities per node, which can 175 be advertised independantly. A "Resource Pool" is defined as a 176 group of resource blocks with same connectivity constraints. 177 Several Resource Pools can be defined to associate them with 178 different properties. The goal is to decrease the size of OSPF 179 advertisement upon LSP changes (setup or tear down). 181 2. The connectivity matrix, defining the node capabilities on 182 interconnection of external links, is used in order to describe 183 connectivity constraints between node-external links and the 184 resource pools. Two advantages can be stressed. First, it 185 gathers all the static information into a node LSA, which OSPF-TE 186 is not required to advertise upon LSP updates. Then it limits 187 the number of connectivity representations introduced by 188 [draft-ietf-rwa-info] (which proposes similar TLVs in different 189 LSAs). 191 3. The scope of Resource Block Information is reduced, and focuses 192 only on resource/device description. The described device are 193 then efficiently instantiated by refering to these defined types. 194 This allows to separate the physical resource characteristics 195 from the way they are arranged in the node, thus having the 196 description completely independent from the node design. 198 As a result, this method allows to share resource description for all 199 the identical blocks of a node, thus decreasing the total size of 200 information. Furthermore, as this information is very static and 201 common to several resource blocks, it can be advertised and refreshed 202 independently to any other information. 204 2.2. Node Information (WSON specific) 206 As presented in [RFC6163] a WSON node may contain electro-optical 207 subsystems such as regenerators, wavelength converters or entire 208 switching subsystems. The model present here can be used in 209 characterizing the accessibility and availability of limited 210 resources such as regenerators or wavelength converters as well as 211 WSON signal attribute constraints of electro-optical subsystems. As 212 such this information element is fairly specific to WSON 213 technologies. 215 2.2.1. Label Restrictions 217 This section is a preamble presenting the Label Restriction entity, 218 which is refered many times later in this document. 220 Wavelength constraint are used in different part of the information 221 model, either as static constraints (in the resource pool as 222 RPWvlConstraints, and the resource block IngressWaveConstraint and 223 EgressWaveConstraint) or representing dynamic properties of a given 224 element (SharedAccessWvls in resource pool). In the GMPLS context 225 Wavelengths are physical instance of Labels. 227 The wavelength constraints used in this document, although having 228 different semantic, refer to the same notion of list of wavelength. 229 Those constraints apply in addition to either the incoming part of a 230 device (or group of device), the outgoing part or both if the 231 constraint is the same, which is for instance not unusual for static 232 wavelength constraint. 234 To support this concept, this section defines a field: 236 LABEL_RESTRICTIONS 238 that carry a label set information and for which direction this label 239 restriction is valid. The directions considered is upstream, 240 downstream or both. The label set information is the one defined in 241 [I-D.ietf-ccamp-rwa-info] as AvailableLabel. 243 This encoding is reused in different TLV or sub-TLV for different 244 semantic but do not require to define a TLV per direction. 246 ------ 247 DELTA: 249 - Define a generic information for label restrictions 251 - Reuse generic label set and provide a compact representation 253 2.2.2. Resource Pools, Resource Blocks and Resource Description 254 Containers 256 As presented in [RFC6163], a WSON node may include regenerators or 257 wavelength converters arranged in shared pools, and can include OEO 258 based WDM switches as well. There are plenty approaches used in the 259 design of WDM switches containing regenerator or converters. 260 However, from the point of view of path computation the following 261 need to be known: 263 1. The nodes that support regeneration or wavelength conversion. 265 2. The accessibility and availability of OEO devices to convert from 266 a given ingress wavelength on a particular ingress port to a 267 desired egress wavelength on a particular egress port, which are 268 summarized under the accessibility constraints. 270 3. Limitations on the types of signals that can be converted and the 271 conversions that can be performed, namely the processing 272 capabilities. 274 For modeling purposes and encoding efficiency regenerators or 275 wavelength converters with identical limitations and/or processing 276 and accessibility constraints are grouped into "blocks". Such blocks 277 can consist of a single resource, though grouping resources into 278 blocks leads to more efficient encodings. Then, these resource 279 blocks are gathered once more into resource pool, for which the 280 blocks share the same accessibility constraints. OEO devices sharing 281 accessibility constraints are likely to being multiplexed on a given 282 piece of equipment (like an Optical Amplifier, a splitter, a 283 Wavelength Selective Switch port, a length of fiber...). 285 Definitions: 287 - Resource Block: A group of resources sharing both the same 288 processing properties and the same accessibility constraints. 289 Each Resource Block can contain a different number of ressources, 290 but all the resources constituting the block are identical 291 devices. 293 - Resource Pool: A group of resources sharing the same 294 accessibility constraints, hence a Resource Pool becomes a group 295 of Resource Blocks sharing the same accessibility constraints. 296 Each Resource Pool can contain a different number of blocks, each 297 of different size, as long as all the devices in the pool are 298 subject to the same accessibility constraints regarding the way 299 these are linked to ingress and egress links of the WSON node 300 containing the pool. 302 The following picture represents the model of WSON nodes with the 303 help of Resource Blocks and Resource Pools entities. 304 +-----------+ 305 I1 +-----------+ | RP #1 | +-----------+ E1 306 ---->| | | +-------+ | | +----> 307 I2 | | | | Rb #1 | | | | E2 308 ---->| | | +-------+ | | +----> 309 | | | +-------+ | | | 310 | Resource +------+ | | +------+ Resource | 311 | Ingress | | | Rb #2 | | | Egress | 312 | Connectiv | | | | | | Connectiv | 313 | Matrix | | +-------+ | | Matrix | 314 | | +-----------+ | | 315 | | +-----------+ | | 316 I3 | | | RP #2 | | | E3 317 ---->| | | +-------+ | | +----> 318 I4 | | | | Rb #3 | | | | E4 319 ---->| +------+ +-------+ +------+ +----> 320 IN | | | +-------+ | | | EM 321 ---->| | | | Rb #P | | | +----> 322 | | | +-------+ | | | 323 +-----------+ +-----------+ +-----------+ 325 Figure 1 327 This figure shows a Resource Ingress Connectivity Matrix and another 328 one of the egress, the model from [I-D.ietf-ccamp-rwa-info] gathers 329 both these connectivity matrix inside a Resource Pool Accessibility 330 item, which would lead to the following definition of a Resource 331 Pool. 333 The following picture represents an abstracted model of the preceding 334 node, that corresponds to the information model chosen in this 335 document. 337 I1 +-----------------+ E1 338 ---->| +----> 339 I2 | | E2 340 ---->| Connectivity +----> 341 I3 | Matrix | E3 342 ---->| +----> 343 I4 | | E4 344 ---->| +----> 345 IN | | EM 346 ---->| +----> 347 RPEI#2| |RPII#2 348 +------->| |>-------+ 349 | RPEI#1| |RPII#1 | 350 | +--->| |>---+ | 351 | | +-----------------+ | | 352 | | | | 353 | | +-----------+ | | 354 | | | RP #1 | | | 355 | | | +-------+ | | | 356 | | | | Rb #1 | | | | 357 | | | +-------+ | | | 358 | | | +-------+ | | | 359 | +------<+ | | |<------+ | 360 | | | Rb #2 | | | 361 | | | | | | 362 | | +-------+ | | 363 | +-----------+ | 364 | +-----------+ | 365 | | RP #2 | | 366 | | +-------+ | | 367 | | | Rb #3 | | | 368 +----------<+ +-------+ +<----------+ 369 | +-------+ | 370 | | Rb #P | | 371 | +-------+ | 372 +-----------+ 374 Figure 2 376 Since by definitions Resource Pools indentify wavelength 377 accessibility to regeneration resources, Section 2.2.3 details how to 378 deal with accessibility constrains. This lead to the following 379 definition of a Resource Pool. 381 ::= ([]...) 382 ([]...) 383 ([]...) 385 - ResourcePoolID a unique (within node scope) number used to 386 identify the pool, 388 - SharedAccessWvls represents the dynamic spectral availability 389 coming from the usage of wavelengths by activated resources 390 inside the pool, 392 - ResourceBlockStates are used to provide the dynamic availability 393 of resources inside the pool. 395 - ResourcePoolWvlConstraints may be used to define the structural 396 (static) spectral constraints of accessibility of the pool. 398 A WSON node having some OEO resource might have from 1 to P resource 399 pools. The ResourcePool is created as an entity that will fit in a 400 dedicacted TLV (as sub-TLV) so the case of multiple Resource Pools 401 will be handled by fitting one or more Reource Pool entity in each 402 advertisment. The unique identifier ResourcePoolID allows to 403 distinguish among all available pools. 405 As this document means to have one Resource Pool entity per physical 406 pool of resources inside the node, inside a given node there is no 407 reason for its pools not to share type of resources, hence their 408 modeled respresentations refer to identical Resource Descriptions 409 entities. In order to avoid unnecessary information flooding, this 410 document gathers all these Resource Descriptions inside a dedicated 411 entity, that is named Resource Description Container. 413 ::= ... 415 The Resource Description Container is a list of Resource Descriptions 416 which, in turn, defines the features (i.e. physical characteristics) 417 of each type of resources held inside the pools (of a given node). 419 ------ 420 DELTA: 422 - Introduced definition of Resource Pool. 424 - Introduced definition of Resource Pool ID. 426 - Introduced definition of Resource Description Container. 428 - Changed accordingly Figure 1 and 2 from 429 [I-D.ietf-ccamp-rwa-info]. 431 - Changed the RBNF from [I-D.ietf-ccamp-rwa-info]. 433 - Changed the Resource Block Info into Resource Description (small 434 semantic change, due to minor internal changes. 436 - Adapted some pieces of models which were related to Resource 437 Block, to the Resource Pool level, namely: RPWvlConstraints 439 2.2.3. Resource Pool Accessibility 441 Every device inside a Resource Pool shares the same accessibility 442 constraints, hence the accessibility is a property related to the 443 pool. In order to depict the accessibility of a given pool, two 444 pieces of information needs to be described: 446 - Which ingress links of the node can be connected to the entry of 447 the Resource Pool, 449 - Which egress links of the node can be connected to the exit of 450 the Resource Pool. 452 Following remarks can be made concerning these accessibility 453 information: 455 - These information share the same nature as the one of the 456 Connectivity Matrix, 458 - These information are relatively static, changing only when the 459 switching fabric of the node is changing (either failure or 460 upgrade), 462 Hence, the accessibility information of every Resource Pool are 463 embedded together inside the node own's Connectivity Matrix. The 464 solution used to do that consists in using both Local Link 465 Identifiers and Resource Pool Identifiers inside the Link Sets of the 466 Connectivity Matrix. To keep unchanged the definition of the Link 467 Set, 32 bits unnumbered IDs for the Resource Pool are needed (see 468 Section 2.2.4). Thanks to this in the context of a node, the 469 Connectivity Matrix is then providing associations between: 471 - On one side a set composed of a mix of: (1) ingress link(s) and 472 (2) exit(s) of resource pool(s), 474 - On the other side a set composed of a mix of: (1) egress link(s) 475 and (2) entry(ies) of resource pool(s). 477 Then the RBNF for the Connectivity Matrix becomes, 478 ::= 479 ( )... 481 The Resource Pool Accessibility information are optional, if not 482 defined, Resource Pool is meant to have no accessibility constraints: 483 from every node ingress port it's possible to reach the pool and the 484 pool egress can reach every egress port of the node. 486 ------ 487 DELTA: 488 This section could be compared to the Resource Block Accessibility 489 constraint, and this is a major change that is proposed here. 491 2.2.4. Resource Pool ID 493 In order to encode directly resource pools accessibility, inside the 494 node's connectivity matrix, each Resource Pool needs to be identified 495 alike an internal link with one ID on each side (ingress and egress), 496 and then requires a Resource Pool ID. For each Resource Pool, WSON 497 node assigns one identifier to each side of the pool. This 498 identifier is a non-zero 32-bit number that is unique within the 499 scope of the WSON node that assigns it, hence the Resource Pool ID is 500 composed by a couple of unique numbers. 502 Consider a (resource) pool inside WSON node A. WSON node A chooses 503 two distincts identifiers for the pool (one for the ingress side and 504 one for the egress side). Considering these identifiers being unique 505 inside the scope of the WSON node A, implies that: no other 506 (resource) pool inside WSON node A may be assigned the value 507 corresponding to any of these two identifiers, neither any 508 (unnumbered) link between WSON node A and any other node may be 509 assigned a link local identifier (from the WSON node A perspective) 510 value corresponding to any of these two identifiers. 512 Support for resource pools in routing includes carrying information 513 about the identifiers of these pools. Specifically, when an LSR 514 advertises a resource pool, the advertisement carries both the 515 ingress and the egress identifiers of the link. 517 ::= 519 2.2.5. Resource Block State 521 The Resource Block State keep track of the current usage of a 522 resource block within a resource pool. 524 The state indicate for the resource the number of available resources 525 and optionnaly the total number (or maximum number) of resources. 526 decoupling ResourceDescription from the the ResourceBlock 527 configuration and allowing a better aggregation of the 528 ResourceDescription. The state available in info model is the 529 following: 531 Resource Block State definition 533 ::= [] 534 536 ------ 537 DELTA: 538 This definition of the Resource Block State allow to separate the 539 total number of resources from the resource description (differing in 540 this from [I-D.ietf-ccamp-rwa-info]). This enable a sharing of the 541 resource description between all the pools, while the other solution 542 requires that each pool holds the same number of devices to share the 543 same ResourceBlockDescription (see Section 2.2.6). 545 2.2.6. Resource Description 547 The resource block information contains the pieces of information 548 needed to fully identify the resource block static and dynamic 549 information. The static information consist of the characteristics 550 that do not depend on the LSPs using the resource block. In 551 particular the wavelength constraints are the one of the OEO and are 552 independent of the LSPs. the static information is described by a 553 ResourceDescription, which can be valid for several resource blocks, 554 then referenced by their ResourceBlockID. 556 The ResourceBlockID identifies a resource block, it is a node wide 557 stable and unique identifier (inside the node context). The 558 ResourceBlockID is defined in the ResourceBlockState TLV held in the 559 Resource Pool TLV and used in the Resource Description TLV. 561 := ... 562 564 with, 566 ::= [] [] 567 [] [] [] 569 ::= 570 [] [] 572 ::= [] [] 573 [] 575 IngressWaveConstraint and EgressWaveConstraint are described in 576 Section 2.2.7. The modulation-list and fec-list represent the list 577 of modulation formats and FEC encoding available within the resource 578 block. This information MAY be present in the advertisement, the 579 absence of this information means that potentially all Modulation and 580 FEC are accepted and possible cranckback may occur. 582 ------ 583 DELTA: 585 - Split between static (can be in a separate LSA or in the resource 586 pool) and dynamic information. 588 - The maximum number of resource is in the state to allow better 589 summarization of the resourceDescription 591 - The static information is describing the properties, the 592 ResourceDescription is more explicit than resourceInfo in this 593 context 595 - Changed the RBNF from [I-D.ietf-ccamp-rwa-info], make use of 596 generic label restriction for the wavelength restrictions. 598 2.2.7. Resource Pool Wavelength Constraints 600 This field defines any constraint at wavelength level within a 601 resource pool, and is meaningful only when a subset of wavelengths 602 could be configurable within the Pool. This information is static 603 since it depends on specific physical resources within the pools and 604 changes only if there is a node reconfiguration (OEO pools added or 605 removed from an optical node, change in the mux or demuxing devices). 606 As there is an ingress side and an egress side of a pool, this item 607 needs to modelize the wavelength usage on each side. 609 This field takes the format of a Label_Restrictions Section 2.2.1. 610 At most two instances of this item can be needed: one for each sides 611 (incoming / outgoing) of the pool. 613 The field is optional, when this field is not present it means there 614 are no specific wavelength constraints imposed by pool. As an 615 example this field is equivalent to the Maximum Bandwidth field 616 defined within [RFC3630]. As the Maximum Bandwith represents the 617 true link capacity, the RESOURCE_POOL_WAVELENGTH_CONSTRAINTS 618 represent the set of wavelengths that can possibly be configured on 619 the pool. 620 Note that the usable set of wavelengths could be limited by other 621 constraints: e.g. currently in-use wavelength (see Section 2.2.8) or 622 due to OEO device constraint on compliant wavelengths (see Wavelength 623 Constraints in Section 2.2.6). 625 ------ 626 DELTA: 627 Only wavelength constrain. While physical constraints are grouped in 628 another set. 630 2.2.8. Shared Access Available Wavelengths 632 The SHARED_ACCESS_AVAILABLE_WAVELENGTHS represents wavelength usage 633 in a Resource Pool hence it is related with the Resource Pool dynamic 634 state. 636 If a wavelength is in use within a pool, the same wavelength cannot 637 be reused in the same pool however the pool will be available for a 638 different wavelength depending on free resource blocks (Resource Pool 639 defintion as in Section 2.2.2). As there is an ingress side and 640 egress side of a pool, this item needs to modelize the wavelength 641 usage on each side. Hence, this representation automatically 642 considers the case of wavelength conversion happening inside the 643 pool. 645 This field takes the format of a Label_Restrictions Section 2.2.1. 646 At most two instances of this item can be needed: one for each sides 647 (incoming / outgoing) of the pool. 649 N.B.: Hence, SHARED_ACCESS_AVAILABLE_WAVELENGTHS has the same format 650 as RESOURCE_POOL_WAVELENGTH_CONSTRAINTS defined in Section 2.2.7. 652 ------ 653 DELTA: 654 Only wavelength constraint. While physical constraints are grouped 655 in another set. 657 3. Encoding 659 3.1. Node related generic encodings 661 In this section we propose modification to 662 [I-D.ietf-ccamp-general-constraint-encode]. 664 3.2. Node related WSON specific encodings 666 This section refer to [I-D.ietf-ccamp-rwa-wson-encode] 668 3.2.1. Label Restrictions 670 Relatively to section 2.2 of 671 [I-D.ietf-ccamp-general-constraint-encode] the LABEL_SET field is 672 here slightly modified in order to define a Label Restrictions field. 674 0 1 2 3 675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Action|U|D| Num Labels | Length | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Base Label | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Additional fields as necessary per action | 682 : : 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Although it make sense only using the actions 0-Inclusive List, 687 2-Inclusive Range or 4-Bitmap. The U bit indicate a label set 688 restriction valid at the upstream direction/incoming side of a 689 resource pool/resource block. The D bit indicate a label set 690 restriction valid at the downstrean/outgoing side of a resource pool/ 691 resource block. At least one of U or D bit MUST be set, both U and D 692 bit MAY be set. 694 ------ 695 DELTA: 696 The Num Labels field become 10 bits and this leave room for 1024 697 labels represented by this encoding. This encoding will be reused in 698 specific TLVs, in case more than 1024 labels are needed multiple 699 fields within TLVs can be used. 701 3.2.2. Id Set Field 703 With the introduction of resource description describing properties 704 for a group of resource block we need to efficiently represent a set 705 of IDs. To do so we introduce an IDSet field which has the same 706 encoding as the LinkSet field defined in 707 [I-D.ietf-ccamp-general-constraint-encode] but with a more generic 708 description. 710 ID Set Field 712 0 1 2 3 713 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Action |Dir| Format | Length | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Identifier 1 | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 : : : 720 : : : 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Identifier N | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 The Action, Dir have the same encoding as in 726 [I-D.ietf-ccamp-general-constraint-encode]. The Format field 727 indicates the format and length of the Identifier: 729 0 -- 32 Bit unnumbered identifier 731 1 -- IPv4 identifier 733 2 -- IPv6 identifier 735 This field is used later to define a set of resource blocks (e.g. to 736 list the resource blocks sharing the same resource description). 738 3.2.3. Resource Pool Accessibility 740 The Resource Pool Accessibility needs no encoding of its own. As 741 explained in the Section 2.2.3 this piece of information is merged 742 inside the Connectivity Matrix object which is actually not impacted 743 by this solution. 745 Nota: The Link Sets held inside the Connectivity Matrix are composed 746 of LINK_LOCAL_IDENTIFIERS (32 bits identifiers), and the solution to 747 describe the Resource Pool Accessibility consists in using either 748 RESOURCE_INGRESS_ID or RESOURCE_EGRESS_ID (also 32 bits identifiers) 749 which are by definition different from the LINK_LOCAL_IDENTIFIERS 750 (see Section 2.2.4). 752 ------ 753 DELTA: A major change here as the content of this field are moved 754 inside Connectivity Matrix. 756 3.2.4. Resource Block State 758 This TLV indicate the state of a resource block as defined in 759 Section 2.2.5. It defines the ResourceBlockId, and provides the 760 number of free resources and maximum in this resource block. The 761 ResourceBlockID field is a 32 bit node-wide identifier, 763 0 1 2 3 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | ResourceBlockID | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | CountAvailableResources | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | CountMaxResources | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 The information of the maximum number of resource is optional, this 776 is encoded with a value of 0 in the CountMaxResource field, or with a 777 Length value set to 8 instead of 12. 779 ------ 780 DELTA: 781 This is an adaptation of the resource pool status that fits the new 782 definition of resource description. 784 3.2.5. Resource Description 786 Resource Description sub-TLVs represent the information described in 787 Section 2.2.6. 789 The resource description TLV encoding follow the definition from 790 Section 2.2.6 with a list of sub-sub TLV. 792 Resource Description TLV 794 0 1 2 3 795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | ResourceBlockID Set Field | 800 : : 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Sub-TLVs (opt) | 803 : : 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 The ResourceBlockID Set Field is encoded using the IDSet field 807 encoding using the ResourceBlockID as identifier with format 0. 809 The Sub-Sub TLVs are defined as follow, the order does not matter. 810 Each of the Sub-Sub-TLV defined in this document MAY be repeated more 811 than once, on receipt all Sub-Sub-TLV MUST be taken into account. 812 The resulting information is the union of all the element of the Sub- 813 Sub-TLVs (all Sub-Sub-TLVs of this document describe lists). For 814 example an implementation may choose to indicate that in total 4 815 label can be used as 4 Label constraint Sub-Sub-tlv, each of them 816 with 1 label. 818 Info model Type Encoding 819 IngressWaveConstraint Label Label restriction, see 820 Constraints Section 3.2.1. 821 Input modulation-list Modulation A list of Modulation Format 822 List Fields, described in 823 [I-D.ietf-ccamp-rwa-wson-encode] 824 section 4.2.1. 825 Input fec-list FEC List A list of FEC type, described in 826 [I-D.ietf-ccamp-rwa-wson-encode] 827 section 4.3.1. 828 Input rate-range-list Rate Range A list of rate range field, 829 described in 830 [I-D.ietf-ccamp-rwa-wson-encode] 831 section 4.4.1. 832 Input Client A list of GPids, described in 833 client-signal-list Signal List [I-D.ietf-ccamp-rwa-wson-encode] 834 section 4.5. 836 ProcessingCapabilities Processing A list of Processing Capabilities 837 Capabilities Fields, except processing cap 838 "Number of Resources", described 839 in 840 [I-D.ietf-ccamp-rwa-wson-encode] 841 section 4.6.1. 842 EgressWaveConstraint Label Label restriction, see 843 Constraints Section 3.2.1. 844 Output modulation-list Modulation see Input modulation-list 845 List 846 Output fec-list FEC List see Input fec-list 848 Resource description Sub-Sub-TLVs and relation to info model 850 The Label Constraints Sub-Sub-TLV is used for IngressWaveConstraint 851 and EgressWaveConstraint as the Label Restriction field carries the U 852 and D bit to allow to distinguish a label restriction valid for 853 incoming, outgoing or both. 855 The Modulation List Sub-Sub-TLV is similarly used for the input and 856 output modulation list. The Sub-Sub-TLV contains a list of 857 Modulation format field, which indicate if they are valid for the 858 input (I bit set to 1) or for the output (I bit cleared). The list 859 of Modulation format field MUST contain at least one ingress FEC 860 modulation format. If no Egress modulation format is present in the 861 list it is implied that no modulation format conversion is 862 impossible, the egress modulation list is the same as the ingress 863 modulation list and modulation format is not performed. 865 The FEC list Sub-Sub-TLV is also representing both Input and Output 866 FEC list. The Sub-Sub-TLV is defined as a list of FEC Fields, 867 conceptually being Sub-Sub-Sub-TLVs indicating via the I bit if they 868 are valid for ingress or egress. At least one ingress FEC MUST be 869 present in the list, if no egress modulation format is present in the 870 list it is implied that the egress FEC list is the same as the 871 ingress FEC list. In such case FEC format conversion MAY be 872 performed. 874 The Processing Capabilities Sub-Sub-TLV is the same as in 875 [I-D.ietf-ccamp-rwa-wson-encode] section 4.6.1. except for the 876 maximum number of resource which is represented in the 877 ResourceBlockState. The FEC and Modulation format conversion 878 capabilities are expressed via the Modulation and FEC list by not 879 including any egress modulation/fec in the respective lists. 881 Bit-Rate Range and Client Signal lists are unchanged from 882 [I-D.ietf-ccamp-rwa-wson-encode] 883 ------ 884 DELTA: 886 - use a common TLV for the label restriction 888 - use a common TLV for the FEC list 890 - use a common TLV for the Modulation format list 892 - re-use indirectly (via ID Set) the general encoding LinkSet for 893 RBlockId set 895 - More explicit statement on FEC and Modulation format conversion 896 capabilities 898 3.2.6. Resource Pool Wavelength Constraints 900 This TLV is used to describe static wavelength constraint, it follows 901 the encoding of Label_Restrictions field Section 3.2.1 903 RESOURCE_POOL_WAVELENGTH_CONSTRAINTS TLV 905 0 1 2 3 906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type | Length | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Label_Restrictions field(s) | 911 : : 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 The Label_Restrictions field might be repeased several times 915 depending on the U and D bit flags. In case multiple fields with the 916 same U and D bits set to 1, the final resulting constrain will be the 917 intersection of all Label_Restrictions. If multiple TLVs are present 918 the resulting constraint is the intersection of all the TLV. 920 Example below: 922 - No RESOURCE_POOL_WAVELENGTH_CONSTRAINTS TLV meaning that these 923 type of constraints are not described. 925 - A TLV present with one Label_Restrictions field with both the U 926 or D bits MUST be set to 1. Which means the same constrains 927 apply to both sides of the pool. 929 - A TLV present with three Label_Restrictions field presents, one 930 field with U=1 so applicable upstream. The two other fields with 931 D=1 so applicable downstream 933 ------ 934 DELTA: Small delta, just using the add-on bits to provide a 935 direction/side semantic. 937 3.2.7. Shared Access Available Wavelengths 939 This TLV is used to describe dynamic wavelength availability, it 940 follows the encoding of Label_Restrictions field. Section 3.2.1 942 SHARED_ACCESS_AVAILABLE_WAVELENGTH TLV 944 0 1 2 3 945 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Label_Restrictions field(s) | 950 : : 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 The same rules and usage defined in Section 3.2.6 apply here. 955 3.2.8. Resource Pool 957 The RESOURCE_POOL TLV contains the preceding TLVs. 959 0 1 2 3 960 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | RESOURCE_INGRESS_ID | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | RESOURCE_EGRESS_ID | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Sub-TLVs as needed (Opt) | 969 : : 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 List of possible Sub-TLVs: 973 Name Static/Dynamic 974 Resource Block State Dynamic 975 Shared Access Available Wavelength Dynamic 976 Resource Pool Wavelength Constraints Static 978 ------ 979 DELTA: 980 Similar to Resource Pool inside [I-D.ietf-ccamp-rwa-wson-encode] with 981 a different internal layout that allows for multiple instances. 983 3.2.9. Resource Description Container 985 The RESOURCE_DESCRIPTION_CONTAINER is a list of RESOURCE_DESCRIPTION. 986 This one MAY be used to extract the static content of the previous 987 TLV, in order to hold all this content inside this purposely defined 988 static TLV. Then each one can be in separatly flooded entities (e.g. 989 in separated LSAs see Section 4.1. 991 0 1 2 3 992 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type | Length | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | RESOURCE_DESCRIPTION | 997 : : 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 : : 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | RESOURCE_DESCRIPTION | 1002 : : 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 ------ 1006 DELTA: 1007 New item. 1009 3.3. Link related encodings 1011 This section does not differ from the equivalent in 1012 [I-D.ietf-ccamp-general-constraint-encode] 1014 4. OSPF-TE Extensions 1016 This section handles OSPF-TE extensions. 1018 It starts with introducing the top view of the extensions provided by 1019 this draft. Then a sub-section dedicated for each top level TLV 1020 details the extensions relevant for this top level TLV. 1022 4.1. Introduction 1024 This introduction provides the layout of the preceding information 1025 model (Section 2) and encodings (Section 3) into top-level TLVs of 1026 opaque LSAs. 1028 [RFC3630] introduces Link top level TLV (type 2). This document 1029 extends its content with the encodings depicted in Section 3.3. 1030 These extensions offer the capability to advertise restrictions on 1031 the list of available labels. 1032 N.B.: This capability is specifically useful when these labels have a 1033 network wide semantic like suggested in a WSON context. 1035 [RFC5786] introduces Node Attribute top level TLV (type 5). This 1036 document extends its content with the encodings depicted in 1037 Section 3.1. These extensions offer the capability to advertise 1038 restrictions on the switching capabilities of the node. 1039 N.B.: This TLV is unique for a given node and contains static 1040 information only, hence no more than one LSA per node is expected to 1041 host such a TLV. 1043 This document introduces a new top level TLV named RESOURCE_POOL 1044 (type value to be defined), which encodings are depicted in 1045 Section 3.2. RESOURCE_POOL TLV offers the capability to advertise 1046 one or multiple pools of OEO devices held in a given node. This 1047 object can carry resource descriptions, the available resources 1048 inside the pool(s) and the availability of wavelengths to reach the 1049 pool (refer to pool definition inside Section 2.2.2). 1050 N.B.: A LSA can contain more than one RESOURCE_POOL top level TLV 1051 (allowing one LSA to advertise the description of all the pools of 1052 the originating node). Alternatively, a node can originate more than 1053 one LSA containing each RESOURCE_POOL top level TLVs (allowing each 1054 LSA to advertise an individual pool). In that case all the 1055 RESOURCE_POOL originated by the same node MUST have different 1056 RESOURCE_POOL_ID. As most of the information contained inside a 1057 RESOURCE_POOL are dynamic, an implementer may well choose to define 1058 one LSA per pool of resources in order to reduce the quantity of 1059 information flooded upon change in resource usage. 1061 This document introduces another new top level TLV named 1062 RESOURCE_DESCRIPTION_CONTAINER (type value to be defined), which 1063 encoding is depicted in Section 3.2.9. 1064 RESOURCE_DESCRIPTION_CONTAINER TLV contains a list of 1065 RESOURCE_DESCRIPTION valid in the scope of the originating node. A 1066 given node MUST NOT originate more than one LSA containing 1067 RESOURCE_DESCRIPTION_CONTAINER TLV. An LSA containing a 1068 RESOURCE_DESCRIPTION_CONTAINER TLV MUST NOT contain any additional 1069 top level TLV. 1070 N.B.: This TLV is designed to be unique in the scope of the 1071 originating node and to gather all the resource descriptions relevant 1072 in this scope. 1074 Summarizing Table 1076 Top-TLV Type Name Instances Static/Dynamic 1077 2 Link 1 per fiber Mix 1078 5 Node Attribute 1 per Node Static 1079 TBD Resource Pool 1 per Pool Dynamic 1080 TBD Resource Desc Cont 1 per Node Static 1082 ------ 1083 DELTA: 1085 - Renamed the Node Optical Property tlv into Resource Pool TLV 1087 - Allow multiple instance of Resource Pool TLV 1089 - Introduced an optional new TLV named Resource Description 1091 4.2. Link top level TLV 1093 This section refer to 1094 [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]. 1096 The following new sub-TLVs are added to the Link top level TLV (type 1097 2). 1099 Sub-TLV Type Length Name 1100 TBD variable Port Label Restrictions 1101 TBD variable Available Wavelengths 1102 TBD variable Shared Backup Wavelengths 1104 In Link TLV, all the sub-TLV listed above are optional. 1106 4.3. Node Attribute top level TLV 1108 This section refer to 1109 [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]. 1111 The following new sub-TLVs are added to the Node Attribute top level 1112 TLV (type 5). 1114 Sub-TLV Type Length Name 1115 TBD variable Connectivity Matrix 1116 TBD variable Port Label Restrictions 1117 TBD variable Shared Risk Node Group 1119 In Node Attribute, all the sub-TLV listed above are optional. None 1120 of them contain sub-TLV. 1122 4.4. Resource Pool top level TLV 1124 This section refer to [I-D.ietf-ccamp-wson-signal-compatibility-ospf] 1126 The following sub-TLVs are created for the Resource Pool top level 1127 TLV. 1129 Sub-TLV Type Length Name 1130 TBD variable Resource Block State 1131 TBD variable Shared Access Available Wavelength 1132 TBD variable Resource Pool Wavelength Constraints 1134 In Resource Pool, all the sub-TLV listed above are optional. 1136 4.5. Resource Description Container top level TLV 1138 This section refer to [I-D.ietf-ccamp-wson-signal-compatibility-ospf] 1140 The following sub-TLVs are created for the Resource Description 1141 Container top level TLV. 1143 Sub-TLV Type Length Name 1144 TBD variable Resource Description 1146 4.5.1. Resource Description sub-TLV 1148 The following sub-TLVs are created for the Resource Pool top level 1149 TLV. 1151 Sub-TLV Type Length Name 1152 TBD variable Modulation List 1153 TBD variable FEC List 1154 TBD variable Rate Range List 1155 TBD variable Client Signal List 1156 TBD variable Processing Capabilities 1157 TBD variable Label Constraints 1159 In Resource Description, all the sub-TLV listed above are optional. 1161 5. Acknowledgements 1163 This template was derived from an initial version written by Pekka 1164 Savola and contributed by him to the xml2rfc project. 1166 This document shares common material with the documents quoted, which 1167 seems fair as the target of this version is to highlight differences. 1169 The editors wish to thank Ramon Casellas for his constructive 1170 comments. 1172 6. Contributors 1174 Daniele Ceccarelli 1175 Ericsson 1176 Via A. Negrone 1/A 1177 Genova - Sestri Ponente 1178 Italy 1180 Email: daniele.ceccarelli@ericsson.com 1182 7. IANA Considerations 1184 This memo requires many requests to IANA, which will be completed in 1185 a latter version. 1187 8. Security Considerations 1189 All drafts are required to have a security considerations section. 1190 See RFC 3552 [RFC3552] for a guide. 1192 9. References 1194 9.1. Normative References 1196 [I-D.ietf-ccamp-general-constraint-encode] 1197 Bernstein, G., "General Network Element Constraint 1198 Encoding for GMPLS Controlled Networks", 1199 draft-ietf-ccamp-general-constraint-encode-04 (work in 1200 progress), December 2010. 1202 [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te] 1203 Zhang, F., Lee, Y., Han, J., Bernstein, G., Xu, Y., Zhang, 1204 G., Li, D., Chen, M., and Y. Ye, "OSPF-TE Extensions for 1205 General Network Element Constraints", 1206 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 1207 (work in progress), March 2011. 1209 [I-D.ietf-ccamp-rwa-wson-encode] 1210 Bernstein, G., Lee, Y., Li, D., Imajuku, W., and J. Han, 1211 "Routing and Wavelength Assignment Information Encoding 1212 for Wavelength Switched Optical Networks", 1213 draft-ietf-ccamp-rwa-wson-encode-11 (work in progress), 1214 March 2011. 1216 [I-D.ietf-ccamp-wson-signal-compatibility-ospf] 1217 Lee, Y. and G. Bernstein, "OSPF Enhancement for Signal and 1218 Network Element Compatibility for Wavelength Switched 1219 Optical Networks", 1220 draft-ietf-ccamp-wson-signal-compatibility-ospf-04 (work 1221 in progress), March 2011. 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, March 1997. 1226 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1227 June 1999. 1229 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1230 Text on Security Considerations", BCP 72, RFC 3552, 1231 July 2003. 1233 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1234 (TE) Extensions to OSPF Version 2", RFC 3630, 1235 September 2003. 1237 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1238 Support of Generalized Multi-Protocol Label Switching 1239 (GMPLS)", RFC 4202, October 2005. 1241 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1242 Used to Form Encoding Rules in Various Routing Protocol 1243 Specifications", RFC 5511, April 2009. 1245 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 1246 Local Addresses in OSPF Traffic Engineering (TE) 1247 Extensions", RFC 5786, March 2010. 1249 9.2. Informative References 1251 [I-D.ietf-ccamp-rwa-info] 1252 Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing 1253 and Wavelength Assignment Information Model for Wavelength 1254 Switched Optical Networks", draft-ietf-ccamp-rwa-info-11 1255 (work in progress), March 2011. 1257 [I-D.narten-iana-considerations-rfc2434bis] 1258 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1259 IANA Considerations Section in RFCs", 1260 draft-narten-iana-considerations-rfc2434bis-09 (work in 1261 progress), March 2008. 1263 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 1264 GMPLS and Path Computation Element (PCE) Control of 1265 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 1266 April 2011. 1268 Appendix A. Solution(s) Evaluation 1270 Within this section we try evaluate the amount of information that 1271 needs to be exchanged through routing advertisements. For this 1272 evaluation we consider some minimum optical node reference design to 1273 make a OEO extension future proof. 1275 This sections starts with summarizing the LSAs needed to depict a 1276 node with both the solution depicted by this document and the 1277 solution depicted by [I-D.ietf-ccamp-rwa-info]. Afterwards, the 1278 hypothesis concerning the node features that will serve as a basis 1279 for the solution evaluation will be presented, before the actual 1280 results of the solutions evaluations (both the one of this document 1281 and the one of [I-D.ietf-ccamp-rwa-info]). 1283 A.1. RBNFs Comparison 1285 In this section we try compare the how TLVs are composed according 1286 two this draft proposal versus existing WSON solutions. The goal 1287 here is to provide the all reference for and easy understanding where 1288 two solutions are different. Numbers will be provided in the next 1289 section. 1291 The evaluation will be done on the Resource Pool top-level TLV since 1292 the Node address and Link TLV are considered equivalent. 1294 WSON Drafts. According to 1295 [I-D.ietf-ccamp-wson-signal-compatibility-ospf] in section 2 defines 1296 the Optical Node Property TLV which collect the WSON specific 1297 information. This TLV is composed of the following: 1299 ::= []... 1300 []... []... 1301 [...] [...] 1303 a) Resource Block Information. Defined as : ([] 1304 ). 1305 A resource block information defines here the number of devices 1306 inside the block. 1308 b) Resource Block Accessibility. Defined as ( 1309 ) which is expanded in tuples like 1310 ()* and 1311 ()*. Note that INGRESS/ 1312 EGRESS_LINK_SET is a name defined here for the link set field 1313 used in the [I-D.ietf-ccamp-rwa-info] document. 1315 c) Resource Block Wavelength Constraints. Defined as 1316 . This is 1317 expanded in INPUT_WAVELENGHT_SET 1318 OUTPUT_WAVELENGTH_SET, for the static constraints of resource 1319 blocks. 1321 d) Shared Access Wavelengths. Defined as 1322 . This is 1323 expanded in INPUT_WAVELENGHT_SET 1324 OUTPUT_WAVELENGTH_SET, for the shared fibers between blocks. 1326 e) Resource Block Pool State. 1328 In current proposal there are two types of TLV. 1330 First the Resource Pool TLV (with an instance per pool) is composed 1331 of the following information: 1333 ::= []... 1334 []... []... 1335 []... 1337 a) Resource Description. Which is defined as: (...) 1338 . 1339 This is equivalent to the item a) above without the number of 1340 devices inside the resource block, which allow this definition to 1341 be usable by any block. The number of available resource of a 1342 given type inside the pool being specified by the Resource Block 1343 State below. When a Resource Description Container TLV is 1344 defined by a Node, the Resource Pool TLV of this same node SHOULD 1345 NOT contain any Resource Description sub-TLV. 1347 b) Resource Block State. Where RBlockState is defined as 1348 [] . This field 1349 efficienty report how many of a given resource type is available 1350 inside the pool or not. 1352 c) Shared Access Available Wavelength. This is composed of a Label 1353 Restriction field and SHOULD used to depict the dynamic 1354 constraints of the pool. 1356 d) Resource Pool Wavelength Constraints. This is composed of a 1357 Label Restriction field and MAY be used to depict the static 1358 constraints of the pool. 1360 Second the Resource Descriptor Container TLV (with a single instance 1361 per node) is used to gather all the Resource Descriptions of a given 1362 node, as these are static information composed of the following 1363 information: 1365 ::= ... 1367 a) Resource Description. Which is defined as: (...) 1368 . 1369 This is equivalent to the item a) above. 1371 A.2. Depiction of the considered cases for evaluation 1373 For the sake of the comparison we have considered the following 1374 parameters and values characterizing the optical node design: 1376 o Node Degree Connectivity: 4, 8 and 16. 1378 o WDM capacity: 100 wavelengths. 1380 o Switching capacity. Defines the total node switching capability 1381 and is calculated as Node Degree Connectivity x 100 wavelengths. 1383 o Regeneration Capability. We assume a value of 5% of the total 1384 switching capacity. 1386 o Add/Drop Capability. We assume a typical value of 25% of the 1387 switching capability. So in the average up to 30 wavelengths per 1388 incoming fiber can be added/dropped within the optical node. 1390 o Resource pool setup and capabilities. A physical resource pool 1391 contains a mix of Add/Drop and Regeneration capabilities. This 1392 has the effect of increasing the number of resource pool 1393 advertized. Resource pool can be fully flexible (connected to any 1394 port), partial (only to some port) or Fixed (can only be connected 1395 to one direction). This parameter influences the complexity of 1396 the connectivity matrix. 1398 o Number of Regenerator types. For a given node the number of OEO 1399 capabilities is limited, it is typically decided by the type of 1400 electrical equipment and optical modules (emitting laser and 1401 optical receiver). 1403 o Blocking Ratio. The Spatial/Spectral blocking ratio indicates how 1404 much port-based/wavelength based blocking a node is experiencing. 1406 For example considering the typical design it results in the 1407 following static layout: 1409 o 3 OEO pools each having 3 Resource Block inside. 1411 o Connectivity Matrix: (8+30+30) 64x64 if considering one 1412 connectivity matrix. Ingress=64x3, Egress=3x64 (considering the 1413 OEO access with a multiple-wavelength link). 1415 The following types of nodes and node designs were considered in this 1416 evaluation: 1418 Node Types and designs 1420 Node Type Nodal Degree Pool Type Blocking 1421 Small(S), Flexible 4 Partial None 1422 Small(S), Fixed(port) 4 Fixed Port 1423 Small(S), Fixed(label) 4 Partial Lambda 1424 Middle(M), Flexible 8 Flexible None 1425 Large(L), Flexible 16 Flexible None 1427 For the small nodes, 5 different type of regenerators are considered, 1428 for the Middle and Large ones 10 different type of regenerators are 1429 considered. Based on those designs we derived the following 1430 important figures: 1432 o Number of resourcePool : depends on the pool type and 1433 connectivity, which depend on the port blocking and number of Add/ 1434 Drop and Regenerator capacity. 1436 o Number of resourceBlock. There is two numbers to be considered 1437 here : the number of resourceBlock for a given resource pool (this 1438 document) and total number of resourceBlock 1439 ([I-D.ietf-ccamp-rwa-info]). In this document the number of 1440 resource block within a resource pool is, worst case, the number 1441 of possible regenerator types, whereas in 1442 [I-D.ietf-ccamp-rwa-info] the number of resource block depends on 1443 the number of OEO types and on the connectivity. 1445 o Number of connectivity matrix/number of pairs/link per pairs. The 1446 number of sub-matrix increase depending on the port blocking 1447 ratio, the number of pair in one connectivity matrix depends on 1448 the wavelength restrictions. Those two criteria do not depend on 1449 which information model is considered. The number of link per set 1450 is increased by the number of resource pool in this draft. 1452 Those numbers for each node are shown in the following table: 1454 Details of information elements per node 1456 Node Type # Pools Resource Blocks Matrix/Pair/Links 1457 S, Flexible 6 5 (30) 1/1/10 (1/1/1) 1458 S, Fixed(port) 12 5 (60) 4/4/4 (4/4/1) 1459 S, Fixed(label) 6 5 (30) 4/1/10 (4/1/1) 1460 M, Flexible 3 10 (30) 1/1/11 (1/1/1) 1461 L, Flexible 5 10 (50) 1/1/21 (1/1/1) 1463 Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between 1464 brackets. 1466 For further reading easiness the above table could be further 1467 expanded as the following one: 1469 Details of information elements per node 1471 Node Type #Pools #Device #Blocks #ResProp Matrix/Pair/Links 1472 Type TLV 1473 S, Flexible 6 5 (30) 30 5 (25) 1/1/10 (1/1/1) 1474 S, Fixed(port) 12 5 (60) 60 5 (45) 4/4/4 (4/4/1) 1475 S,Fixed(label) 6 5 (30) 30 5 (25) 4/1/10 (4/1/1) 1476 M, Flexible 3 10 (30) 30 10 (35) 1/1/11 (1/1/1) 1477 L, Flexible 5 10 (50) 50 10 (40) 1/1/21 (1/1/1) 1479 Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between 1480 brackets. 1482 A.3. Comparing evaluation of the solutions 1484 Based on those key information model elements both the tables "LSA 1485 size" indicate the size of the LSAs in this document and in 1486 [I-D.ietf-ccamp-rwa-wson-encode]. Number of flooded LSAs of a given 1487 type are indicated between brackets (when bigger than 1). 1489 Solution of this document - Average size (and number) of LSAs per 1490 node type (unit: bytes) 1492 Node Type Node Attr LSA Resource Pool LSA Resource Desc LSA 1493 S, Flexible 117 120 (6) 524 1494 S, Fixed(port) 692 120 (12) 644 1495 S, Fixed(label) 620 120 (6) 524 1496 M, Flexible 127 120 (3) 904 1497 L, Flexible 209 120 (5) 984 1499 Solution of [I-D.ietf-ccamp-rwa-wson-encode] - Average size (and 1500 number) of LSAs per node type (unit: bytes) 1502 Node Type Node Attr LSA Optical Node LSA 1503 S, Flexible 49 2801 1504 S, Fixed(port) 340 2980 1505 S, Fixed(label) 132 4118 1506 M, Flexible 52 2980 1507 L, Flexible 54 2809 1509 The Resource Description Container LSA contains several resource 1510 description TLVs. This LSA is smaller than the corresponding in 1511 [I-D.ietf-ccamp-rwa-wson-encode] mainly because the resource 1512 description do not depend on the port/lambda connectivity and number 1513 of device per block, thus allowing a better sharing of the 1514 information depicting the oeo capabilities. 1516 The following summarizing table indicates the size of the sum of all 1517 LSA and the average size per update. In this document all the 1518 dynamic part is in the resource pool, allowing a more efficient 1519 updating behavior. The evaluation for 1520 [I-D.ietf-ccamp-rwa-wson-encode] are best case/worst case; the best 1521 case being an update of the RBState TLV and SharedAccessPool TLV 1522 only, which requires a multi-instance implementation of OSPF. 1524 Summarizing Table (unit:bytes) 1526 Node Type Total LSA size Total number of Avg size of an 1527 LSA update 1528 S, Flexible 1361 (2850) 8 (2) 120 (616/2801) 1529 S, Fixed(port) 2776 (5411) 14 (2) 120 (1192/2980) 1530 S, Fixed(label) 1864 (2941) 8 (2) 120 (616/4118) 1531 M, Flexible 1391 (3032) 5 (2) 120 (448/2980) 1532 L, Flexible 1793 (4172) 7 (2) 120 (720/2809) 1534 Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between 1535 brackets 1537 The node design considered are typical case, a worst case can be a 1538 node with high nodal degree, with lots of port and wavelength 1539 constraints. With considering a nodal degree of 8, resulting in 28 1540 resource pool and 140 resource blocks, the total size is 9816 (11820) 1541 with 30 (2) LSAs. 1543 Authors' Addresses 1545 Pierre Peloso (editor) 1546 Alcatel-Lucent 1547 R.te de Villejust 1548 Nozay, 91620 1549 France 1551 Phone: +33 130 702 662 1552 Email: pierre.peloso@alcatel-lucent.com 1554 Giovanni Martinelli 1555 Cisco 1556 Monza, 20900 1557 Italy 1559 Phone: +39 039 209 2044 1560 Email: giomarti@cisco.com 1562 Julien Meuric 1563 France Telecom 1564 2, av. Pierre Marzin 1565 Lannion, 22307 1566 France 1568 Phone: +33 296 052 828 1569 Email: julien.meuric@orange-ftgroup.com 1571 Cyril Margaria 1572 Nokia Siemens Networks 1573 St-Martin str. 76 1574 Munchen, 81541 1575 Germany 1577 Phone: +49-89-5159-16934 1578 Email: cyril.margaria@nsn.com