idnits 2.17.1 draft-lee-teas-actn-abstraction-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 543: '... MUST be defined and configured/ne...' RFC 2119 keyword, line 554: '... MUST be defined and configured/ne...' RFC 2119 keyword, line 571: '..., the type of abstraction MUST and its...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-frame' is mentioned on line 345, but not defined Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG 2 Young Lee 3 Internet Draft Dhruv Dhody 4 Intended status: Informational Huawei 6 Daniele Ceccarelli 7 Ericsson 9 Oscar Gonzalez de Dios 10 Telefonica 12 Expires: September 2017 14 March 13, 2017 16 Abstraction and Control of TE Networks (ACTN) Abstraction Methods 18 draft-lee-teas-actn-abstraction-01 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 13, 2017. 43 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 Abstraction and Control of Traffic Engineering (TE) Networks(ACTN) 60 refers to the set of virtual network operations needed to 61 orchestrate, control and manage large-scale multi-domain TE 62 networks, so as to facilitate network programmability, automation, 63 and efficient resource sharing. 65 As the ACTN architecture considers abstraction as one of the 66 important building blocks, this document describes a few 67 alternatives methods of abstraction for both packet and optical 68 networks. This is an important consideration since the choice of the 69 abstraction method impacts protocol design and the information it 70 carries. 72 Table of Contents 74 1. Introduction...................................................3 75 2. ACTN Architecture..............................................4 76 3. Abstraction Factors and Methods................................5 77 3.1. No abstraction (native/white topology)....................6 78 3.2. One Abstract Node (black topology)........................7 79 3.3. Abstraction of TE tunnels for all pairs of border nodes 80 (grey topology)................................................9 81 3.3.1. Grey topology type A: border nodes with a TE links 82 between them in a full mesh fashion........................10 83 3.3.2. Grey topology Type B................................11 84 3.4. How to build grey topology...............................11 85 3.4.1. Automatic generation of abstract topology by 86 configuration..............................................11 87 3.4.2. On-demand generation of supplementary topology via path 88 compute request/reply......................................12 89 4. Protocol/Data Model Requirements..............................13 90 4.1. Packet Networks..........................................13 91 4.2. OTN Networks.............................................14 92 4.3. WSON Networks............................................14 93 5. Security......................................................14 94 6. Acknowledgements..............................................15 95 7. References....................................................15 96 7.1. Informative References...................................15 97 8. Contributors..................................................15 98 Authors' Addresses...............................................16 99 Appendix A:......................................................16 101 1. Introduction 103 Abstraction and Control of TE Networks (ACTN) describes a method for 104 operating a Traffic Engineered (TE) network (such as an MPLS-TE 105 network or a layer 1 transport network) to provide connectivity and 106 virtual network services for customers of the TE network. The 107 services provided can be tuned to meet the requirements (such as 108 traffic patterns, quality, and reliability) of the applications 109 hosted by the customers. More details about ACTN can be found in 110 Section 2. 112 Abstraction is defined in [RFC7926] as: 114 Abstraction is the process of applying policy to the available TE 115 information within a domain, to produce selective information that 116 represents the potential ability to connect across the domain. 117 Thus, abstraction does not necessarily offer all possible 118 connectivity options, but presents a general view of potential 119 connectivity according to the policies that determine how the 120 domain's administrator wants to allow the domain resources to be 121 used. 123 Connectivity referred to this document is TE path through a series 124 of connected domains as used in [RFC7926]. 126 As the ACTN architecture considers abstraction as one of the 127 important building blocks, this document discusses a few 128 alternatives for the methods of abstraction for both packet and 129 optical networks. This is an important consideration since the 130 choice of the abstraction method impacts protocol design and the 131 information it carries. 133 The purpose of this document is to find a common agreement on the 134 factors and methods of abstraction. These abstraction factors and 135 methods may in turn impact implementations and protocol design. 137 2. ACTN Architecture 139 This section provides a brief description of ACTN architecture. 140 [ACTN-Frame] describes the architecture model for ACTN including the 141 entities (Customer Network Controller (CNC), Multi-domain Service 142 Coordinator (MDSC), and Physical Network Controller (PNC) and their 143 interfaces. 145 Figure 1 depicts a high-level control and interface architecture for 146 ACTN and is a reproduction of Figure 5 from [ACTN-Frame]. 148 VPN customer NW Mobile Customer ISP NW service Customer 149 | | | 150 +-------+ +-------+ +-------+ 151 | CNC-A | | CNC-B | | CNC-C | 152 +-------+ +-------+ +-------+ 153 \ | / 154 ----------- |CMI I/F -------------- 155 \ | / 156 +-----------------------+ 157 | MDSC | 158 +-----------------------+ 159 / | \ 160 ------------- |MPI I/F ------------- 161 / | \ 162 +-------+ +-------+ +-------+ 163 | PNC | | PNC | | PNC | 164 +-------+ +-------+ +-------+ 165 | GMPLS / | / \ 166 | trigger / | / \ 167 -------- ---- +-----+ +-----+ \ 168 ( ) ( ) | PNC | | PCE | \ 169 - - ( Phys ) +-----+ +-----+ ----- 170 ( GMPLS ) (Netw) | / ( ) 171 ( Physical ) ---- | / ( Phys. ) 172 ( Network ) ----- ----- ( Net ) 173 - - ( ) ( ) ----- 174 ( ) ( Phys. ) ( Phys ) 175 -------- ( Net ) ( Net ) 176 ----- ----- 178 Figure 1 : ACTN Control Hierarchy 180 The MDSC oversees the specific aspects of the different domains and 181 builds a single abstracted end-to-end network topology in order to 182 coordinate end-to-end path computation and path/service 183 provisioning. In order for the MDSC to perform its coordination 184 function, it depends on the coordination with the PNCs which are the 185 domain-level controllers especially as to what level of domain 186 network resource abstraction is agreed upon between the MDSC and the 187 PNCs. 189 As discussed in [RFC7926], abstraction is tied with policy of the 190 networks. For instance, per an operational policy, the PNC would not 191 be allowed to provide any technology specific details (e.g., optical 192 parameters for WSON) in its update. In such case, the abstraction 193 level of the update will be in a generic nature. In order for the 194 MDSC to get technology specific topology information from the PNC, a 195 request/reply mechanism may be employed. 197 In some cases, abstraction is also tied with the controller's 198 capability of abstraction as abstraction involves some rules and 199 algorithms to be applied to the actual network resource information 200 (which is also known as network topology). 202 [TE-Topology] describes YANG models for TE-network abstraction. 203 [PCEP-LS] describes PCEP Link-state mechanism that also allows for 204 transport of abstract topology in the context of Hierarchical PCE. 206 3. Abstraction Factors and Methods 208 This section discusses factors that may impact the choice of 209 abstraction and presents a number of abstraction methods. 211 It is important to understand that abstraction depends on several 212 factors: 214 - The nature of underlying domain networks: Abstraction depends on 215 the nature of the underlying domain networks. For instance, packet 216 networks may have different level of abstraction requirements from 217 that of optical networks. Within optical networks, WSON may have 218 different level of abstraction requirements than the OTN networks. 220 - The capability of the PNC: Abstraction depends on the capability 221 of the PNCs. As abstraction requires hiding details of the 222 underlying resource network resource information, the PNC 223 capability to run some internal optimization algorithm impacts the 224 feasibility of abstraction. Some PNC may not have the ability to 225 abstract native topology while other PNCs may have such an ability 226 to abstract actual topology by using sophisticated algorithms. 228 - Scalability factor: Abstraction is a function of scalability. If 229 the actual network resource information is of small size, then the 230 need for abstraction would be less than the case where the native 231 network resource information is of large size. In some cases, 232 abstraction may not be needed at all. 234 - The frequency of topology updates: The proper abstraction level 235 may depend on the frequency of topology updates and vice versa. 237 - The capability/nature of the MDSC: The nature of the MDSC impacts 238 the degree/level of abstraction. If the MDSC is not capable of 239 handling optical parameters such as those specific to OTN/WSON, 240 then white topology abstraction may not work well. 242 - The confidentiality: In some cases where the PNC would like to 243 hide key internal topological data from the MDSC, the abstraction 244 method should consider this aspect. 246 - The scope of abstraction: All of the aforementioned factors are 247 equally applicable to both the MPI (MDSC-PNC Interface) and the 248 CMI (CNC-MDSC Interface). 250 With having the aforementioned factors in mind, the following 251 abstraction methods can be considered for implementations. 253 3.1. No abstraction (native/white topology) 255 This is a case where the PNC provides the actual network topology to 256 the MDSC without any hiding or filtering. In this case, the MDSC has 257 the full knowledge of the underlying network topology and as such 258 there is no need for the MDSC to send a path computation request to 259 the PNC. The computation burden will fall on the MDSC to find an 260 optimal end-to-end path and optimal per domain paths. 262 +--+ +--+ +--+ +--+ 263 +-+ +-----+ +-----+ +-----+ +-+ 264 ++-+ ++-+ +-++ +-++ 265 | | | | 266 | | | | 267 | | | | 268 | | | | 269 ++-+ ++-+ +-++ +-++ 270 +-+ +-----+ +-----+ +-----+ +-+ 271 +--+ +--+ +--+ +--+ 273 Figure 1: The native/white topology 275 3.2. One Virtual Node (black topology) 277 The entire domain network is abstracted as a single virtual node 278 (see the definition of virtual node in [RFC7926]) with the 279 access/egress links without disclosing any node internal 280 connectivity information. 282 Figure 2a depicts a native topology with the corresponding black 283 topology with one virtual node and inter-domain links. In this case, 284 the MDSC has to make path computation requests to the PNCs before it 285 can determine an end-to-end path. If there are a large number of 286 inter-connected domains, this abstraction method may impose a heavy 287 coordination load at the MDSC level in order to find an optimal end- 288 to-end path. 290 Figure 2b depicts another type of a black topology with border nodes 291 and inter-domain links. 293 The black topology would not give the MDSC any critical network 294 resource information other than the border nodes/links information 295 and as such it is likely to have a need for complementary 296 communications between the MDSC and the PNCs (e.g., Path Computation 297 Request/Reply). 299 +--+ +--+ +--+ +--+ 300 +-+ +-----+ +-----+ +-----+ +-+ 301 ++-+ ++-+ +-++ +-++ 302 | | | | 303 | | | | 304 | | | | 305 | | | | 306 ++-+ ++-+ +-++ +-++ 307 +-+ +-----+ +-----+ +-----+ +-+ 308 +--+ +--+ +--+ +--+ 310 +--------+ 311 +--+ +--+ 312 | | 313 | | 314 | | 315 | | 316 | | 317 | | 318 +--+ +--+ 319 +--------+ 321 Figure 2a: The native topology and the corresponding black topology 322 with one virtual node and inter-domain links 324 ----- 325 ( ) 326 ( ) 327 +--+ +--+ 328 +-+ | | +-+ 329 +--+ +--+ 330 ( ) 331 ( ) 332 ( ) 333 +--+ +--+ 334 +-+ | | +-+ 335 +--+ +--+ 336 ( ) 337 ( ) 338 ----- 340 Figure 2b: A black topology with border nodes and inter-domain links 342 3.3. Abstraction of TE tunnels for all pairs of border nodes (grey 343 topology) 345 This abstraction level, referred to a grey topology in [ACTN-frame] 346 is between black topology and white topology from a granularity 347 point of view. As shown in Figures 3a and 3b, we may further 348 differentiate from a perspective of how to abstract internal TE 349 resources between the pairs of border nodes: 351 . Grey topology type A: border nodes with a TE links between them 352 in a full mesh fashion (See Figure 3a) 353 . Grey topology type B: border nodes with some internal 354 abstracted nodes and abstracted links (See Figure 3b) 356 +--+ +--+ +--+ +--+ 357 +-+ +-----+ +-----+ +-----+ +-+ 358 ++-+ ++-+ +-++ +-++ 359 | | | | 360 | | | | 361 | | | | 362 | | | | 363 ++-+ ++-+ +-++ +-++ 364 +-+ +-----+ +-----+ +-----+ +-+ 365 +--+ +--+ +--+ +--+ 367 +--+ +--+ 368 +-+ +----+ +-+ 369 ++-+ +-++ 370 | \ / | 371 | \/ | 372 | /\ | 373 | / \ | 374 ++-+ +-++ 375 +-+ +----+ +-+ 376 +--+ +--+ 378 Figure 3a: The native topology and the corresponding grey topology 379 type A with TE links between border nodes 381 +--+ +--+ +--+ 382 +-+ +-----+ +-----+ +-+ 383 ++-+ ++-+ +-++ 384 | | 385 | | 386 | | 387 | | 388 ++-+ ++-+ +-++ 389 +-+ +-----+ +-----+ +-+ 390 +--+ +--+ +--+ 392 Figure 3b: The grey topology type B with abstract nodes/links 393 between border nodes 395 3.3.1. Grey topology type A: border nodes with a TE links between them 396 in a full mesh fashion 398 For each pair of ingress and egress nodes (i.e., border nodes 399 to/from the domain), TE link metric is provided with TE attributes 400 such as max bandwidth available, link delay, etc. This abstraction 401 depends on the underlying TE networks. 403 Note that this topology is similar to the connectivity matrix 404 defined in [TE-Topology]. The only thing might be different is some 405 additional information about the end points of the links of the 406 border nodes if they cannot be included in the connectivity matrix's 407 termination points. 409 - For packet networks, abstraction may include max bandwidth 410 available, delay, etc. 412 - For OTN networks, max bandwidth available may be per ODU 0/1/2/3 413 switching level or aggregated across all ODU switching levels 414 (i.e., ODUj/k).Clearly, there is a trade-off between these two 415 abstraction methods. Some OTN switches can switch any level of 416 ODUs and in such case there is no need for ODU level abstraction. 418 - For WSON networks, max bandwidth available may be per 419 lambda/frequency level (OCh) or aggregated across all 420 lambda/frequency level. Per OCh level abstraction gives more 421 detailed data to the MDSC at the expense of more information 422 processing. Either OCh-level or aggregated level abstraction 423 should factor in the RWA constraint (i.e., wavelength continuity) 424 at the PNC level. This means the PNC should have this capability 425 and advertise it as such. See the Appendix for this abstraction 426 method. 428 3.3.2. Grey topology Type B 430 The grey abstraction type B would allow the MDSC to have more 431 information about the internals of the domain networks by the PNCs 432 so that the MDSC can flexibly determine optimal paths. The MDSC may 433 configure some of the internal virtual nodes (e.g., cross-connect) 434 to redirect its traffic as it sees changes from the domain networks. 436 3.4. How to build grey topology 438 This section discusses two different methods of building a grey 439 topology: 441 . Automatic generation of abstract topology by configuration 442 (Section 3.4.1) 443 . On-demand generation of supplementary topology via path 444 computation request/reply (Section 3.4.2) 446 3.4.1. Automatic generation of abstract topology by configuration 448 The "Automatic generation" method is based on the 449 abstraction/summarization of the whole domain by the PNC and its 450 advertisement on MPI interface once the abstraction level is 451 configured. The level of abstraction advertisement can be decided 452 based on some PNC configuration parameters (e.g. provide the 453 potential connectivity between any PE and any ASBR in an MPLS-TE 454 network as described in section 3.3.1) 456 Note that the configuration parameters for this potential topology 457 can include available B/W, latency, or any combination of defined 458 parameters. How to generate such tunnel information is beyond the 459 scope of this document. Appendix A provides one example of this 460 method for the WSON case. 462 Such potential topology needs to be periodically or 463 incrementally/asynchronously updated every time that a failure, a 464 recovery or the setup of new VNs causes a change in the 465 characteristics of the advertised grey topology (e.g. in our 466 previous case if due to changes in the network is it now possible to 467 provide connectivity between a given PE and a given ASBR with a 468 higher delay in the update). 470 3.4.2. On-demand generation of supplementary topology via path compute 471 request/reply 473 The "on-demand generation" of supplementary topology is to be 474 distinguished from automatic generation of abstract topology. While 475 abstract topology is generated and updated automatically by 476 configuration as explained in Section 3.4.1., additional 477 supplementary topology may be obtained by the MDSC via path compute 478 request/reply mechanism. Starting with a black topology 479 advertisement from the PNCs, the MDSC may need additional 480 information beyond the level of black topology from the PNCs. It is 481 assumed that the black topology advertisement from PNCs would give 482 the MDSC each domain's the border node/link information as described 483 in Figure 2. Under this scenario, when the MDSC needs to allocate a 484 new VN, the MDSC can issue a number of Path Computation requests as 485 described in [ACTN-YANG] to different PNCs with constraints matching 486 the VN request. 488 An example is provided in Figure 4, where the MDSC is requesting to 489 setup a P2P VN between AP1 and AP2. The MDSC can use two different 490 inter-domain links to get from Domain X to Domain Y, namely the one 491 between ASBRX.1 and ASBRY.1 and the one between ASBRX.2 and ASBRY.2, 492 but in order to choose the best end to end path it needs to know 493 what domain X and Y can offer in term of connectivity and 494 constraints between the PE nodes and the ASBR nodes. 496 ------- ------- 497 ( ) ( ) 498 - ASBRX.1------- ASBRY.1 - 499 (+---+ ) ( +---+) 500 -+---( |PE1| Dom.X ) ( Dom.Y |PE2| )---+- 501 | (+---+ ) ( +---+) | 502 AP1 - ASBRX.2------- ASBRY.2 - AP2 503 ( ) ( ) 504 ------- ------- 506 Figure 4: A multi-domain networks example 508 A path computation request will be issued to PNC.X asking for 509 potential connectivity between PE1 and ASBRX.1 and between PE1 and 510 ASBRX.2 with related objective functions and TE metric constraints. 511 A similar request will be issued to PNC.Y and the results merged 512 together at the MDSC to be able to compute the optimal end-to-end 513 path including the inter domain links. 515 The info related to the potential connectivity may be cached by the 516 MDSC for subsequent path computation processes or discarded, but in 517 this case the PNCs are not requested to keep the grey topology 518 updated. 520 4. Protocol/Data Model Requirements 522 This section provides a set of requirements that may impact the way 523 protocol/data model is designed and the information elements thereof 524 which are carried in the protocol/data model. 526 It is expected that the abstraction level be negotiated between the 527 CNC and the MDSC (i.e., the CMI) depending on the capability of the 528 CNC. This negotiated level of abstraction on the CMI may also impact 529 the way the MDSC and the PNCs configure and encode the abstracted 530 topology. For example, if the CNC is capable of sophisticated 531 technology specific operation, then this would impact the level of 532 abstraction at the MDSC with the PNCs. On the other hand, if the CNC 533 asks for a generic topology abstraction, then the level of 534 abstraction at the MDSC with the PNCs can be less technology 535 specific than the former case. 537 The subsequent sections provide a list of possible abstraction 538 levels for various technology domain networks. 540 4.1. Packet Networks 542 - For grey abstraction, the type of abstraction and its parameters 543 MUST be defined and configured/negotiated. 544 o Abstraction Level 1: TE-tunnel abstraction for all (S-D) 545 border pairs with: 546 . Maximum B/W available per Priority Level 547 . Minimum Latency 549 o Other Level (TBD) 551 4.2. OTN Networks 553 - For grey abstraction, the type of abstraction and its parameters 554 MUST be defined and configured/negotiated. 556 o Abstraction Level 1: Per ODU Switching level (i.e., ODU type 557 and number) TE-tunnel abstraction for all (S-D) border pairs 558 with: 559 . Maximum B/W available per Priority Level 560 . Minimum Latency 562 o Abstraction Level 2: Aggregated TE-tunnel abstraction for all 563 (S-D) border pairs with: 564 . Maximum B/W available per Priority Level 565 . Minimum Latency 567 o Other Level (TBD) 569 4.3. WSON Networks 571 - For grey abstraction, the type of abstraction MUST and its 572 parameters be defined and configured/negotiated. 574 o Abstraction Level 1: Per Lambda/Frequency level TE-tunnel 575 abstraction for all (S-D) border pairs with: 576 . Maximum B/W available per Priority Level 577 . Minimum Latency 579 o Abstraction Level 2: Aggregated TE-tunnel abstraction for all 580 (S-D) border pairs with: 581 . Maximum B/W available per Priority Level 582 . Minimum Latency 584 o Other Level (TBD) 586 Note that Appendix A provides how to compute WSON grey topology 587 Abstraction Level 1 and Level 2. These examples illustrate that the 588 encoding of an abstraction topology can be impacted by the 589 configured/negotiated abstraction level in the ACTN interfaces. 591 5. Acknowledgements 593 We thank Name for providing useful comments and suggestions for this 594 draft. 596 6. References 598 6.1. Informative References 600 [RFC7926] A. Farrel, Ed., "Problem Statement and Architecture for 601 Information Exchange between Interconnected Traffic- 602 Engineered Networks", RFC 7926, July 2016. 604 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 605 Control of Traffic Engineered Networks", draft-ietf-teas- 606 actn-framework, work in progress. 608 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 609 draft-ietf-teas-yang-te-topo, work in progress. 611 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli, "PCEP Extension for 612 Distribution of Link-State and TE Information," draft- 613 dhodylee-pce-pcep-ls, work in progress. 615 [RFC7926] A. Farrel, et. al., "Problem Statement and Architecture 616 for Information Exchange Between Interconnected Traffic 617 Engineered Networks", RFC 7926, July 2016. 619 [ACTN-YANG] X. Zhang, et. Al., "Applicability of YANG models for 620 Abstraction and Control of Traffic Engineered Networks", 621 draft-zhang-teas-actn-yang, work in progress 623 7. Contributors 625 Contributor's Addresses 627 Sergio Belotti 628 Nokia 630 Email: sergio.belotti@nokia.com 632 Xian Zhang 633 Huawei 634 Email: zhang.xian@huawei.com 636 Authors' Addresses 638 Young Lee 639 Huawei Technologies 640 5340 Legacy Drive 641 Plano, TX 75023, USA 642 Phone: (469)277-5838 644 Email: leeyoung@huawei.com 646 Dhruv Dhody 647 Huawei Technologies 649 Email: dhruv.ietf@gmail.com 651 Daniele Ceccarelli 652 Ericsson 653 Torshamnsgatan,48 654 Stockholm, Sweden 656 Email: daniele.ceccarelli@ericsson.com 658 Oscar Gonzalez de Dios 659 Telefonica 661 Email: oscar.gonzalezdedios@telefonica.com 663 Appendix A: 665 This section provides how WSON grey topology abstraction levels 1 666 and 2 can be computed at a PNC. These examples illustrate that the 667 encoding of an abstraction topology can be impacted by the 668 configured/negotiated abstraction level at the MPI. 670 Abstraction Level 1: Per Lambda/Frequency level TE-tunnel 671 abstraction for all (S-D) border pairs: 673 For each (S-D) border node pair, 675 1) The concept of a lambda plane: A lambda plane is a confined 676 optical topology with respect to a given lambda value. If an OMS 677 link has the wavelength of the given lambda available, it is 678 included, otherwise excluded. 680 2) Calculate the maximal flow between S and D in every lambda plane. 681 Max flow computation is restricted to each lambda plane is for OCh 682 wavelength continuity. 684 3) Convert each feasible lambda plane with OCh wavelength continuity 685 to B/W equivalent encoding; Send this per lambda level encoding 686 for (S-D) to the MDSC; 688 Abstraction Level 2: Aggregated TE-tunnel abstraction for WSON for 689 all (S-D) border pairs 691 For each (S-D) border node pair, 693 1) The concept of a lambda plane: A lambda plane is a confined 694 optical topology with respect to a given lambda value. If an OMS 695 link has the wavelength of the given lambda available, it is 696 included, otherwise excluded. 698 2) Calculate the maximal flow between S and D in every lambda plane. 699 Max flow computation is restricted to each lambda plane is for OCh 700 wavelength continuity. 702 3) Add up the max flow values across all lambda planes. This is the 703 maximal number of OCh paths that can be setup between S and D at 704 the same time. 706 4) Convert the max number of OCh paths to B/W equivalent encoding; 707 Send this encoding as max B/W for (S-D) to the MDSC;