idnits 2.17.1 draft-li-opsawg-carrier-ip-service-model-req-arch-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Huawei 4 Intended status: Informational Q. Sun 5 Expires: September 14, 2017 China Telecom 6 Y. Zheng 7 China Unicom 8 March 13, 2017 10 Requirements and Architecture of Carrier IP Service Models 11 draft-li-opsawg-carrier-ip-service-model-req-arch-01 13 Abstract 15 Service Model is a fundamental building block for a controller's 16 North-Bound Interface (NBI). Defining a service model for different 17 multi-layered and heterogeneous networks is a complicated work and 18 may require lots of consideration since different model users may 19 have different perspective and concerns. 21 This document proposes the requirements and architecture for service 22 models to facilitate future work. This document does not attempt to 23 provide a detailed description of all the architectural components, 24 but rather it describes a set of building blocks, requirements, 25 architecture and guidelines from which models may be constructed. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 14, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Generic Scenarios Oriented . . . . . . . . . . . . . . . 6 72 4.2. Network-Functional Level Abstract . . . . . . . . . . . . 6 73 4.3. Multi-Level Openness Required . . . . . . . . . . . . . . 6 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Base Network Models . . . . . . . . . . . . . . . . . . . 7 76 5.1.1. Topology Model . . . . . . . . . . . . . . . . . . . 7 77 5.1.2. Inventory Model . . . . . . . . . . . . . . . . . . . 7 78 5.1.3. Resource Model . . . . . . . . . . . . . . . . . . . 7 79 5.2. Service Models . . . . . . . . . . . . . . . . . . . . . 7 80 5.2.1. VPN Service Models . . . . . . . . . . . . . . . . . 8 81 5.2.2. Service Flow Models . . . . . . . . . . . . . . . . . 9 82 5.2.3. Tunnel Service Models . . . . . . . . . . . . . . . . 9 83 5.2.4. IP Flow Service Models . . . . . . . . . . . . . . . 9 84 5.3. Supporting Models . . . . . . . . . . . . . . . . . . . . 9 85 5.3.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . 9 86 6. Architecture of Network Models . . . . . . . . . . . . . . . 9 87 6.1. Principles of Architecture . . . . . . . . . . . . . . . 10 88 6.1.1. Hierarchical Architecture . . . . . . . . . . . . . . 10 89 6.1.2. Extended Architecture . . . . . . . . . . . . . . . . 10 90 6.1.3. Three Containers . . . . . . . . . . . . . . . . . . 10 91 6.1.4. Multiple Choices . . . . . . . . . . . . . . . . . . 10 92 6.2. Architecture of Base Network Models . . . . . . . . . . . 11 93 6.2.1. Topology Model . . . . . . . . . . . . . . . . . . . 11 94 6.3. Inventory Model . . . . . . . . . . . . . . . . . . . . . 11 95 6.4. Resource Model . . . . . . . . . . . . . . . . . . . . . 11 96 6.5. Architecture of Service Models . . . . . . . . . . . . . 11 97 6.5.1. VPN Service Models . . . . . . . . . . . . . . . . . 11 98 6.5.2. Service Flow Models . . . . . . . . . . . . . . . . . 12 99 6.5.3. Tunnel Service Models . . . . . . . . . . . . . . . . 12 100 6.5.4. IP Flow Models . . . . . . . . . . . . . . . . . . . 13 101 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 107 11.2. Informative References . . . . . . . . . . . . . . . . . 14 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 110 1. Introduction 112 Service Model is a fundamental building block for a controller's 113 North-Bound Interface (NBI). Defining a service model for different 114 multi-layered and heterogeneous networks is a complicated work and 115 may require lots of consideration since different model users may 116 have different perspective and concerns. 118 This document proposes the requirements and architecture for service 119 models to facilitate future work. This document does not attempt to 120 provide a detailed description of all the architectural components, 121 but rather it describes a set of building blocks, requirements, 122 architecture and guidelines from which models may be constructed. 124 2. Terminology 126 o NBI: North-Bound Interface 128 o SBI: South-Bound Interface 130 o SDN: Software-Defined Network 132 o RAN: Radio Access Network 134 o OAM: Operation, Administration and Maintenance 136 3. Scope 138 The L3VPN service model [I-D.ietf-l3sm-l3vpn-service-model] is 139 defined to provides an abstracted view of the Layer 3 IPVPN service 140 configuration components. A typical usage is to use this model as an 141 input for an orchestration layer who will be responsible to translate 142 it to orchestrated configuration of network elements who will be part 143 of the service. As the development of SDN controller, there will be 144 functionalities division between the controller and the orchestrator. 145 The orchestrator is always responsible for the service orchestration 146 between network service and related applications while controller is 147 dedicated to the network-level services. 149 Since an orchestrator will face end users directly, the corresponding 150 input for its models will absolutely be expressed into a user- 151 friendly manner. Taking the Network L3VPN Service Model as an 152 example, the location of PEs can be expressed by using geographical 153 information such as street or latitude/longitude, etc. for an 154 orchestrator model. But the input for a controller's model has to be 155 certain identification that can be directly used by the controller 156 such as network element ID or IP address. Though there maybe some 157 subtle difference between the service models of controller and 158 orchestrator, as the abstracted view of network service, there exists 159 much similarity between these network service models. This document 160 primarily focuses on service models for a controller's NBI instead of 161 the counterpart of an orchestrator which are shown in the Figure 1. 163 Orchestrator | 164 -Oriented | 165 Service | 166 Model | 167 | 168 +------------------+ 169 | Orchestrator | 170 +------------------+ 171 | 172 Controller | 173 -Oriented | 174 Service | 175 Model | 176 | 177 +----------------+ 178 | Controller | 179 +----------------+ 180 | | 181 | Netconf/CLI ... 182 | | 183 +------------------------------------------------+ 184 Network 186 +++++++ 187 + AAA + 188 +++++++ 190 +++++++ Bearer ++++++++ ++++++++ +++++++ 191 + CEA + ------- + PE A + + PE B + ----- + CEB + 192 +++++++ Cnct ++++++++ ++++++++ +++++++ 194 Site A Site B 196 Figure 1: Different Level's Network Service Model 198 Currently service models such as vDC, Service Function Chain (SFC), 199 etc. are developed for the data center network. This document 200 focuses on the services of traditional carrier IP networks 201 exclusively. Carrier IP networks are also facing the same challenges 202 as those of data center networks such as rapid deployment and 203 maintenance of network services for which network service model can 204 be introduced to try to simplify the service provision and 205 maintenance. For example, when handling an IP-RAN network with 206 thousands of nodes and complex business on, it is really eager to 207 have some methods to help to alleviate this pain point. 209 4. Considerations 211 4.1. Generic Scenarios Oriented 213 Instead of addressing all problem spaces and fixing every issue from 214 all kinds of scenarios, a network service model is RECOMMENDED to 215 primarily focus on those generic ones. Introducing too many details 216 that are scenario specific can cause lots of customized models which 217 will minimize the difference between NBI and SBI gradually and 218 jeopardize the value of NBI in the long run. 220 4.2. Network-Functional Level Abstract 222 There are two types of abstraction of network service models: Intent 223 Level and Network-functional Level. Since the network architecture 224 is more complicated and there will be hard to introduce many plug- 225 and-play features, it is difficult for a carrier IP network to 226 achieve high abstraction to the intent level. As a result, it is 227 mandatory to understand some details of the whole network (such as 228 service specific topology) when service models are introduced. Based 229 on this consideration, this document will primarily focus on 230 definition of service models of network-functional level. 232 4.3. Multi-Level Openness Required 234 It is obvious that a service model can have lots of users which will 235 certainly have different backgrounds and perspective. It is 236 important that a service model can satisfy all these requirements 237 through different levels of openness and abstraction while still keep 238 itself intact. 240 In simple terms, we can divide the users of a service model into two 241 groups: business users and administrators. 243 1. Business users. The primary concern of this kind of users is to 244 deploy fast and operate successfully. They care about details 245 only when they have to. Unless they are professional technical 246 personnel or required themselves, it is better for a service 247 model to try best to avoid unnecessary details. 249 2. Administrators. For administrators, they care about not only the 250 network service provision based on the possible network service 251 models, but also the following aspects related with network 252 service: 254 A. Pre-configuration. In order to accomplish the mapping from 255 NBI models to SBI models, it is necessary to pre-configure 256 parts of business related items and resources. This is also 257 helpful to lower the threshold for business users. 259 B. Operation and maintenance. When talking about operation and 260 maintenance work on a daily basis, it is reasonable to access 261 certain exact information, and even some non-user-friendly 262 fields when shooting troubles. It is important that a 263 service model can support such level of openness for 264 accessing. 266 5. Requirements 268 5.1. Base Network Models 270 The base network models are to provide the abstraction of underlay 271 network to facilitate the definition of network service models. 273 5.1.1. Topology Model 275 Topology models are the base network models to provide the abstracted 276 view of topologies of the physical network. Based on the 277 requirements of different network service models, there should be 278 models on generic network topology, L3 network topology, L2 network 279 topology, MPLS-TE topology and IP-TE topology. 281 5.1.2. Inventory Model 283 Network inventory is one important base network models which can 284 provide the abstracted view of different network devices. 286 5.1.3. Resource Model 288 Resource model defines the configuration for pools of service 289 resources and operational state about the used and the available 290 resources. The model focus on the service resouces such as Route 291 Distinguisher, Route Target, Vxlan ID etc. 293 5.2. Service Models 295 Nowadays huge IP related technologies such as IGP, BGP, MPLS, VPN, 296 OAM, etc. have been used in carrier IP networks which propose the 297 great challenges for network service provision and maintenance. When 298 considering the procedure of deploying these services in a high 299 abstraction level, it can be simplified as a work of "leading traffic 300 flow into pipes". These "pipes" can be recognized as tunnels or IP 301 flows involving multiple routers in the network, while "traffic flow" 302 can be recognized according to different granularity. In a manner of 303 speaking, VPN can be seen as a kind of coarse grain flow while a 304 finer grain flow can be defined using the "5-tuple" of IP header. 306 Even for the "pipes" base on tunnels, there can be many types of 307 tunnels implemented on the device. Through a controller's NBI, an 308 application can trigger a controller to create the tunnel it needs 309 without understanding the detail. Or the business can trigger the 310 traffic optimization of network-level MPLS-TE tunnels for service 311 bearing. In these scenarios, the "pipe" itself is also a kind of 312 network-level service. So here we get several basic service models 313 for carrier IP network: 315 Pipes: 317 o Network Tunnel Service Model 319 o Network IP Flow Service Model 321 Flows: 323 o Network VPN Service Model 325 o Network Service Flow Model 327 As stated above, because of different requirements and technical 328 background, the input of a specific service model shows the wide 329 diversity. For instance, users of VPN Service do not have to care 330 about it is L3VPN, L2VPN or EVPN that is actually being used. And a 331 common end identification only needs to be designated instead of 332 concrete IP or MAC addresses. These concrete identifications can be 333 allocated by a controller automatically. On the other hand, some 334 users prefer to designate the exact VPN such as L3VPN in the case IP 335 address for the identification of ACs should be designated instead of 336 allocated by the controller. Owing to the wide diversity of 337 requirements on specific network service models, there should be 338 multiple levels of such network service models to accommodate these 339 requirements. 341 5.2.1. VPN Service Models 343 The draft "Considerations on Layered Network VPN Service Models" in 344 process describe in details the requirements of VPN service models 345 including: 347 1. Network VPN Service Model 348 2. Network L3VPN Service Model 349 3. Network L2VPN Service Model 350 4. P2P Network L2VPN Service Model 351 5. MP2MP Network L2VPN Service Model 352 6. Network EVPN Service Model 354 5.2.2. Service Flow Models 356 Service flow service models is to provide the abstracted view of 357 network-level's steering the traffic identified with the thinner 358 granularity than VPN such as "5 tuple" of IP header to the possible 359 "pipes". The details will be defined in the future accompanying 360 draft. 362 5.2.3. Tunnel Service Models 364 The draft "Considerations on Layered Network Tunnel Service Models" 365 in process describe in details the requirements of Tunnel service 366 models including: 368 1. Network Tunnel Service Model 369 2. Network MPLS TE Tunnel Service Model 370 3. Network IP Tunnel Service Model 372 5.2.4. IP Flow Service Models 374 IP Flow service models is to provide the abstracted view of network 375 service based on IP paths spanning multiple network elements. The 376 details will be defined in the future accompanying draft. 378 5.3. Supporting Models 380 Supporting models is used to help define the possible service in a 381 specific network service model. Templates or profiles of specific 382 service are important supporting models which can be reused in the 383 multiple instances of a specific network service models. 385 5.3.1. QoS Profile 387 QoS Profile model can help define a set of QoS parameter which can be 388 applied to the network VPN service models. 390 6. Architecture of Network Models 391 6.1. Principles of Architecture 393 6.1.1. Hierarchical Architecture 395 The architecture of network service models should be defined into a 396 multi-level hierarchy in the object-oriented paradigm. Different 397 concern and perspective can be fulfilled through models in different 398 levels in the hierarchy. 400 6.1.2. Extended Architecture 402 In order to adapt changes of service models, even for the network 403 service model in the specific level of the hierarchy, there should be 404 base model and extended model. The parameters in the base model 405 should be common to most users while the extended model can define 406 parameters requireed by limited users. If the parameters in the 407 extended models can be well accepted, they can be moved to the 408 corresponding base model. 410 6.1.3. Three Containers 412 For specific network service models there should be three primary 413 containers: 415 -- Service Configuration Data: The service configuration data is used 416 for the network service provision. 418 -- Service Operational Data: The service operational data should be 419 defined for operation and maintenance of the network service. There 420 should be different levels of operational data used for business 421 users and administrators. 423 -- Pre-configuration. The pre-configuration can be used to define 424 the possible policy to help convert the network service model to the 425 device-level configuration or the service resources used for the 426 conversion. 428 6.1.4. Multiple Choices 430 There should be multiple choices for defining parameters for specific 431 services in the network service models. For simple use cases, only 432 few parameters need to be specified for defining a service (For 433 example, bandwidth is specified for QoS process). But some 434 professional users may wish to define a serial of parameters for the 435 same service which can be achieved through a parameter template (For 436 example, QoS profile should be introduced to define the QoS process). 437 It is REQUIRED that options should be available for a service model 438 to satisfy different needs. 440 6.2. Architecture of Base Network Models 442 6.2.1. Topology Model 444 Based on the topology models which are defining, the hierarchy of 445 topology models are depicted in the following figure: 447 +--------------+ 448 | | 449 | Network | 450 | Topology | 451 +-------+------+ 452 | 453 +------------------+--------+---------+-----------------+ 454 | | | | 455 V V V V 456 +--------------+ +--------------+ +--------------+ +--------------+ 457 | | | | | | | | 458 | L3 Topology | | L2 Topology | | MPLS-TE | | IP-TE | 459 | | | | | Topology | | Topology | 460 +--------------+ +--------------+ +--------------+ +--------------+ 461 Figure 2: Architecture of Topology Models 463 6.3. Inventory Model 465 It will be defined in the future version of the draft. 467 6.4. Resource Model 469 It will be defined in the future version of the draft. 471 6.5. Architecture of Service Models 473 6.5.1. VPN Service Models 475 Based on the draft "Considerations on Layered Network VPN Service 476 Models" in process, the hierarchy of VPN service models are depicted 477 in the following figure (network EVPN model will be defined in the 478 future version of the draft): 480 +--------------+ 481 | | 482 | Network VPN | 483 | | 484 +-------+------+ 485 | 486 +--------------+--------------+ 487 | | 488 V V 489 +---------------+ +---------------+ 490 | | | | 491 | Network L3VPN | | Network L2VPN | 492 | | | | 493 +---------------+ +---------------+ 494 | 495 +-------------------+ 496 | | 497 V V 498 +---------------+ +---------------+ 499 | P2P | | MP2MP | 500 | Network L2VPN | | Network L2VPN | 501 | | | | 502 +---------------+ +---------------+ 503 Figure 3: Architecture of VPN Service Model 505 6.5.2. Service Flow Models 507 The architecture of Service Flow models will be defined in the future 508 version of the draft. Service flow service models is to provide the 509 abstract view of network-level's steering the traffic identified with 510 the thinner granularity than VPN such as "5 tuple" of IP header to 511 the possible "pipes". 513 6.5.3. Tunnel Service Models 515 Tunnel service can be divieded into TE tunnel service and IP tunnel 516 service. The hierarchy of TE Tunnel service models are depicted in 517 the following figure: 519 +--------------+ 520 | | 521 | Network | 522 | UTETunnel | 523 +-------+------+ 524 | 525 +--------------+--------------+ 526 | | 527 V V 528 +--------------+ +--------------+ 529 | Network | | Network | 530 | TE Tunnel | | UNI Tunnel | 531 | | | | 532 +--------------+ +--------------+ 533 | 534 +-------------------+ 535 | | 536 V V 537 +---------------+ +---------------+ 538 | RSVP TE | | SR TE | 539 | Tunnel | | Tunnel | 540 | | | | 541 +---------------+ +---------------+ 542 Figure 4: Architecture of Tunnel Service Model 544 6.5.4. IP Flow Models 546 The architecture of IP Flow models will be defined in the future 547 version of the draft. 549 7. Contributors 551 The following people have substantially contributed to the 552 requirement and architecture design of carrier IP service models: 554 Xiaofeng Ji 555 Huawei 556 Email: jixiaofeng@huawei.com 558 Yuanbin Yin 559 Huawei 560 Email: yinyuanbin@huawei.com 562 Xianping Zhang 563 Huawei 564 Email: zhangxianping@huawei.com 566 8. IANA Considerations 568 This document makes no request for IANA. 570 9. Security Considerations 572 This document does not introduce new security threat. 574 10. Acknowledgements 576 During the course of defining requirement and architecture of carrier 577 IP network services, the discussion with the IP experts from China 578 Mobile, China Telecom and China Unicom does great help to this work. 579 The discussion in the Yang models design teams of different VPNs, 580 Tunnels, MPLS features also help much for the abstraction of network 581 services. Research work of colleagues of authors of the draft in 582 different controllers and orchestrators including ONOS, ODL, 583 OpenStack, etc. provides extensive thinking on the model design. 584 The authors would like to acknowledge all these helpful work. 586 11. References 588 11.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, 592 DOI 10.17487/RFC2119, March 1997, 593 . 595 11.2. Informative References 597 [I-D.ietf-l3sm-l3vpn-service-model] 598 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 599 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 600 service-model-19 (work in progress), November 2016. 602 Authors' Addresses 604 Zhenbin Li 605 Huawei 606 Huawei Bld., No.156 Beiqing Rd. 607 Beijing 100095 608 China 610 Email: lizhenbin@huawei.com 611 Qiong Sun 612 China Telecom 613 No.118 Xizhimennei street, Xicheng District 614 Beijing 100035 615 China 617 Email: sunqiong@ctbri.com.cn 619 Yi Zheng 620 China Unicom 621 No.9, Shouti Nanlu, Haidian District 622 Beijing 100048 623 China 625 Email: zhengyi39@chinaunicom.cn