idnits 2.17.1 draft-fu-pce-ip-link-transport-service-mapping-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 abstract seems to contain references ([I-D.ietf-teas-actn-framework], [ACTN-FWK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 28, 2016) is 2736 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACTN-FWK' is mentioned on line 96, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-actn-framework (ref. 'I-D.ietf-teas-actn-framework') Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group PC. Fu 3 Internet-Draft JZ. FU 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 1, 2017 AJ. Wang 6 RQ. Jing 7 China Telecom 8 October 28, 2016 10 A YANG Model for IP Link and Transport Service Mapping 11 draft-fu-pce-ip-link-transport-service-mapping-01 13 Abstract 15 IP+optical is a cross-layer collaboration technology for unified 16 management of IP and optical networks. Based on framework proposed 17 in [ACTN-FWK][I-D.ietf-teas-actn-framework], this draft presents 18 specific information about the IP+optical solution: hierarchical 19 controllers + disabled GMPLS UNIs. This solution does not involve 20 UNI tunnel objects. Therefore, the mapping between IP links and 21 transport services is key point of this solution. This draft 22 provides a YANG model for the RESTCONF/NETCONF protocol. This YANG 23 module defines NBIs for the IP+optical super controller. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 May 1, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. IP+optical solution . . . . . . . . . . . . . . . . . . . 2 67 1.2. Unified cross-layer algorithm . . . . . . . . . . . . . . 6 68 1.3. IP+VNT algorithm . . . . . . . . . . . . . . . . . . . . 7 69 1.4. IP Link and Transport Service Mapping . . . . . . . . . . 8 70 2. IP Link and Transport Service Mapping Model - YANG Tree . . . 10 71 3. IP Link and Transport Service Mapping Model - YANG Code . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 1.1. IP+optical solution 82 IP+optical is a cross-layer collaboration technology for unified 83 management of IP and optical networks. IP+optical adopts the C/S 84 architecture, where the IP network is the client-layer network and 85 the optical network is the server-layer network. The mapping between 86 IP-layer IP links and transport services is the key ability of an 87 IP+optical network. Through the mapping, the services of IP layers 88 and those of transport layers can be associated to implement use 89 cases of IP+optical scenarios. 91 IP+optical use cases include multi-layer topology visualization, 92 automated network deployment, multi-layer automated service 93 deployment, multi-layer protection and restoration, multi-layer 94 optimization, and multi-layer maintenance window. 96 Based on framework proposed in [ACTN- 97 FWK][I-D.ietf-teas-actn-framework], this draft presents specific 98 information about the IP+optical solution: hierarchical controllers + 99 disabled GMPLS UNIs. This solution does not involve UNI tunnel 100 objects. Therefore, the mapping between IP links and transport 101 services is key point of this solution. 103 The IP+optical solution implements cross-layer service provisioning 104 through cross-layer link and association of multi-layer topologies. 105 After service provisioning, this solution is required to present 106 multi-layer service views for users to learn service status. In 107 addition, the association management function needs to be available 108 during fault demarcation and locating and cross-layer protection and 109 restoration. To meet these demands, a service mapping needs to be 110 maintained between IP-layer IP links and optical-layer transport 111 services. 113 +----------+ 114 |IP+Optical| 115 | Super | 116 |Controller| 117 +-/------\-+ 118 / \ 119 +---------/--+ +--\--------+ 120 | IP | | Optical | 121 | Controller | |Controller | 122 +----+-------+ +---+-------+ 123 | | 124 +----+----------------+-------------+ 125 /R | R |R R / 126 / R R | / 127 IP / R . R . | R R / 128 Layer +-------------------------+---------+ 129 . . . . | . . 130 . . . . | . . 131 . . . . | . . 132 . . . . | . . 133 . . . . | . . 134 +---------------------+-------------+ 135 / O . O . O . | O O / 136 / O . O O / 137 Optical / O O O O O / 138 Layer +-----------------------------------+ 139 Figure 1: IP+optical solution 141 In real-world situations, IP+optical super controllers can be 142 separately deployed or combined with other controllers. For example, 143 in IP+optical single-domain scenarios, an IP+optical super controller 144 can be combined with an IP domain controller. In IP multi-domain and 145 optical multi-domain scenarios, you can deploy one separate IP super 146 controller and one separate optical super controller. The two super 147 controllers communicate through RESTConf interfaces and use the 148 IP+VNT algorithm to complete E2E cross-layer path calculation. In 149 such multi-domain scenarios, you can also deploy only one IP+optical 150 super controller and use a unified cross-layer algorithm in the 151 controller to complete E2E cross-layer path calculation. 153 +----------+ 154 |IP+Optical| 155 | Super | 156 |Controller| 157 +--/-----\-+ 158 / \ 159 / +--\--------+ 160 / | Optical | 161 / |Controller | 162 / +---+-------+ 163 / | 164 +-----/---------------+-------------+ 165 /R / R |R R / 166 / R R | / 167 IP / R . R . | R R / 168 Layer +-------------------------+---------+ 169 . . . . | . . 170 . . . . | . . 171 . . . . | . . 172 . . . . | . . 173 . . . . | . . 174 +---------------------+-------------+ 175 / O . O . O . | O O / 176 / O . O O / 177 Optical / O O O O O / 178 Layer +-----------------------------------+ 179 Figure 2: IP+optical single-domain scenarios 180 +--------------------+ 181 | IP+Optical | 182 | Super | 183 | Controller | 184 +/--------+---------\+ 185 / | \ 186 +-----------/+ +-----+-----+ +-\---------+ 187 | IP | | Optical | | Optical | 188 | Controller | |Controller | |Controller | 189 +--------+---+ +-+---------+ +-------+---+ 190 | | | 191 +-+---------+---------------------+-------+ 192 /R | R | R R | R / 193 / . | . | R . R . | / 194 IP / . R . R | . . R . . R | R / 195 Layer +---.--.-.------+----.----------.-----+---+ 196 . . . . | . . . . . . | . 197 . . . . | . . . . . . | . 198 . . . . | . . . . . . | . 199 . . . . | . . . . . . | . 200 . . . . | . . . . . . | . 201 +--.-.------+----.----+ +---.-----+-------+ 202 /O . O O | . O . / /. . O | O / 203 / O O/ / O O | / 204 Optical / O O / / O O / 205 Layer +---------------------+ +-----------------+ 206 Figure 3: IP domain and optical multi-domain scenarios-1 207 +------------+ +--------------------+ 208 | IP | | IP+Optical | 209 | Controller +------+ Controller | 210 +-------+----+ +---+-------------+--+ 211 | | | 212 | | | 213 | +--------+--+ +-----+-----+ 214 | | Optical | | Optical | 215 | |Controller | |Controller | 216 | +--+--------+ +-------+---+ 217 | | | 218 +-+---------+---------------------+-------+ 219 /R | R | R R | R / 220 / . | . | R . R . | / 221 IP / . R . R | . . R . . R | R / 222 Layer +---.--.-.------+----.----------.-----+---+ 223 . . . . | . . . . . . | . 224 . . . . | . . . . . . | . 225 . . . . | . . . . . . | . 226 . . . . | . . . . . . | . 227 . . . . | . . . . . . | . 228 +--.-.------+----.----+ +---.-----+-------+ 229 /O . O O | . O . / /. . O | O / 230 / O O/ / O O | / 231 Optical / O O / / O O / 232 Layer +---------------------+ +-----------------+ 233 Figure 4: IP domain and optical multi-domain scenarios-2 235 1.2. Unified cross-layer algorithm 237 In this model, inter-layer path computation is performed by a single 238 PCE of a Unified controller that has topology visibility into all 239 layers. Such a PCE is called a multi-layer PCE. In Figure 2, the 240 network is comprised of two layers. NEs H1, H2,H3, and H4 belong to 241 the higher layer, and NEs H2, H3, L1, and L2 belong to the lower 242 layer. The PCE is a multi-layer PCE that has visibility into both 243 layers. It can perform end-to-end path computation across layers 244 (single PCE path computation). For instance, it can compute an 245 optimal path H1-H2-L1-L2-H3-H4. Of course, more complex cooperation 246 may be required if an optimal end-to-end path is desired. 248 Controller 249 +-----------------------------------+ 250 | +--------------+ | 251 | |Multilayer-PCE| | 252 | +--------------+ | 253 | +--------++-----------++--------+ | 254 | |IP ||Cross-Layer||Optical | | 255 | |Topology||Topology ||Topology| | 256 | +--------++-----------++--------+ | 257 +----------------+------------------+ 258 | 259 | 260 | 261 ----- ----- | ----- ----- 262 | R |--| R |........|.......| R |--| R | 263 | H1 | | H2 | | H3 | | H4 | 264 ----- -----\ /----- ----- 265 \----- -----/ 266 | O |--| O | 267 | L1 | | L2 | 268 ----- ----- 269 Figure 5: Unified cross-layer algorithm 271 1.3. IP+VNT algorithm 273 In this model, there is at least one PCE of controller per layer, and 274 each PCE of controller has topology visibility restricted to its own 275 layer. Some providers may want to keep the layer boundaries due to 276 factors such as organizational and/or service management issues. The 277 choice for multiple PCE computation instead of single PCE computation 278 may also be driven by scalability considerations, as in this mode a 279 PCE only needs to maintain topology information for one layer 280 (resulting in a size reduction for the Traffic Engineering Database 281 (TED)). Figure 3 shows multiple PCE inter-layer computation with 282 inter-PCE communication. There is one PCE in each layer. The PCEs 283 from each layer collaborate to compute an end-to-end path across 284 layers. An IP-PCE of IP-domain controller uses IP topology and VNT 285 topology information to perform path calculation at the higher layer. 286 If a VNT link is selected, the IP-domain controller collaborates with 287 the optical-domain controller for path calculation. The optical-PCE 288 of optical-domain controller then uses cross-layer topology and 289 optical topology information to calculate an underlying VNT path.A 290 simple example of cooperation between the PCEs could be as follows: 292 o IP controller sends a request to IP-PCE for a path H1-H4 with ip 293 topo and VNT topo. 295 o IP-PCE selects VNT link as the entry point and exit point to the 296 lower layer. 298 o IP-PCE of IP controller requests a path both ends of VNT link from 299 Optical-PCE of optical controller. 301 o Optical-PCE returns H2-L1-L2-H3 to IP-PCE. 303 o IP-PCE is now able to compute the full path (H1-H2-L1-L2-H3-H4) 305 IP Controller Optical Controller 306 +-----------------------+ +-----------------------------------+ 307 | +------+ | | +-----------+ | 308 | |IP-PCE| +------+ |Optical-PCE| | 309 | +------+ | | +-----------+ | 310 |+--------++-----------+| | +--------++-----------++--------+ | 311 ||IP ||VNT || | |VNT ||Cross-Layer||Optical | | 312 ||Topology||Topology || | |Topology||Topology ||Topology| | 313 |+--------++-----------+| | +--------++-----------++--------+ | 314 +-----------+-----------+ +----------+------------------------+ 315 | | 316 | | 317 | | 318 | | 319 | | 320 ----- ----- VNT Link | ----- ----- 321 | R |-+| R |......................|.| R |--| R | 322 | H1 | | H2 | | | H3 | | H4 | 323 ----- -----\ | /----- ----- 324 \ / 325 \ / 326 \ / 327 \ / 328 \----- -----/ 329 | O |--| O | 330 | L1 | | L2 | 331 ----- ----- 332 Figure 6: IP+VNT algorithm 334 1.4. IP Link and Transport Service Mapping 336 The mapping varies with IP link interfaces and changes with system 337 creation, dismantlement, and scheduling changes. 339 +-----+ +-----+ 340 | R | IP Link | R | 341 | H1 | | H2 | 342 | @############################@ | 343 | |\ /| | 344 +---- + \ / + ----+ 345 \ / 346 \ Transport Service / 347 \ +-----+ +-----+ / 348 \| |--| |/ 349 @**************@ 350 | O | | O | 351 | L1 | | L2 | 352 | | | | 353 +-----+ +-----+ 354 Figure 7: Physical port connection scenario 356 IP Link 357 +-----+ +-----+ 358 | R O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O R | 359 | H1 O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O H2 | 360 | O@^^^^^^^^^^^^^^^^^^^^^^^^^^^^@O | 361 | |\ /| | 362 +---- + \ / + ----+ 363 \ / 364 \ Transport Service / 365 \ +-----+ +-----+ / 366 \| |--| |/ 367 @**************@ 368 | O | | O | 369 | L1 | | L2 | 370 | | | | 371 +-----+ +-----+ 372 Figure 8: VLAN port connection scenario 373 +-----+ +-----+ 374 | R | IP Link | R | 375 | H1 @ @ H2 | 376 | E^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^E | 377 | @ \ / @ | 378 +---- +\ \ / /+ ----+ 379 \ \ / / 380 \ \ Transport Service/ / 381 \ \+-----+ +-----+/ / 382 \ @**************@ / 383 \| |/ 384 @**************@ 385 | O | | O | 386 | L1 | | L2 | 387 +-----+ +-----+ 388 Figure 9: Eth-trunk port connection scenario 390 2. IP Link and Transport Service Mapping Model - YANG Tree 392 (preamble) 394 module: ietf-mapping-ip_link-transport_service 395 +--rw mapping-ip-link-transport-service 396 +--rw mappings* [mapping-id] 397 +--rw mapping-id string 398 +--rw mapping-name? string 399 +--rw ip-links 400 | +--rw ip-link* [ip-link-name] 401 | +--rw ip-link-name string 402 | +--rw ip-link-base? enumeration 403 | +--rw source-node-id? string 404 | +--rw source-if-id? uint32 405 | +--rw sink-node-id? string 406 | +--rw sink-if-id? uint32 407 | +--rw bandwidth? decimal64 408 | +--rw delay? decimal64 409 | +--rw srlg? decimal64 410 | +--rw ip-optical? protection-type 411 +--rw transport-service 412 +--rw transport-service-id? uint32 413 +--rw bandwidth? decimal64 414 +--rw delay-limit? decimal64 415 +--rw delayvariation-limit? decimal64 416 +--rw srlg? decimal64 417 +--rw ip-optical? protection-type 418 +--rw supporting-tunnel-name? string 420 (postamble) 422 3. IP Link and Transport Service Mapping Model - YANG Code 424 (preamble) 426 module ietf-mapping-ip_link-transport_service { 427 namespace "urn:ietf:params:xml:ns:yang: 428 ietf-mapping-ip_link-transport_service"; 429 prefix "ip-trans-map"; 431 organization 432 "Huawei Technologies"; 434 contact 435 "fupengcheng@huawei.com"; 437 description 438 "The YANG module defines a mapping between ip link 439 and transport."; 441 revision 2016-10-28 { 442 description "Initial revision."; 443 } 445 /* Features */ 446 feature ip-link { 447 description "ip-link paras"; 448 } 450 feature transport { 451 description "transport paras"; 452 } 454 /* Typedefs */ 455 typedef protection-type { 456 type string; 457 description 458 "ip or optical protection type."; 459 } 461 /* Groupings */ 462 grouping ip-link-paras { 463 container ip-links { 464 list ip-link { 465 key ip-link-name; 467 leaf ip-link-name { 468 type string; 469 description 470 "name of an ip link."; 471 } 472 leaf ip-link-base { 473 type enumeration { 474 enum "physical" { 475 description 476 "physical link."; 477 } 478 enum "vlan-if" { 479 description 480 "vlan if"; 481 } 482 enum "eth-trunk" { 483 description 484 "eth-trunk"; 485 } 486 } 487 } 488 leaf source-node-id { 489 type string; 490 description 491 "source node id."; 492 } 493 leaf source-if-id { 494 type uint32; 495 description 496 "source if id."; 497 } 498 leaf sink-node-id { 499 type string; 500 description 501 "sink node id."; 502 } 503 leaf sink-if-id { 504 type uint32; 505 description 506 "sink if id."; 507 } 508 leaf bandwidth { 509 type decimal64 { 510 fraction-digits 2; 511 } 512 description 513 "bandwidth."; 514 } 515 leaf delay { 516 type decimal64 { 517 fraction-digits 2; 519 } 520 description 521 "delay."; 522 } 523 leaf srlg { 524 type decimal64 { 525 fraction-digits 2; 526 } 527 description 528 "srlg."; 529 } 530 leaf ip-optical { 531 type protection-type; 532 description 533 "IP_Optial."; 534 } 535 description 536 "List of ip links"; 537 } 538 description 539 "Container of ip links"; 540 } 541 description 542 "This grouping defines ip link parameters"; 543 } 545 grouping transport-service-paras { 546 container transport-service { 547 leaf transport-service-id { 548 type uint32; 549 description 550 "transport service id."; 552 } 553 leaf bandwidth { 554 type decimal64 { 555 fraction-digits 2; 556 } 557 description 558 "bandwidth."; 559 } 560 leaf delay-limit { 561 type decimal64 { 562 fraction-digits 2; 563 } 564 description 565 "delay limit."; 566 } 567 leaf delayvariation-limit { 568 type decimal64 { 569 fraction-digits 2; 570 } 571 description 572 "delayvariation limit."; 573 } 574 leaf srlg { 575 type decimal64 { 576 fraction-digits 2; 577 } 578 description 579 "srlg."; 580 } 581 leaf ip-optical { 582 type protection-type; 583 description 584 "IP_Optial."; 585 } 586 leaf supporting-tunnel-name { 587 type string; 588 description 589 " supporting tunnel name."; 590 } 591 } 592 description 593 "This grouping defines transport service parameters"; 594 } 596 /* Main blocks */ 597 container mapping-ip-link-transport-service { 598 list mappings { 599 key mapping-id; 601 leaf mapping-id { 602 type string; 603 description 604 "key of a mapping."; 605 } 606 leaf mapping-name { 607 type string; 608 description 609 "name of a mapping"; 610 } 612 uses ip-link-paras; 613 uses transport-service-paras; 614 } 616 } 617 } 619 (postamble) 621 4. IANA Considerations 623 This document makes no request of IANA. 625 Note to RFC Editor: this section may be removed on publication as an 626 RFC. 628 5. Security Considerations 630 6. Acknowledgements 632 7. Normative References 634 [I-D.ietf-teas-actn-framework] 635 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 636 Control of Traffic Engineered Networks", draft-ietf-teas- 637 actn-framework-01 (work in progress), October 2016. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 Authors' Addresses 646 Pengcheng FU 647 Huawei Technologies 649 Email: fupengcheng@huawei.com 651 Jianzhong FU 652 Huawei Technologies 654 Email: fujianzhong@huawei.com 656 Aijun.Wang 657 China Telecom 659 Email: wangaj@ctbri.com.cn 660 Ruiquan Jing 661 China Telecom 663 Email: jingrq@ctbri.com.cn