idnits 2.17.1 draft-barguil-teas-network-slices-instantation-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RefNBIdraft' is mentioned on line 324, but not defined == Missing Reference: 'RFC8049' is mentioned on line 456, but not defined ** Obsolete undefined reference: RFC 8049 (Obsoleted by RFC 8299) == Missing Reference: 'G.827' is mentioned on line 510, but not defined == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-05 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-12 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-09 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Barguil 3 Internet-Draft L.M. Contreras 4 Intended status: Informational Telefonica 5 Expires: 8 September 2022 V. Lopez 6 Nokia 7 R. Rokui 8 Ciena 9 O. Gonzalez de Dios 10 Telefonica 11 7 March 2022 13 Instantiation of IETF Network Slices in Service Providers Networks 14 draft-barguil-teas-network-slices-instantation-03 16 Abstract 18 Network Slicing (NS) is an integral part of Service Provider 19 networks. The IETF has produced several YANG data models to support 20 the Software-Defined Networking and network slice architecture and 21 YANG-based service models for network slice (NS) instantiation. 23 This document describes the relationship between IETF Network Slice 24 models for requesting the IETF Network Slices and (e.g., Layer-3 25 Service Model, Layer-2 Service Model) and Network Models (e.g., 26 Layer-3 Network Model, Layer-2 Network Model) used during their 27 realizations. In addition, this document describes the communication 28 between the IETF Network Slice Controller and the network controllers 29 for the realization of IETF network slices. 31 The IETF Network Slice YANG model provides the customer-oriented view 32 of the network slice. Thus, once the IETF Network Slice controller 33 (NSC) receives a request, it needs to map it to accomplish the 34 specific parameters expected by the network controllers. The network 35 models are analyzed to satisfy the IETF Network Slice requirements, 36 and the gaps in existing models are reported. 38 The document also provides operational and security considerations 39 when deploying network slices in Service Provider networks. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 8 September 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Reference Architecture and Components . . . . . . . . . . . . 4 77 2.1. Possible architectural options for IETF Network Slice 78 Controller . . . . . . . . . . . . . . . . . . . . . . . 4 79 2.2. Possible relationship of IETF Network Slice service model 80 with other models . . . . . . . . . . . . . . . . . . . . 7 81 3. IETF Network Slice Requirements and Data Models . . . . . . . 8 82 4. IETF Network Slice Procedure . . . . . . . . . . . . . . . . 9 83 5. Network Controller Operation . . . . . . . . . . . . . . . . 10 84 5.1. LxVPN Service Models . . . . . . . . . . . . . . . . . . 10 85 5.2. LxVPN Network Models . . . . . . . . . . . . . . . . . . 11 86 5.3. Traffic Engineering Models . . . . . . . . . . . . . . . 11 87 5.4. Traffic Engineering Service Mapping . . . . . . . . . . . 11 88 6. Operational Considerations . . . . . . . . . . . . . . . . . 11 89 6.1. Availability . . . . . . . . . . . . . . . . . . . . . . 12 90 6.2. Downlink throughput / Uplink throughput. . . . . . . . . 12 91 6.3. Protection scheme . . . . . . . . . . . . . . . . . . . . 12 92 6.4. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 6.5. Packet loss rate . . . . . . . . . . . . . . . . . . . . 13 95 7. Network Slice Procedure . . . . . . . . . . . . . . . . . . . 13 96 7.1. IETF Network Slice requested to Hierarchical Network 97 Controller . . . . . . . . . . . . . . . . . . . . . . . 14 98 7.2. IETF Network Slice requested to Network Slice 99 Controller . . . . . . . . . . . . . . . . . . . . . . . 16 100 7.3. Network Slice Controller as part of the domain 101 controller . . . . . . . . . . . . . . . . . . . . . . . 17 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 106 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 107 13. Normative References . . . . . . . . . . . . . . . . . . . . 20 108 Annex. Example of relationship between IETF NBI model parameters 109 and L3SM model parameters . . . . . . . . . . . . . . . . 22 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 112 1. Introduction 114 The IETF has produced several YANG data models to support the 115 Software-Defined Networking and network slice architecture. 117 The IETF Network Slice YANG service model provides the customer- 118 oriented view of the network slice. Once the IETF Network Slice 119 controller (NSC)receives a request, it needs to map it to accomplish 120 the specific parameters expected by the network controller. 122 Several Service Models and Network Models, including Layer-3 Service 123 Model (L3SM), Layer-2 Service Model (L2SM) and Network Models which 124 may be utilized for IETF Network Slicing, are analyzed can satisfy 125 the IETF Network Slice requirements. In addition, identified gaps on 126 existing models are reported. 128 This document describes the architecture and communication process 129 between the Network Slice Controller and a network controller for 130 IETF network slice creation. 132 Editor's Note: the terminology in this draft will be aligned with the 133 final terminology selected for describing the notion of IETF Network 134 Slice when applied to IETF technologies, as being defined in 135 [I-D.ietf-teas-ietf-network-slices]. 137 1.1. Terminology 139 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 140 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 141 document, are to be interpreted as described in [RFC2119]. 143 2. Reference Architecture and Components 145 As described in [I-D.ietf-teas-ietf-network-slices], the IETF Network 146 Slice Controller (NSC) is a functional entity for control and 147 management of IETF network slices. As shown in Figure A, NSC from 148 its Northbound Interface (NBI exposes set of APIs that allow a higher 149 level system to request an IETF network slice. The NSC NBI supports 150 the request for enabling of an IETF Network Slice (i.e., creation, 151 modification or deletion). Upon receiving a request from its NBI, 152 NSC finds the resources needed for realization of the IETF Network 153 Slice and in turn interfaces from its Southbound Interface (SBI) with 154 one or more Network Controllers for the realization of the requested 155 IETF Network Slice. 157 This document focuses on how IETF Network Slice Controller (NSC) can 158 be implemented in the operator's network. 160 +------------------------------------------+ 161 | A higher level system | 162 | (e.g E2E network slice orchestrator) | 163 +------------------------------------------+ 164 A 165 | NSC NBI 166 V 167 +------------------------------------------+ 168 | IETF Network Slice Controller (NSC) | 169 +------------------------------------------+ 170 A 171 | NSC SBI 172 V 173 +------------------------------------------+ 174 | Network Controller(s) | 175 +------------------------------------------+ 177 Figure 1 Network Slice Controller as a module of the Hierarchical SDN 178 controller. 180 2.1. Possible architectural options for IETF Network Slice Controller 182 Several architectural definitions have arisen on the IETF to support 183 SDN and network slicing deployments. The architectural proposal 184 defined in [I-D.ietf-teas-ietf-network-slices] includes a three-level 185 hierarchy and expresses how each level relates with the ACTN 186 architecture framework. 188 Figure 2 defines depicts a possible architecture using those 189 concepts. It starts from a top consumer or high-level operational 190 systems. Next, the IETF Network Slice Controller function might be 191 part of the Hierarchical network controller (e.g., as the MDSC in the 192 ACTN context [RFC8453]) as a modular function. At the bottom, two 193 network controllers, each one can handle multiple or single underlay 194 technologies. 196 +------------------------------+ 197 | High-level operation system. | 198 +--------------+---------------+ 199 |IETF Network Slice Request 200 | 201 +-------------------v------------------+ 202 | | 203 | Hierarchical Network | 204 | Controller/Orchestrator | 205 | | 206 | +-------------------------------+ | 207 | | IETF Network Slice Controller | | 208 | +-------------------------------+ | 209 | | 210 +-------------------+------------------+ 211 | 212 | 213 +--------------+---------------+ 214 | | 215 v v 216 +-------------+----------+ +-------------+----------+ 217 | Network Controller | | Network Controller | 218 +-------------+----------+ +-------------+----------+ 219 | | 220 | | 221 v v 222 Network Elements Network Elements 224 Figure 2 IETF Network Slice Controller as a module of the 225 Hierarchical SDN controller. 227 In other implementations, the IETF Network Slice Controller can be a 228 stand-alone element and directly interact with the network 229 controller, as depicted in Figure 2. In this scenario, the services 230 request follows a data-enrichment path, where each entity adds more 231 information to the service request. This document describes how the 232 available service models and network models interact to deliver the 233 network slices in a service provider environment. 235 +-------------------------------+ 236 | High-level operation system | 237 +-------------+-----------------+ 238 |IETF Network Slice Request 239 | 240 +-------------v-----------------+ 241 | IETF Network Slice Controller | 242 +-------------+-----------------+ 243 | 244 | 245 +-------------v-----------------+ 246 | Network Controller | 247 +-------------+-----------------+ 248 | 249 | 250 v 251 Network Elements 253 Figure 3 The IETF Network Slice Controller as a stand-alone entity. 255 As another implementation possibility, the IETF Network Slice 256 Controller can be integrated with the Network controller and directly 257 realize the network slice using device data models to configure the 258 network devices. The sample architecture is depicted in Figure 4. 260 +-------------------------------+ 261 | High-level operation system | 262 +-------------+-----------------+ 263 |IETF Network Slice Request 264 | 265 +-------------v----------------+ 266 | Network Controller | 267 | | 268 |+----------------------------+| 269 || Network Slice Controller || 270 |+----------------------------+| 271 | | 272 +-------------+----------------+ 273 | 274 | 275 v 276 Network Elements 278 Figure 4 IETF Network Slice Controller as a module of the Network 279 controller. 281 2.2. Possible relationship of IETF Network Slice service model with 282 other models 284 IETF Network Slice service is expected to serve as input from where 285 deriving some other models in the network. According to the 286 architectural options before, different relationships could be 287 considered. Figure 5 reflects a couple of options. 289 Operations Support and Business Support YANG Modules 291 +-----------------------+ +-----------------------+ 292 | | | | 293 | Customer Service | | Other | 294 | YANG Modules | | Operations Support | 295 | | | and | 296 | +-----------------+ | | Business Support | 297 | | IETF Network | | | YANG Modules | 298 | | Slice service |-------+ | | 299 | | model | | | | | 300 | +-----------------+ | | | | 301 | | | | | | 302 | __________V_________ | | | | 303 |/ +------+ +------+\ | | | | 304 | | | | | | | | | 305 | | L2SM | | L3SM | | | | | 306 | | | | | | | | | 307 | +------+ +------+ | | | | 308 |\____________________/ | | | | 309 +-----------|-----------+ | +-----------------------+ 310 | | 311 - - - - - - | - - - - - - - -| - - - - - - - - - - - - - - - - 312 | | Network Service YANG Modules 313 _____________V________________V__________________________________ 314 / \ 315 / +------------+ +-------------+ +-------------+ +-------------+ \ 316 | | | | | | | | 317 | - L2VPN | | - L2VPN | | EVPN | | L3VPN | 318 | - VPWS | | - VPLS | | | | | 319 | | | | | | | | 320 +------------+ +-------------+ +-------------+ +-------------+ 322 Figure 5 Possible relationships between models. 324 Thus, the IETF Network Slice model (e.g., as defined in [RefNBIdraft] 325 could feed existing service models, such as L2SM or L3SM, or could 326 feed existing network models (e.g., EVPN, L3VPN, etc). Existing 327 models both for service or network level could require some 328 extensions themselves, or their application in conjunction with some 329 other complementary models (e.g., TE model) to accomplish the service 330 objectives and expectations as declared in the IETF Network Slice 331 model. 333 3. IETF Network Slice Requirements and Data Models 335 The main set of requirements for the IETF Slice, based on the high- 336 level slice requirements from multiple organizations and use cases, 337 are compiled in [I-D.contreras-teas-slice-nbi] and reproduced bellow 338 the slice use cases reported: 340 +-----------------------------------------------+ 341 | Network Slice Requirements for 5G service | 342 +-----------------------------------------------+ 343 | Availability | 344 | Deterministic communication | 345 | Downlink throughput per network slice | 346 | Energy efficiency | 347 | Group communication support | 348 | Isolation level | 349 | Maximum supported packet size | 350 | Mission critical support | 351 | Performance monitoring | 352 | Slice quality of service parameters | 353 | Support for non-IP traffic | 354 | Uplink throughput per network slice | 355 | User data access | 356 | Delay tolerance | 357 +-----------------------------------------------+ 359 +-----------------------------------------------+ 360 | NFV-based services | 361 +-----------------------------------------------+ 362 | Incoming and outgoing bandwidth | 363 | Qos metrics | 364 | Directionality | 365 | MTU | 366 | Protection scheme | 367 | Connectivity mode | 368 +-----------------------------------------------+ 369 +-----------------------------------------------+ 370 | Network sharing | 371 +-----------------------------------------------+ 372 | Maximum and Guaranteed Bit Rate | 373 | Bounded latency | 374 | Packet loss rate | 375 | IP addressing | 376 | L2/L3 reachability | 377 | Recovery time | 378 | Secure connection | 379 +-----------------------------------------------+ 381 To accomplish those requirements, a set of YANG data models have been 382 proposed. Those Yang models, summarized in table xx, could be used 383 by an IETF Network Slice Controller to manage CRUD operations on the 384 IETF Network Slice. That is, these models aim capturing the 385 requirements from the consumer of the slice point of view and avoid 386 entering into the detail of how the slice is actually created. 388 * [draft-wd-teas-ietf-network-slice-nbi-yang]: A Yang Data Model for 389 IETF Network Slice NBI. 391 * [draft-liu-teas-transport-network-slice-yang]: Transport Network 392 Slice YANG Data Model. 394 4. IETF Network Slice Procedure 396 An IETF Network Slice may use several underlying technologies. The 397 creation of a new IETF Network Slice will be initiated with following 398 three steps: 400 1. A higher level system requests connections with specific 401 characteristics via the NBI. 403 2. This request will be processed by an IETF NSC which specifies a 404 mapping between northbound request to any IETF Services, Tunnels, 405 and paths models. 407 3. A series of requests for creation of services, tunnels and paths 408 will be sent to the network to realize the transport slice. 410 5. Network Controller Operation 412 As a functional entity responsible for managing a network domain, the 413 network controller, can expose its northbound interface based on YANG 414 models. The IETF Network Slice Controller can use the network 415 controller's NBI during the realization of IETF Network Slice. The 416 following network models can be used for realization of IETF Network 417 slices: 419 * LxVPN Network models: 421 - These models describe a VPN service from the network point of 422 view. It supports the creation of Layer 3 and Layer 2 services 423 using several control planes. 425 * Traffic Engineering models: 427 - These models allow to manipulate Traffic Engineering tunnels 428 within the network segment. Technology-specific extensions 429 allow to work with a desired technology (e.g. MPLS RSVP-TE 430 tunnels, Segment Routing paths, OTN tunnels, etc.) 432 * TE Service Mapping extensions: 434 - These extensions allow to specify for LxVPN the details of an 435 underlay based on TE. 437 * ACLs and routing policies models: 439 - Even though ACLs and routing policies are device models, it's 440 exposure in the NBI of a domain controller allows to provide an 441 additional granularity that the network domain controller is 442 not able to infer on its own. 444 5.1. LxVPN Service Models 446 The framework defined in [RFC8969] compiles a set of YANG data models 447 for automating network services. The data models can be used during 448 the service and network management life cycle (e.g., service 449 instantiation, service provisioning, service optimization, service 450 monitoring, service diagnosing, and service assurance). The Service 451 models could be a realization of IETF Network slice requests. 453 The following models are examples of Network models that describe 454 services. 456 * [RFC8049]: YANG Data Model for L3VPN Service Delivery 457 * [RFC8466]: A YANG Data Model for Layer 2 Virtual Private Network 458 (L2VPN) Service Delivery 460 5.2. LxVPN Network Models 462 Similar to the Service Models, the framework defined in [RFC8969] 463 compiles a set of YANG data models for automating network services. 464 The Network models could be reused for the realization of Network 465 slice requests. 467 The following models are examples of Network models that describe 468 services. 470 * [I-D.ietf-opsawg-l3sm-l3nm]: A Layer 3 VPN Network YANG Model 472 * [I-D.ietf-opsawg-l2nm]: A Layer 2 VPN Network YANG Model 474 5.3. Traffic Engineering Models 476 TEAS has defined a collection of models to allow the management of 477 Traffic Engineering tunnels. 479 * [I-D.ietf-teas-yang-te]: A YANG Data Model for Traffic Engineering 480 Tunnels, Label Switched Paths and Interfaces. The model allows to 481 instantiate paths in a TE enabled network. Note that technology 482 augmented models are require to particular per-technology 483 instantiations. 485 5.4. Traffic Engineering Service Mapping 487 The IETF has defined a YANG model to set up the procedure to map VPN 488 service/network models to the TE models. This model, known as 489 service mapping, allows the network controller to assign/retrieve 490 transport resources allocated to specific services. At the moment 491 there is just one service mapping model 492 [I-D.ietf-teas-te-service-mapping-yang]. The "Traffic Engineering 493 (TE) and Service Mapping Yang Model" augments the VPN service and 494 network models. 496 6. Operational Considerations 498 This section outlines the compliance and operational aspects of 499 Network Controller models with IETF Network slice requirements. 500 Section presented the requirements of the IETF Network slice. In 501 this subsection it is analyzed how available YANG models that can be 502 used by a Network Controller can satisfy those requirements and 503 identify gaps. 505 6.1. Availability 507 As per [draft-ietf-teas-te-service-mapping-yang], Availability is a 508 probabilistic measure of the length of time that a VPN/VN instance 509 functions without a network failure. As per RFC 8330, The parameter 510 "availability", as described in [G.827], [F.1703], and [P.530], is 511 often used to describe the link capacity. The availability is a time 512 scale, representing a proportion of the operating time that the 513 requested bandwidth is ensured". 515 The calculation of the availability is not trivial and would need to 516 be clearly scoped to avoid misunderstandings. 518 The set of Yang models proposed today allow to request tunnels/paths 519 with different resiliency requirements in terms of protection and 520 restoration. However, none of them include the possibility of 521 requesting a specific availability (e.g. 99.9999%). 523 6.2. Downlink throughput / Uplink throughput. 525 The LxVPN Models ([I-D.ietf-opsawg-l3sm-l3nm] and 526 [I-D.ietf-opsawg-l2nm]) allow to specify the bandwdidth at the 527 interface level between the slice and the customer. In addition, the 528 Service Mapping model [draft-ietf-teas-te-service-mapping-yang] 529 allows to bind a VPN to a given LSP, which have its bandwidth 530 requirements. Additionally, TE models can force a give bandwidth in 531 the connection between Provider Edges. 533 Previous comment applies to the incoming and outgoing bandwidth 534 parameters required for the NFV-based services use case in 535 [I-D.contreras-teas-slice-nbi]. The Network sharing use case has 536 Maximum and Guaranteed Bit Rate parameters. These parameters can be 537 mapped to the TE tunnel models when setting up LSPs [draft-ietf-teas- 538 yang-te]. 540 6.3. Protection scheme 542 Protection schemes are mechanisms to define how to setup resources 543 for a given connection. TE tunnel models [draft-ietf-teas-yang-te] 544 includes protection and restoration as two main attributes. The 545 parameters included in the containers for protection and restoration 546 cover the requirements of the IETF NS related with protection 547 schemes. Similarly, TE models cover the parameter 'recovery time' 548 for the network sharing use case. 550 6.4. Delay 552 Delay is a critical parameter for several IETF NS types. Every use- 553 case defined in [I-D.contreras-teas-slice-nbi] contains delay 554 constraints. 5G use cases require 'delay tolerance', NFV-based 555 services have the delay information within 'QoS metrics' and 'Bounded 556 latency' in the network sharing use case. 558 During the realization of the IETF Network Slice, these parameters 559 are part of the requirements of a TE tunnel configuration [draft- 560 ietf-teas-yang-te]. They can be included within the 'path-metric- 561 bounds' parameter, so the created LSP fulfils the given metrics 562 bounds like 'path-metric-delay-average' or 'path-metric-delay- 563 minimum'. 565 6.5. Packet loss rate 567 The packet loss rate indicates the maximum rate for lost packets that 568 the service tolerates in the link. During the realization of the 569 IETF Network Slice, this attribute will influence the tunnel 570 selection and the value is included in the [draft-ietf-teas-yang-te] 571 document as the 'path-metric-loss". The 'path-metric-loss' is a 572 metric type, which measures the percentage of packet loss of all 573 links traversed by a P2P path. This parameter is required for 5G 574 services and network sharing use-case, while it is part of the 'QoS 575 metrics' for the NFV-based services. 577 7. Network Slice Procedure 579 Draft [draft-contreras-teas-slice-controller-models] shows the 580 internal structure of an IETF Network Slice Controller which can be 581 divided into two components: 583 * IETF Network Slice Mapper: this high-level component processes the 584 customer request, putting it into the context of the overall IETF 585 Network Slices in the network. 587 * IETF Network Slice Realizer: this high-level component processes 588 the complete view of transport slices including the one requested 589 by the customer, decides the proper technologies for realizing the 590 IETF Network Slice and triggers its realization. 592 Higher Level System 593 | 594 | NSC NBI 595 +-------------------------+ 596 | NSC | | 597 | v | 598 | +-----------------+ | 599 | | | | 600 | | NS Mapper | | 601 | | | | 602 | +-----------------+ | 603 | | | 604 | v | 605 | +-----------------+ | 606 | | | | 607 | | NS Realizer | | 608 | | | | 609 | +-----------------+ | 610 | | | 611 +-------------------------+ 612 | NSC SBI 613 v 614 Network Controllers 616 Figure 8: IETF Network Slice Controller Structure 618 The details of IETF network slice mapper and realize are provided 619 below for various implementation of NCS. 621 7.1. IETF Network Slice requested to Hierarchical Network Controller 623 Referring to Figure 1 in an integrated architecture, the IETF Network 624 Slice Controller (NCS) is part of a Hierarchical SDN controller 625 module, the NSC's and the Hierarchical Network Controller should 626 share the same internal data and the same NBI. Thus, the H-SDN 627 module must be able to: 629 * Map: The customer request received using the [draft-wd-teas-ietf- 630 network-slice-nbi-yang] must be processed by the NCS. The mapping 631 process takes the network-slice SLAs selected by the customer to 632 available Routing Policies and Forwarding policies. 634 * Realize: Create necessary network requests. The slice's 635 realization can be translated into one or several LXNM Network 636 requests, depending on the number of underlay controllers. Thus, 637 the NCS must have a complete view of the network to map the orders 638 and distribute them across domains. The realization should 639 include the expansion/selection of Forwarding Policies, Routing 640 Policies, VPN policies, and Underlay transport preference. 642 To maintain the data coherence between the control layers, the IETF 643 Network Slice ID ns-id used of the [draft-wd-teas-ietf-network-slice- 644 nbi-yang] must be directly mapped to the transport-instance-id at the 645 VPN-Node level. 647 + 648 | 649 | IETF Network Slice Request: 650 draft-wd-teas-ietf-network-slice-nbi-yang 651 | * network-slice-id 652 | 653 +-------------------v------------------+ 654 | | 655 | Hierarchical Network | 656 | Controller/Orchestrator | 657 | | 658 | +-------------------------------+ | 659 | | IETF Network Slice Controller | | 660 | +-------------------------------+ | 661 | | 662 +-------------------+------------------+ 663 IETF Network Slice Realizer: LXNM 664 VPN-id | 665 * transport-instance-id | 666 | 667 +--------------+---------------+ 668 | | 669 v v 670 +-------------+----------+ +-------------+----------+ 671 | Network Controller | | Network Controller | 672 +-------------+----------+ +-------------+----------+ 673 | | 674 | | 675 v v 676 Network Elements Network Elements 678 Figure 9 Workflow for the slice request in an integrated 679 architecture. 681 7.2. IETF Network Slice requested to Network Slice Controller 683 Referring to Figure 2 when the Network Slice Controller is a stand- 684 alone controller module, the NSC's should perform the same two tasks 685 described in section 6.1: 687 * Map: Process the customer request. The customer request can be 688 sent using the [draft-liu-teas-transport-network-slice-yang]. 689 This draft allows the topology mapping of the Slice request. 691 * Realize: Create necessary network requests. The slice's 692 realization will be translated into one LXNM Network request. As 693 the NCS has a topological view of the network, the realization can 694 include the customer's traffic engineering transport preferences 695 and policies. 697 + 698 |IETF Network Slice Request 699 draft-liu-teas-transport-network-slice-yang 700 network-id 701 | 702 +-------------v-----------------+ 703 | IETF Network Slice Controller | 704 +-------------+-----------------+ 705 | 706 IETF Network Slice Realizer: LXNM 707 VPN-id | 708 * Underlay-transport 709 * transport-instance-id 710 | 711 +-------------v----------------+ 712 | Network Controller | 713 +-------------+----------------+ 714 | 715 | 716 v 717 Network Elements 719 Figure 10 Workflow for the slice request in an stand-alone 720 architecture. 722 7.3. Network Slice Controller as part of the domain controller 724 The Network Slice Controller can be a module of the Network 725 controller. In that case, two options are available. One is to 726 share the same device data model in the NBI and SBI of the SDN 727 controller. The direct translation would reduce the service logic 728 implemented at the SDN controller level, grouping the mapping and 729 translation into a single task: 731 * Realize: As the device models are part of the network controller's 732 NBI thus, the realization can be done by the network controller 733 applying a simple service logic to send the Network elements. 735 + 736 | Slice Request based on 737 | Device Models 738 | 739 | 740 +------------------v------------------+ 741 | | 742 | Network | 743 | Controller | 744 | | 745 | +------------------------------+ | 746 | | Network Slice Controller | | 747 | +------------------------------+ | 748 | | 749 +------------------+------------------+ 750 | Device Models 751 | 752 v 753 Network Elements 755 Figure 11 Workflow for the slice request in an stand-alone 756 architecture. 758 A second option introduces a more complex logic in the network 759 controller and creates an abstraction layer to process the transport 760 slices. In that case, the controller should receive network slices 761 creation requests and maintain the whole set of implemented slices: 763 * Map & Realize: The mapping and realization can be done by the 764 Domain controller applying the service logic to create policies 765 directly on the Network elements. 767 + 768 |Slice Request 769 draft-liu-teas-transport-network-slice-yang-01 770 network-id 771 | 772 | 773 +------------------v------------------+ 774 | | 775 | Network | 776 | Controller | 777 | | 778 | +------------------------------+ | 779 | | Network Slice Controller | | 780 | +------------------------------+ | 781 | | 782 +------------------+------------------+ 783 | 784 | 785 v 786 Network Elements 788 Figure 12 Workflow for the slice request in an stand-alone 789 architecture. 791 8. Security Considerations 793 There are two main aspects to consider. On the one hand, the IETF 794 Network Slice has a set of security related requirements, such as 795 hard isolation of the slice, or encryption of the communications 796 through the slice. All those requirements need to be analyzed in 797 detailed and clearly mapped to the Network Controller and device 798 interfaces. 800 On the other hand, the communication between the IETF network slicer 801 and the network controller (or controllers or hierarchy of 802 controllers) need to follow the same security considerations as with 803 the network models. 805 The network YANG modules defines schemas for data that is designed to 806 be accessed via network management protocols such as NETCONF 807 [RFC6241] or RESTCONF [RFC8040]. 809 The lowest NETCONF layer is the secure transport layer, and the 810 mandatory-to-implement secure transport is Secure Shell (SSH) 811 [RFC6242]. 813 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 814 secure transport is TLS [RFC8466]. 816 The Network Configuration Access Control Model (NACM) [RFC8341] 817 provides the means to restrict access for particular NETCONF or 818 RESTCONF users to a preconfigured subset of all available NETCONF or 819 RESTCONF protocol operations and content. 821 The following summarizes the foreseen risks of using the Network 822 Models to instantiate IETF network Slices: 824 * Malicious clients attempting to delete or modify VPN services that 825 implements an IETF network slice. The malicious client could 826 manipulate security related aspects of the network configuration 827 that impact the requirements of the slice, failing to satisfy the 828 customer requirement. 830 * Unauthorized clients attempting to create/modify/delete a VPN hat 831 implements an IETF network slice service. 833 * Unauthorized clients attempting to read VPN services related 834 information hat implements an IETF network slice 836 * Malicious clients attempting to leak traffic of the slice. 838 9. IANA Considerations 840 This document is informational and does not require IANA allocations. 842 10. Conclusions 844 A wide variety of yang models are currently under definition in IETF 845 that can be used by Network Controllers to instantiate IETF network 846 slices. Some of the IETF slice requirements can be satisfied by 847 multiple means, as there are multiple choices available. However, 848 other requirements are still not covered by the existing models. A 849 more detailed definition of those uncovered requirements would be 850 needed. Finally, a consensus on the set of models to be exposed by 851 Network Controllers would facilitate the deployment of IETF network 852 slices. 854 11. Contributors 856 Daniel King:daniel@olddog.co.uk> 858 Figure 1 860 12. Acknowledgements 862 This work is partially supported by the European Commission under 863 Horizon 2020 grant agreement number 101015857 Secured autonomic 864 traffic management for a Tera of SDN flows (Teraflow). 866 13. Normative References 868 [I-D.contreras-teas-slice-nbi] 869 Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., 870 Tantsura, J., and K. Szarkowicz, "IETF Network Slice Use 871 Cases and Attributes for Northbound Interface of IETF 872 Network Slice Controllers", Work in Progress, Internet- 873 Draft, draft-contreras-teas-slice-nbi-05, 12 July 2021, 874 . 877 [I-D.ietf-opsawg-l2nm] 878 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 879 Munoz, "A Layer 2 VPN Network YANG Model", Work in 880 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 881 November 2021, . 884 [I-D.ietf-opsawg-l3sm-l3nm] 885 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 886 and A. Aguado, "A YANG Network Data Model for Layer 3 887 VPNs", Work in Progress, Internet-Draft, draft-ietf- 888 opsawg-l3sm-l3nm-18, 8 October 2021, 889 . 892 [I-D.ietf-teas-ietf-network-slices] 893 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 894 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 895 Network Slices", Work in Progress, Internet-Draft, draft- 896 ietf-teas-ietf-network-slices-08, 6 March 2022, 897 . 900 [I-D.ietf-teas-te-service-mapping-yang] 901 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 902 and J. Tantsura, "Traffic Engineering (TE) and Service 903 Mapping YANG Model", Work in Progress, Internet-Draft, 904 draft-ietf-teas-te-service-mapping-yang-09, 24 October 905 2021, . 908 [I-D.ietf-teas-yang-te] 909 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 910 and O. G. D. Dios, "A YANG Data Model for Traffic 911 Engineering Tunnels, Label Switched Paths and Interfaces", 912 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 913 29, 7 February 2022, 914 . 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, 919 DOI 10.17487/RFC2119, March 1997, 920 . 922 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 923 and A. Bierman, Ed., "Network Configuration Protocol 924 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 925 . 927 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 928 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 929 . 931 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 932 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 933 . 935 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 936 Access Control Model", STD 91, RFC 8341, 937 DOI 10.17487/RFC8341, March 2018, 938 . 940 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 941 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 942 DOI 10.17487/RFC8453, August 2018, 943 . 945 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 946 Data Model for Layer 2 Virtual Private Network (L2VPN) 947 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 948 2018, . 950 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 951 L. Geng, "A Framework for Automating Service and Network 952 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 953 January 2021, . 955 Annex. Example of relationship between IETF NBI model parameters and 956 L3SM model parameters 958 This annex presents an initial analysis of the relationship between 959 IETF NBI model parameters and L3SM service model parameters. 961 The L3SM service parameters are defined in section 6.2 of RFC 8299. 962 The following parameters are considered, so far: 964 * Bandwidth. This parameter indicates the bandwidth requirement 965 between each CE and PE participating in the service, then 966 referrign essentially to the required WAN link bandwidth. It is 967 expressed in terms of bits per second and individually specified 968 for both input and output. Despite it is not stated in RFC 8299, 969 this parameter can be interpreted as the CIR/PIR expected for the 970 CE - PE connection. 972 * MTU. This parameter indicates the maximum PDU size expected for 973 the layer-3 service. It is relevant since packets could be 974 discarded in case the customer sends packets with longer MTU than 975 the one expressed by this parameter. 977 * QoS. Regardign QoS, two different kind of parameters are 978 detailed. 980 - QoS classification policy. This policy is used to classify the 981 traffic received from the customer, and it is expressed as a 982 set of ordered rules. It is used for marking the input traffic 983 (from CE to PE) when the customer flows match any of the rules 984 in the list, setting the appropriate target class of service 985 (target-class-id). 987 - QoS profile. This profile defines the traffic-scheduling to be 988 applied to the flows for either Site-to-WAN, WAN-to-Site, or 989 both directions. It contains the following information per 990 class of service: rate-limit, latency, jitter and guaranteed 991 bandwidth. 993 * Multicast. This parameter identifies if the service is multicast, 994 and if so, what is the role of the site in the customer multicast 995 service topology (i.e., source, receiver, or both). It also 996 defines the kind of multicast relationship with the customer 997 (i.e., as a router requiring PIM, host requiring either IGMP or 998 MLD, or both), as well as the support of IPv4, IPv6 or both. 1000 On the other hand, the IETF NS NBI YANG model supports a number of 1001 SLOs and SLEs in the form of network slice service policy attributes. 1002 Such policy can apply to per-network slice, per-connection group or 1003 per-connection indivudually (over-writting of attributes is allowed 1004 as more granular information is provided). The following SLO 1005 attributes are detailed: 1007 * One-way / Two-way bandwidth, indicating the guaranteed minimum 1008 bandwidth between any two NSEs (unidirectional / bidirectional). 1010 * One-way / Two-way latency, indicating the guaranteed minimum 1011 latency between any two NSEs (unidirectional / bidirectional). 1013 * One-way / Two-way delay variation, indicating the maximum 1014 permissible delay variation of the slice (unidirectional / 1015 bidirectional). 1017 * One-way / Two-way packet loss, indicating the maximum permissible 1018 packet loss rate between endpoints (unidirectional / 1019 bidirectional). 1021 Additionally, the following SLEs are defined: 1023 * MTU, referring to the the maximum PDU size that the customer may 1024 use. 1026 * Security, indicating if encryption or other security measures are 1027 required between two endpoints. 1029 * Isolation, as a way of indicating the isolation level expected by 1030 the customer in the allocation of network resources. 1032 * Maximum occupancy level, to express the amount of flows to be 1033 admitted (and optionally a maximum number of countable resource 1034 units such as IP or MAC addresses). 1036 Thus, an initial mapping between L3SM and IETF NS NBI model can be 1037 performed as indicated in the follwoing table. 1039 + 1040 +-------------------------+---------------------------------+ 1041 | L3SM (RFC 8299) | IETF NSC NBI YANG model | 1042 +-------------------------+---------------------------------+ 1043 | Bandwidth | Sum of bandwidth SLO per NSE | 1044 | | counting all connections | 1045 +-------------------------+---------------------------------+ 1046 | MTU | MTU attribute in SLE | 1047 +-------------------------+---------------------------------+ 1048 | QoS | | 1049 | ........................|................................ | 1050 | - QoS classification | Defined in the model as | 1051 | policy | network-access-qos-policy-name | 1052 | | to be applied per access-point | 1053 | ........................|................................ | 1054 | - QoS profile | | 1055 | - rate-limit | Defined in the model as | 1056 | | incoming/outgong rate-limits | 1057 | | per end-point (or access-point) | 1058 | - latency | One-way / Two-way latency SLO | 1059 | - jitter | One-way / Two-way delay | 1060 | | variation SLO | 1061 | - bandwidth | One-way / Two-way bandwidth SLO | 1062 +-------------------------+---------------------------------+ 1063 | Multicast | The need of replication can be | 1064 | | inferred from | 1065 | | ns-connectivity-type. Further | 1066 | | details are not available (e.g. | 1067 | | source or receiver role) | 1068 +-------------------------+---------------------------------+ 1070 Table 1 Mapping of IETF NS NBI and L3SM service attributes. 1072 The following consideration can be made. 1074 * While the QoS profile in L3SM applies per service class, the 1075 parameters in IETF NS NBI apply per connection. So if per-class 1076 granularity is required in an IETF network slice, then different 1077 connections have to be defined between the same end-points, one 1078 per service class. 1080 * A number of attributes are not defined in L3SM such as packet 1081 loss, isolation or security. Then L3SM could not be sufficient to 1082 realize IETF network slices with such specific needs, unless those 1083 other objectives and expectations are provided by other means 1084 (e.g., realizing the L3SM thorugh technologies guaranteing 1085 dedicated resource allocation such as OTN). 1087 Authors' Addresses 1089 Samier Barguil 1090 Telefonica 1091 Distrito T 1092 28050 Madrid 1093 Spain 1094 Email: samier.barguilgiraldo.ext@telefonica.com 1096 Luis M. Contreras 1097 Telefonica 1098 Distrito T 1099 28050 Madrid 1100 Spain 1101 Email: luismiguel.contrerasmurillo@telefonica.com 1103 Victor Lopez 1104 Nokia 1105 Calle de María Tubau, 9 1106 28050 Madrid 1107 Spain 1108 Email: victor.lopez@nokia.com 1110 Reza Rokui 1111 Ciena 1112 Canada 1113 Email: rrokui@ciena.com 1115 Oscar Gonzalez de Dios 1116 Telefonica 1117 Distrito T 1118 28050 Madrid 1119 Spain 1120 Email: oscar.gonzalezdedios@telefonica.com