idnits 2.17.1 draft-bestbar-teas-ns-packet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1245 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-01 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 == Outdated reference: A later version (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group T. Saad 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: May 3, 2021 October 30, 2020 7 Realizing Network Slices in IP/MPLS Networks 8 draft-bestbar-teas-ns-packet-00 10 Abstract 12 Network slicing provides the ability to partition a physical network 13 into multiple isolated logical networks of varying sizes, structures, 14 and functions so that each slice can be dedicated to specific 15 services or customers. Network slices need to operate in parallel 16 with varying degrees of isolation while providing slice elasticity in 17 terms of network resource allocation. The Differentiated Service 18 (Diffserv) model allows for carrying multiple services on top of a 19 single physical network by relying on compliant nodes to apply 20 specific forwarding treatments on to packets that carry the 21 respective Diffserv code point. This document proposes a solution 22 based on the Diffserv model to realize network slicing in IP/MPLS 23 networks. The proposed solution is agnostic to the path control 24 technology used in the network slicing domain and allows service 25 differentiation of traffic within a given network slice. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 64 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Network Resource Slicing Membership . . . . . . . . . . . . . 5 66 2.1. Dedicated Network Resources . . . . . . . . . . . . . . . 6 67 2.2. Shared Network Resources . . . . . . . . . . . . . . . . 6 68 3. Path Selection . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Approaches to Network Resource Slicing . . . . . . . . . . . 7 70 4.1. Data Plane Network Resource Slicing . . . . . . . . . . . 7 71 4.2. Control Plane Network Resource Slicing . . . . . . . . . 8 72 4.3. Data and Control Plane Network Resource Slicing . . . . . 10 73 5. Network Slice Instantiation . . . . . . . . . . . . . . . . . 11 74 5.1. Slice Intent . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Slice Per-Hop Definition . . . . . . . . . . . . . . . . 12 76 5.2.1. Slice Data Plane Selector . . . . . . . . . . . . . . 13 77 5.2.2. Slice Network Resource Reservation . . . . . . . . . 17 78 5.2.3. Slice Per-Hop Behavior . . . . . . . . . . . . . . . 18 79 5.2.4. Slice Topology Membership . . . . . . . . . . . . . . 19 80 5.3. Network Slice Boundary . . . . . . . . . . . . . . . . . 19 81 5.3.1. Network Slice Edge Nodes . . . . . . . . . . . . . . 19 82 5.3.2. Network Slice Interior Nodes . . . . . . . . . . . . 20 83 5.3.3. Network Slice Incapable Nodes . . . . . . . . . . . . 20 84 5.3.4. Combining Network Resource Slicing Approaches . . . . 21 85 5.4. Slice Traffic Steering . . . . . . . . . . . . . . . . . 22 86 6. Control Plane Extensions . . . . . . . . . . . . . . . . . . 22 87 7. Applicability to Path Control Technologies . . . . . . . . . 23 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 91 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 12.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 Network slicing allows a Service Provider, or a network operator to 100 create independent and isolated logical networks on top of a common 101 or shared physical network infrastructure. Such network slices can 102 be offered to customers or used internally by the Service Provider to 103 facilitate or enhance their service offerings. A Service Provider 104 can also use network slicing to structure and organize the elements 105 of its infrastructure. For example, certain network resource 106 capabilities and functionality can be grouped together providing a 107 self-contained unit (network slice) of varying size and complexity. 109 When logical networks representing network slices are realized on top 110 of a shared physical network, it is important to steer traffic on the 111 specific network resources allocated for the network slice. In 112 packet networks, the packets that traverse a specific network slice 113 MAY be identified by specific field(s) carried within the packet. A 114 network slice boundary node will usually mark or populate the 115 respective field(s) in packets that enter a network slice to allow 116 interior slice nodes to identity those packets and apply the specific 117 Per Hop Behavior (PHB) that is associated with the slice and that 118 defines the scheduling treatment and, in some cases, the packet drop 119 probability. 121 In a Differentiated Service (Diffserv) domain [RFC2475], packets 122 requiring the same forwarding treatment are classified and marked 123 with a Class Selector (CS) at domain ingress nodes. At transit 124 nodes, the CS field inside the packet is inspected to determine the 125 specific forwarding treatment to be applied before the packet is 126 forwarded further. 128 Multiple network slices can be realized on top of a shared physical 129 infrastructure network. A single network slice may also support 130 multiple forwarding treatments or Diffserv classes that can be 131 carried over the same logical network slice. This document proposes 132 a solution that allows proper placement of paths and respective 133 treatment of traffic traversing network slice resource(s) in IP/MPLS 134 networks. The network slice traffic may be marked at slice boundary 135 nodes with a Slice Selector (SS) to allow routers to apply a specific 136 forwarding treatment that guarantees the slice Service Level 137 Agreements (SLAs). Network slice traffic may further carry a 138 Diffserv CS to allow differentiation of forwarding treatments for 139 packets forwarded over the same network slice network resources. 141 For example, when using MPLS as a dataplane, it is possible to 142 identify packets belonging to the same slice by carrying a global 143 MPLS Slice Selector Label (SSL) in the MPLS label stack that 144 identifies the slice in each packet. Additional Diffserv 145 classification may be indicated in the MPLS Traffic Class (TC) bits 146 of the SSL to allow further differentiation of traffic treatments of 147 traffic traversing the same slice network resources. 149 1.1. Terminology 151 The reader is expected to be familiar with the terminology specified 152 in [I-D.nsdt-teas-ietf-network-slice-definition] and 153 [I-D.draft-nsdt-teas-ns-framework-04]. 155 The following terminology is used in the document: 157 Slicing capable node: 158 a node that supports one of the network slicing approaches 159 described in this document. 161 Slicing incapable node: 162 a node that does not support one of the network slicing approaches 163 described in this document. 165 Slice traffic: 166 traffic that is forwarded over network resource(s) associated with 167 a specific network slice. 169 Slice path: 170 a path that is setup over network resource(s) associated with a 171 specific network slice. 173 Slice-aware TE: 174 a mechanism for TE path selection that takes into account the 175 available network resource(s) associated with a specific network 176 slice. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 1.2. Acronyms and Abbreviations 186 CS: Class Selector 188 SS: Slice Selector 190 Slice-PHD: Slice Per-Hop Definition as described in Section 5.2 192 Slice-PHB: Slice Per-Hop Behavior as described in Section 5.2.3 193 SSL: Slice Selector Label as described in section Section 5.2.1 195 SSLI: Slice Selector Label Indicator 197 SLA: Service Level Agreement 199 SLO: Service Level Objective 201 Diffserv: Differentiated Services 203 DS-TE: Differentiated Services Traffic Engineering 205 MPLS: Multiprotocol Label Switching 207 LSP: Label Switched Path 209 LSR: Label Switching Router 211 LER: Label Edge Router 213 RSVP: Resource Reservation Protocol 215 TE: Traffic Engineering 217 SR: Segment Routing 219 1.3. Scope 221 The definition of Network Slice for use within the IETF and the 222 characteristics of IETF Network Slice are specified in 223 [I-D.draft-nsdt-teas-transport-slice-definition-04]. A framework for 224 reusing IETF VPN and traffic-engineering technologies to realize IETF 225 Network Slices is discussed in [I-D.draft-nsdt-teas-ns-framework-04]. 227 This document provides a solution that addresses the network slice 228 requirements in packet networks from a device and network resource 229 level perspective based on DiffServ principles. 231 2. Network Resource Slicing Membership 233 A network slice can span multiple parts of an IP/MPLS network (e.g. 234 all or specific network resources in the access, aggregation, or core 235 network), and can stretch across multiple operator domains. A 236 network slice may include all or a sub-set of the physical nodes and 237 links of an IP/MPLS network, and it may be comprised of dedicated 238 and/or shared network resources (e.g. in terms of processing power, 239 storage, and bandwidth) and may have varying degrees of isolation 240 from the other network slices. 242 2.1. Dedicated Network Resources 244 Physical network resources may be fully dedicated to a specific 245 network slice. For example, this allows traffic belonging to a slice 246 to traverse the dedicated resources without network resource 247 contention from traffic of another network slice. Dedicated network 248 resource slicing allows for simple partitioning of the physical 249 network resources into multiple isolated network slices without the 250 need to distinguish packets traversing the dedicated network 251 resources since only one slice traffic can use them. 253 2.2. Shared Network Resources 255 To optimize network utilization, sharing of the physical network 256 resources may be desirable. In such case, the same physical network 257 resource capacity is partitioned among logical network slice(s). 258 Shared network resources can be partitioned in the dataplane (for 259 example by applying hardware policers and shapers), partitioned in 260 the control plane by providing a logical representation of the 261 physical link that has a subset of the network resources available to 262 it. 264 3. Path Selection 266 Path selection in a network can be network state dependent, or 267 network state independent as described in Section 5 of 268 [I-D.draft-dt-teas-rfc3272bis-11]. The latter is the choice commonly 269 used by IGP(s) when selecting a best path to a destination prefix, 270 while the former is used by ingress TE routers, or Path Computation 271 Engines (PCEs) when optimizing the placement of a flow based on the 272 current network resource utilization. 274 For example, when steering traffic on a delay optimized path, the IGP 275 can use its Link State Database (LSDB)'s view of the network topology 276 to compute a path optimizing for the delay metric of each link in the 277 network resulting in a cumulative lowest delay path. 279 When path selection is network state dependent, the path computation 280 can leverage Traffic Engineering mechanisms (e.g. as defined in 281 [RFC2702]) to compute feasible paths taking into account the incoming 282 traffic demand rate and current state of network. This allows 283 avoiding overly utilized link(s), and reduces the chance of 284 congestion on traversed link(s). 286 To enable TE path placement, the link state is advertised with 287 current reservation(s), thereby reflecting the available bandwidth on 288 each link. Such link reservations may be maintained centrally on a 289 network wide network resource manager, or distributed on devices (as 290 usually done with RSVP). TE extensions exist today to allow IGPs 291 (e.g. [RFC3630] and [RFC5305]), and BGP-LS [RFC7752] to advertise 292 such link state reservations. 294 When network resource reservations are also slice aware, the link 295 state can carry per network slice state (e.g. per network slice link 296 reservable bandwidth). This allows path computation to take into 297 account the specific network resources available for a network slice 298 when determining the path for a specific flow. In this case, we 299 refer to the process of path placement and path provisioning has 300 Slice-aware Traffic Engineering (Slice-aware TE). 302 4. Approaches to Network Resource Slicing 304 The partitioning of the shared network resources amongst multiple 305 slices can be achieved in: 307 a) control plane only, or 309 b) data plane only, or 311 c) both control and data planes. 313 4.1. Data Plane Network Resource Slicing 315 The physical network resources can be partitioned on network devices 316 by applying a Per-Hop forwarding Behavior (PHB) onto packets that 317 traverse the network device(s). In the Diffserv model, a Class 318 Selector (CS) is carried in the packet and is used by transit node(s) 319 to apply the PHB that determines the scheduling treatment and, in 320 some cases, drop probability for packet(s). 322 When dataplane network resource slicing is required, packets need to 323 be forwarded on the specific slice network resources and be applied a 324 specific forwarding treatment that is dictated by the Slice Per-Hop 325 Definition (Slice-PHD) (refer to Section 5.2 below) consumed by each 326 device. A slice Selector (SS) MAY be carried in each slice packet to 327 identify the slice that it belongs to. 329 The ingress node of a slice domain, in addition to marking packets 330 with a Diffserv CS, MAY also add a SS to each slice packet. The 331 transit node(s) within a slice domain MAY use the SS to associate 332 packets with a slice and to determine the Slice Per Hop Behavior 333 (Slice-PHB) that is applied to the packet (refer to Section 5.2.3 for 334 further details). The CS MAY be used to apply a Diffserv PHB on to 335 the packet to allow differentiation of traffic treatment within the 336 same network slice. 338 When dataplane only network resource slicing is desirable, routers 339 may rely on a network state independent view of the topology to 340 determine the best path(s) to reach destination(s). In this case, 341 the best path selection dictates the forwarding path of packets to 342 the destination. The SS that is carried in each packet determines 343 the specific Slice-PHB treatment for each slice along the selected 344 path. 346 For example, Segment-Routing flexible algorithm may be deployed in a 347 network to steer packet(s) on the lowest cumulative delay. A Slice- 348 PHD may be used to enable the link(s) along the least latency path 349 for dataplane slicing. Network slice packet(s) forwarded along the 350 lowest delay path can carry the SS when forwarded along the least 351 latency path. Transit nodes along the lowest delay path can inspect 352 the SS and Diffserv CS to determine the Slice-PHB and the Diffserv 353 class PHB to apply to packets before they are forwarded downstream. 355 4.2. Control Plane Network Resource Slicing 357 The physical network resources in the network can be logically 358 partitioned by having a representation of network resources appear in 359 a virtual topology. The virtual topology can contain all or a subset 360 of the physical network resource(s). The logical network resources 361 that appear in the virtual topology can reflect a part, whole, or in- 362 excess of the physical network resource capacity (when 363 oversubscription is desirable). For example, a physical link 364 bandwidth can be divided into fractions, each belonging to a slice. 365 Each fraction of the physical link bandwidth can be represented as a 366 logical link in a virtual topology that is used when determining 367 path(s) in a specific slice. The per slice virtual network can be 368 used by routing protocol(s), or by the ingress/PCE when computing 369 slice aware path(s). 371 To perform network state dependent path computation in each slice, 372 the resource reservation on each link needs to be slice aware (Slice- 373 aware TE). Depending on the network Slice-PHD, a physical link may 374 be part of one or more slice(s). Each such link may be sliced 'n' 375 ways so that each slice will have certain network resources 376 associated with it. The per slice network resource availability on 377 link(s) are updated (and may eventually be advertised in the network) 378 when new path(s) are placed in the network. The per slice resource 379 reservation, in this case, can be maintained on each device(s) or be 380 centralized on a resource reservation manager that holds link 381 reservation state(s) on links in the network. 383 A number of network slice(s) can share the available network 384 resource(s) allocated to each network slice amongst a group. In this 385 case, a node can update the reservable bandwidth for each slice to 386 take into consideration the available bandwidth from other slice(s) 387 in the same group. 389 For illustration purposes, the diagram below represents bandwidth 390 isolation or sharing amongst a group of network slice(s). In 391 Figure 1a, the network slices: Slice1, Slice2, Slice3 and Slice4 are 392 not sharing any bandwidths between each other. In Figure 1b, the 393 network slices: Slice1 and Slice2 can share the available bandwidth 394 portion allocated to each amongst them. Similarly, Slice3 and Slice4 395 can share amongst themselves any available bandwidth allocated to 396 them, but they cannot share available bandwidth allocated to Slice1 397 or Slice2. In both cases, the Max Reservable Bandwidth may exceed 398 the actual physical link resource capacity to allow for over 399 subscription. 401 I-----------------------------I I-----------------------------I 402 <--Slice1-> I I-----------------I I 403 I---------I I I <-Slice1-> I I 404 I I I I I-------I I I 405 I---------I I I I I I I 406 I I I I-------I I I 407 <-----Slice2------> I I I I 408 I-----------------I I I <-Slice2-> I I 409 I I I I I---------I I I 410 I-----------------I I I I I I I 411 I I I I---------I I I 412 <---Slice3----> I I I I 413 I-------------I I I Slice1 + Slice2 I I 414 I I I I-----------------I I 415 I-------------I I I I 416 I I I I 417 <---Slice4----> I I-----------------I I 418 I-------------I I I <-Slice3-> I I 419 I I I I I-------I I I 420 I-------------I I I I I I I 421 I I I I-------I I I 422 I Slice1+Slice2+Slice3+Slice4 I I I I 423 I I I <-Slice4-> I I 424 I-----------------------------I I I---------I I I 425 <--Max Reservable Bandwidth--> I I I I I 426 I I---------I I I 427 I I I 428 I Slice3 + Slice4 I I 429 I-----------------I I 430 I Slice1+Slice2+Slice3+Slice4 I 431 I I 432 I-----------------------------I 433 <--Max Reservable Bandwidth--> 434 (a) (b) 436 Figure 1: (a) bandwidth allocation(s) when no sharing between 437 slice(s), (b) bandwidth allocation(s) when sharing between slice(s) 438 of the same group. 440 4.3. Data and Control Plane Network Resource Slicing 442 In order to support strict guarantees and hard isolation between 443 network slice(s), the network resource(s) can be partitioned in both 444 the control plane and data plane. 446 The control plane partitioning allows the creation of customized 447 topologies per slice that router(s) or a Path Computation Engine 448 (PCE) can use to determine optimal path placement for specific demand 449 flows (Slice-aware TE). 451 The data plane partitioning protects slice traffic from network 452 resource contention that occurs due to bursts in traffic from 453 different slice(s) traversing the same shared network resource. 455 5. Network Slice Instantiation 457 A network slice can span multiple technologies and multiple 458 administrative domains. Depending on the network slice consumer's 459 requirements, a network slice can be isolated from other network 460 slices in terms of data, control or management planes. 462 The instantiation of a network slice may necessitate a network Slice 463 Manager or service orchestrator that accepts a Service Layer Slice 464 Intent as input and is translates it to a network wide device 465 specific Slice-PHD as shown in Figure 2. 467 The Diffserv procedures may be employed within the same network slice 468 to realize multiple classes of traffic belonging to the same slice. 470 +----------+ 471 | Slice | 472 | Manager | 473 +----------+ 474 | Network Slice 475 | Service Layer 476 ========================================= 477 | Network Slice 478 | Device/Resource Layer 479 | 480 | Slice Per-Hop Definition 481 | Distribution 482 XXXX|XXXXXX 483 XX /| XX 484 XX / | XX 485 XX / | XX 486 XXXX v v XXXX 487 XXX Ingress All XXX 488 XXX node(s) nodes XXX 489 XXX XXX 490 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 491 <----------- Path Control ---------> 492 RSVP-TE/SR-Policy /SR-FlexAlgo .. 494 Figure 2: Network Slice instantiation model. 496 5.1. Slice Intent 498 A network slicing solution may be realized using a network slice 499 service Layer, and a device/resource Layer. The service layer can be 500 managed by a service orchestrator that exposes a north bound 501 interface to slice consumers that can be used to convey the intent. 502 Depending on the use cases and type of services for which the end-to- 503 end slice is instantiated, multiple levels of control may be exposed 504 to the tenants by a slice provider. 506 For example, network slicing provider may allow for a connectivity 507 and data processing that is tailored to specific customer 508 requirements. At the service layer, the consumer of a network slice 509 expresses their intent for a particular network slice by specifying 510 requirements rather than how a slice is realized. The requirements 511 for a network slice can vary and can be expressed in terms of 512 connectivity needs between end-points (point-to-point, point-to- 513 multipoint or multipoint-to-multipoint) with customizable network 514 capabilities that may include data speed, quality, latency, 515 reliability, security, and services (refer to 516 [I-D.draft-nsdt-teas-transport-slice-definition-04] for more 517 details). These capabilities are always provided based on a Service 518 Level Agreement (SLA) between the network slice consumer and the 519 provider. 521 The network slice orchestrator is responsible for translating the 522 network slice consumer intent into a Slice-PHD that can be 523 instantiated by network elements at Device/Resource layer so that the 524 network slice consumer requirements in terms of network 525 characteristics are met. 527 5.2. Slice Per-Hop Definition 529 The high-level slice intent is consumed to produce a set of features 530 and attributes that can be provisioned on network elements. The 531 device level Slice-PHD includes attributes related to: 533 o Dataplane specific properties: This includes the SS, any firewall 534 rules or flow-spec filters, and QoS profiles associated with the 535 slice and any classes within it. 537 o Control plane specific properties: This includes guaranteed 538 bandwidth, any network resource sharing amongst slice(s), and 539 slice reservation preference to prioritize any reservations of a 540 specific slice over others. 542 o Membership policies: This defines policies that dictate node/link/ 543 function network resource topology association for a specific 544 slice. 546 There is a desire for flexibility in implementing network slices to 547 support the services across networks consisting of products from 548 multiple vendors, and may be grouped into disparate domains and using 549 various path control technologies and tunnel types. It is expected 550 that having a standardized data model for a Slice-PHD will facilitate 551 the instantiation of a network slice on a network slicing capable 552 node. 554 It is also possible to deliver a Slice-PHD to network devices using 555 several mechanisms, including using protocols such as NETCONF or 556 RESTCONF, or exchanging it using a suitable routing protocol that 557 network devices participate in (such as IGP(s) or BGP). 559 5.2.1. Slice Data Plane Selector 561 A router MUST be able to identify a packet as belonging to a network 562 slice before it can apply the proper forwarding treatment or PHB 563 associated with the slice. One or more fields within the packet MAY 564 be selected as a SS to do this. 566 Per Slice Forwarding Address: 568 One approach to distinguish packets targeted to a destination but 569 belong to different slices is to assign multiple forwarding 570 addresses (or multiple MPLS label bindings in the case of MPLS 571 network) to the same destination - one for each slice the 572 destination can be reached over. For example, when realizing a 573 network slice over an IP dataplane, the same destination can be 574 assigned multiple IP addresses (or multiple SRv6 locators in the 575 case of SRv6 network) to enable steering of traffic to the same 576 destination over multiple network slices. 578 Similarly, when an MPLS dataplane is used, [RFC3031] states in 579 Section 2.1 that: 'Some routers analyze a packet's network layer 580 header not merely to choose the packet's next hop, but also to 581 determine a packet's "precedence" or "class of service'. In such 582 case, the same destination can be assigned multiple MPLS label 583 bindings corresponding to an LSP that traverses network resources 584 of a specific slice towards the destination. 586 The specific slice forwarding address (or MPLS forwarding label) 587 can be carried in the packet belonging to a network slice to allow 588 (IP or MPLS) routers along the path to identify the packets and 589 apply the respective per Slice-PHB and forwarding treatment. This 590 approach requires maintaining per slice state for each destination 591 in the network in both the control and data plane and on each 592 router in the network. 594 For example, consider a network slicing provider with a network 595 composed of 'N' nodes, each with 'K' adjacencies to its neighbors. 596 Assuming a node is reachable in as many as 'M' network slice(s), 597 the node will have to assign and advertise reachability for 'N' 598 unique forwarding addresses, or MPLS forwarding labels 599 corresponding to the 'N' slices. Similarly, each node will have 600 to assign a unique forwarding address (or MPLS forwarding label) 601 for each of its 'K' adjacencies to enable strict steering over 602 each. Consequently, the control plane at any node in the network 603 will need to store as many as (N+K)*M states. In addition, a node 604 will have to store and program (N+K)*M forwarding addresses or 605 labels entries in its Forwarding Information Base (FIB) to realize 606 this. Therefore, as 'N', 'K', and 'M' parameters increase, this 607 approach will have scalability challenges both in the control and 608 data planes. 610 Per Slice Selector: 612 A Slice Selector (SS) field can be carried in each packet to 613 identify the packet belonging to a specific slice, independent of 614 the forwarding address or MPLS forwarding label that is bound to 615 the destination. Routers within the network slice domain can use 616 the forwarding address (or MPLS forwarding label) to determine the 617 forwarding path, and use the SS field in the packet to determine 618 the specific Slice-PHB that gets applied on the packet. This 619 approach allows better scale since it relies on a single 620 forwarding address or MPLS label binding to be used independent of 621 the number of network slices required along the path. In this 622 case, the additional SS field will need to be carried, and 623 maintained in each packet while it traverses the slice domain. 625 The SS can be carried in one of multiple fields within the packet, 626 depending on the dataplane type used. For example in MPLS 627 networks, the SS can be represented as a global MPLS label that is 628 carried in the packet's MPLS label stack. All packets that belong 629 to the same slice MAY carry the same SS label in the MPLS label 630 stack. It is possible, as well, to have multiple SS label(s) 631 point to the same Slice-PHB. 633 The MPLS SS Label (SSL) may appear in several positions in the 634 MPLS label stack. For example, the MPLS SSL can be maintained at 635 the top of the label stack while the packet is forwarded along the 636 MPLS path. In this case, the forwarding at each hop is determined 637 by the forwarding label that resides below the SSL. Figure 3 638 shows an example where the SSL appears at the top of MPLS label 639 stack in a packet. PE1 is a network Slice edge node that receives 640 the packet that needs to be steered over a slice specific MPLS 641 Path. PE1 computes the SR Path composed of the Label Segment- 642 List={9012, 9023}. It imposes a SSL=1001 corresponding to Slice- 643 ID=1001 followed by the SR Path Segment-List. At P1, the top 644 label sets the context of the packet to Slice-ID=1001. The 645 forwarding of the packet is determined by inspecting the 646 forwarding label (below the SSL) within the context of SSL. 648 SR Adj-SID: SSL: 1001 649 9012: P1-P2 650 9023: P2-PE2 652 /-----\ /-----\ /-----\ /-----\ 653 | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | 654 \-----/ \-----/ \-----/ \-----/ 656 In 657 packet: 658 +------+ +------+ +------+ +------+ 659 | IP | | 1001 | | 1001 | | 1001 | 660 +------+ +------+ +------+ +------+ 661 | Pay- | | 9012 | | 9023 | | IP | 662 | Load | +------+ +------+ +------+ 663 +----- + | 9023 | | IP | | Pay- | 664 +------+ +------+ | Load | 665 | IP | | Pay- | +------+ 666 +------+ | Load | 667 | Pay- | +------+ 668 | Load | 669 +------+ 671 Figure 3: SSL at top of label stack. 673 The SSL can also reside at the bottom of the label stack. For 674 example, the VPN service label may also be used as an SSL which 675 allows steering of traffic towards one or more egress PEs over the 676 same network slice. In such cases, one or more service labels MAY 677 be mapped to the same slice. The same VPN label may also be 678 allocated on all Egress PEs so it can serve as a single SSL for a 679 specific network slice. Alternatively, a range of SSL (VPN 680 labels) may be mapped to a single network slice to allow carrying 681 multiple VPN(s) over the same network slice as shown in Figure 4. 683 SR Adj-SID: SSL (VPN) on PE2: 1001 684 9012: P1-P2 685 9023: P2-PE2 687 /-----\ /-----\ /-----\ /-----\ 688 | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | 689 \-----/ \-----/ \-----/ \-----/ 691 In 692 packet: 693 +------+ +------+ +------+ +------+ 694 | IP | | 9012 | | 9023 | | 1001 | 695 +------+ +------+ +------+ +------+ 696 | Pay- | | 9023 | | 1001 | | IP | 697 | Load | +------+ +------+ +------+ 698 +----- + | 1001 | | IP | | Pay- | 699 +------+ +------+ | Load | 700 | IP | | Pay- | +------+ 701 +------+ | Load | 702 | Pay- | +------+ 703 | Load | 704 +------+ 706 Figure 4: SSL or VPN label at bottom of label stack. 708 In some cases, the position of the SSL may not be at a fixed place 709 in the MPLS label header. In this case, transit routers cannot 710 expect the SSL at a fixed place in the MPLS label stack. This can 711 be addressed by introducing a new Special Purpose Label from the 712 label reserved space called a Slice Selector Label Indicator 713 (SSLI). The slice network ingress boundary node, in this case, 714 will need to impose at least two additional MPLS labels (SSLI + 715 SSL) to identify the slice that the packets belong to as shown in 716 Figure 5. 718 SR Adj-SID: SSLI/SSL: SSLI/1001 719 9012: P1-P2 720 9023: P2-PE2 722 /-----\ /-----\ /-----\ /-----\ 723 | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | 724 \-----/ \-----/ \-----/ \-----/ 726 In 727 packet: 728 +------+ +------+ +------+ +------+ 729 | IP | | 9012 | | 9023 | | SSLI | 730 +------+ +------+ +------+ +------+ 731 | Pay- | | 9023 | | SSLI | | 1001 | 732 | Load | +------+ +------+ +------+ 733 +------+ | SSLI | | 1001 | | IP | 734 +------+ +------+ +------+ 735 | 1001 | | IP | | Pay- | 736 +------+ +------+ | Load | 737 | IP | | Pay- | +------+ 738 +------+ | Load | 739 | Pay- | +------+ 740 | Load | 741 +------+ 743 Figure 5: SSLI and bottom SSL at bottom of label stack. 745 When the slice is realized over an IP dataplane, the SSL can be 746 encoded in the IP header. For example, the SSL can be encoded in 747 portion of the IPv6 Flow Label field as described in 748 [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01]. 750 5.2.2. Slice Network Resource Reservation 752 Bandwidth and network resource allocation strategies for network 753 slicing are essential to achieve optimal placement of paths within 754 the network while still meeting the target SLOs. 756 Resource reservation allows for the managing of available bandwidth 757 and for prioritization of existing allocations to enable preference 758 based preemption when contention on a specific network resource 759 arises. Sharing of a network resource's available bandwidth amongst 760 a group of slices may also be desirable. For example, a slice may 761 not always be using all of its reservable bandwidth; this allows 762 other slices in the same group to use the available bandwidth 763 resources. 765 Congestion on shared network resources may result from sub-optimal 766 placement of paths in different network slices. When this occurs, 767 preemption of some slice specific paths may be desirable to alleviate 768 congestion. A preference based allocation scheme enables 769 prioritization of slice paths that can be preempted. 771 Since network characteristics and its state can change over time, the 772 per slice topology and its state also needs to be propagated in the 773 network to enable ingress TE routers or Path Computation Engine 774 (PCEs) to perform accurate path placement based on the current state 775 of the network slice. 777 5.2.3. Slice Per-Hop Behavior 779 In Diffserv terminology, the forwarding behavior that is assigned to 780 a specific class is called a Per-Hop Behavior (PHB). The PHB defines 781 the forwarding precedence that a marked packet with a specific CS 782 receives in relation to other traffic on the Diffserv-aware network. 784 A Slice Per Hop Behavior (Slice-PHB) is the externally observable 785 forwarding behavior applied to a specific packet belonging to a 786 slice. The goal of a Slice-PHB is to provide a specified amount of 787 network resources for traffic belonging to a specific slice. A 788 single network slice may also support multiple forwarding treatments 789 or services that can be carried over the same logical network slice. 791 The slice traffic may be identified at slice boundary nodes by 792 carrying a SS to allow router(s) to apply a specific forwarding 793 treatment that guarantee the slice SLA(s). 795 With Differentiated Services (Diffserv) it is possible to carry 796 multiple service(s) over a single converged network. Packets 797 requiring the same forwarding treatment are marked with a Class 798 Selector (CS) at domain ingress nodes. Up to eight classes or 799 Behavior Aggregated (BAs) may be supported for a given Forwarding 800 Equivalence Class (FEC) [RFC2475]. To support multiple services over 801 the same network slice, a slice packet MAY also carry a Diffserv CS 802 to identify the specific Diffserv forwarding treatment to be applied 803 on the different service traffic belonging to the same slice. 805 At transit nodes, the CS field carried inside the packets are used to 806 determine the specific Per Hop Behavior (PHB) that determines the 807 forwarding and scheduling treatment before packets are forwarded, and 808 in some cases, drop probability for each packet. 810 5.2.4. Slice Topology Membership 812 A network slice is built on top of a customized topology that may 813 include the full or subset of the physical network topology. The 814 network slice topology could also span multiple administrative 815 domains and/or multiple dataplane technologies. 817 The network slice topology can overlap or share a subset of links 818 with another network slice topology. A number of policies or 819 topology filters can be defined to limit the specific topology 820 elements that belong to a network slice. 822 The Slice-PHD membership can carry the topology filtering policies. 823 For example, such policies can leverage Resource Affinities as 824 defined in [RFC2702] to include or exclude certain link(s) in a 825 specific network slice topology. The Slice-PHD may also include a 826 reference to a predefined topology (e.g. derived from from a Flexible 827 Algorithm Definition (FAD) as defined in [I-D.ietf-lsr-flex-algo], or 828 Multi-Topology ID as defined [RFC4915]. 830 Alternatively, the topology filtering policies can specify specific 831 link properties (such as delay, bandwidth capacity, security) to 832 filter/include such link(s) in a network slice topology. 834 5.3. Network Slice Boundary 836 A network slice originates at the boundary of a network slice 837 provider at edge node(s). Traffic that is steered over the network 838 slice may traverse network slicing capable interior nodes, as well 839 as, network slicing incapable interior nodes. 841 The network slice may compose of one or more administrative 842 domain(s); for example, an organization's intranet or an ISP. The 843 administration of the network is responsible for ensuring that 844 adequate network resources are provisioned and/or reserved to support 845 the SLAs offered by the network end-to-end. 847 5.3.1. Network Slice Edge Nodes 849 Network slicing edge nodes sit at the boundary of a network slice 850 provider network and receive traffic that requires steering over 851 network resources specific to a network slice. The slice edge nodes 852 are responsible for identifying network slice specific traffic flows 853 by possibly inspecting multiple fields from inbound packets (e.g. 854 implementations may inspect IP traffic's network 5-tuple in the IP 855 and transport protocol headers) to decide on which network slice it 856 can be forwarded. 858 Network slice ingress nodes may condition the inbound traffic at 859 network boundaries in accordance with the requirements or rules of 860 each service's SLA(s). The requirements and rules for network slice 861 services are set using mechanisms which are outside the scope of this 862 document. 864 When dataplane slicing is required, the slice boundary nodes are 865 responsible for adding a suitable SS onto packets that belong to 866 specific network slices. In addition, edge nodes MAY mark the 867 corresponding Diffserv CS to differentiate between different types of 868 traffic carried over the same network slice. 870 5.3.2. Network Slice Interior Nodes 872 A network slice interior node receives slice traffic and MAY be able 873 to identify the packets belonging to a specific network slice by 874 inspecting the SS field carried inside each packet, or by inspecting 875 other fields within the packet that may identify specific flows 876 belonging to a specific network slice. For example when dataplane 877 slicing is required, interior nodes can use the SS carried within the 878 packet to apply the corresponding Slice-PHB forwarding behavior. 879 Nodes within the network slice provider network may also inspect the 880 Diffserv CS within each packet to apply a per Diffserv class PHB 881 within the network slice, and allow differentiation of forwarding 882 treatments for packets forwarded over the same network slice network 883 resources. 885 5.3.3. Network Slice Incapable Nodes 887 Packets that belong to a network slice may need to traverse nodes 888 that are incapable of network slicing. In this case, several options 889 are possible to allow the network slice traffic to continue to be 890 forwarded over such devices and be able to resume the network slice 891 forwarding treatment once the traffic reaches devices that are 892 capable of network slicing. 894 When dataplane network slicing is desirable, packets carry a SS to 895 allow slice interior nodes to identify them. To enable end-to-end 896 network slicing, the SS MUST be maintained in the packets as they 897 traverse devices within the network - including devices incapable of 898 network slicing. 900 For example, when the SS is an MPLS label at the bottom of the MPLS 901 label stack, packets can traverse over devices that are incapable of 902 network slicing without any further considerations. On the other 903 hand, when the SSL is at the top of the MPLS label stack, packets can 904 be bypassed (or tunneled) over the network slicing incapable devices 905 towards the next device that supports network slicing as shown in 906 Figure 6. 908 SR Node-SID: SSL: 1001 @@@: network slicing enforced 909 1601: P1 ...: network slicing not enforced 910 1602: P2 911 1603: P3 912 1604: P4 913 1605: P5 915 @@@@@@@@@@@@@@ ........................ 916 . 917 /-----\ /-----\ /-----\ . 918 | P1 | ----- | P2 | ----- | P3 | . 919 \-----/ \-----/ \-----/ . 920 | @@@@@@@@@@ 921 | 922 /-----\ /-----\ 923 | P4 | ------ | P5 | 924 \-----/ \-----/ 926 +------+ +------+ +------+ 927 | 1001 | | 1604 | | 1001 | 928 +------+ +------+ +------+ 929 | 1605 | | 1001 | | IP | 930 +------+ +------+ +------+ 931 | IP | | 1605 | | Pay- | 932 +------+ +------+ | Load | 933 | Pay- | | IP | +------+ 934 | Load | +------+ 935 +----- + | Pay- | 936 | Load | 937 +------+ 939 Figure 6: Extending network slice over slicing incapable device(s). 941 5.3.4. Combining Network Resource Slicing Approaches 943 It is possible to employ a combination of the approaches that were 944 discussed in Section 4 to realize an end-to-end network slice. For 945 example, data and control plane network resource slicing can be 946 employed in parts of a network, while control plane only slicing can 947 be employed in the other parts of the network. The Slice-aware path 948 selection in such case can take into account the per slice available 949 network resources. Packets carry a SS within them so the 950 corresponding Slice-PHB can be enforced on the parts of the network 951 that realize dataplane network resource slicing. The SS can be 952 maintained while traffic traverses nodes that do not enforce any 953 dataplane slicing, and so slice PHB enforcement can resume once 954 traffic traverses slicing capable nodes. 956 5.4. Slice Traffic Steering 958 The usual techniques to steer traffic onto paths can be applicable 959 when steering traffic over paths established in a specific network 960 slice. 962 For example, one or more (layer-2 or layer-3) VPN services can be 963 directly mapped to paths established in a specific network slice. In 964 this case, traffic that arrives on the Provider Edge (PE) router over 965 external interface(s) can be directly mapped to a specific network 966 slice path. External interface(s) can be further partitioned (e.g. 967 using VLANs) to allow mapping one or more VLANs to specific network 968 slice paths. 970 Another option is steer specific destinations directly over specific 971 network slices. This allows traffic arriving on any external 972 interface and targeted to such destinations to be directly steered 973 over the slice transport paths. 975 A third option that can also be used is to utilize a dataplane 976 firewall filter or classifier to enable matching of several fields in 977 the incoming packets to decide whether the packet is steered on a 978 specific slice. This option allows for applying a rich set of 979 rule(s) to identify specific packets to be mapped to a network slice. 980 However, it requires dataplane network resources to be able to 981 perform the additional checks in hardware. 983 6. Control Plane Extensions 985 Routing protocol(s) may need to be extended to carry additional per 986 slice link state. For example, [RFC5305], [RFC3630], and [RFC7752] 987 are ISIS, OSPF, and BGP protocol extensions to exchange network link 988 state information to allow ingress TE routers and PCE(s) to do proper 989 path placement in the network. The extensions required to support 990 network slicing may be defined in other document(s), and are outside 991 the scope of this document. 993 The provisioning of the network slicing device Slice-PHD may need to 994 be automated. Multiple options are possible to facilitate automation 995 of provisioning a network slice definition on device(s) that are 996 capable of network slicing. 998 For example, a YANG data model for the network Slice-PHD may be 999 supported on network devices and controllers. A suitable transport 1000 (e.g. NETCONF [RFC6241], RESTCONF [RFC8040], or gRPC) may be used to 1001 enable configuration and retrieval of state information for network 1002 slicing on network device(s). The network Slice-PHD YANG data model 1003 may be defined in a separate document, and is outside the scope of 1004 this document. 1006 7. Applicability to Path Control Technologies 1008 The network slicing approach(s) described in this document are 1009 agnostic to the technology used to setup path(s) that carry 1010 networking slice traffic. Once feasible path(s) within a network 1011 slice are selected, it is possible to use RSVP-TE protocol [RFC3209] 1012 to setup or signal the LSP(s) that would be used to carry slice 1013 traffic. Specific extension(s) to RSVP-TE protocol to enable 1014 signaling of slice aware RSVP LSP(s) are outside the scope and will 1015 be tackled in a separate document(s). 1017 Alternatively, Segment Routing (SR) [RFC8402] may be used and the 1018 feasible path(s) can realized by steering over specific segment(s) or 1019 segment-list(s) using an SR policy. Further detail(s) on how the 1020 approach(es) presented in this document can be realized over an SR 1021 network will be tackled in a separate document. 1023 8. IANA Considerations 1025 This document has no IANA actions. 1027 9. Security Considerations 1029 The main goal of network slicing is to allow for some level of 1030 isolation for traffic from multiple different network slices that are 1031 utilizing a common network infrastructure and to allow for different 1032 levels of services to be provided for traffic traversing a single 1033 network slice resource(s). 1035 A variety of techniques may be used to achieve this, but the end 1036 result will be that some packets may be mapped to specific 1037 resource(s) and may receive different (e.g., better) service 1038 treatment than others. The mapping of network traffic to a specific 1039 slice is indicated primarily by the SS, and hence an adversary may be 1040 able to utilize resource(s) allocated to a specific network slice by 1041 injecting packets carrying the same SS field in their packets. 1043 Such theft-of-service may become a denial-of-service attack when the 1044 modified or injected traffic depletes the resources available to 1045 forward legitmiate traffic belonging to a specific network slice. 1047 The defense against this type of theft and denial-of-service attacks 1048 consists of the combination of traffic conditioning at network 1049 slicing domain boundaries with security and integrity of the network 1050 infrastructure within a network slicing domain. 1052 10. Acknowledgement 1054 The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, and 1055 Prabhu Raj Villadathu Karunakaran for their review of this document, 1056 and for providing valuable feedback on it. 1058 11. Contributors 1060 The following individuals contributed to this document: 1062 Colby Barth 1063 Juniper Networks 1064 Email: cbarth@juniper.net 1066 Srihari R. Sangli 1067 Juniper Networks 1068 Email: ssangli@juniper.net 1070 Chandra Ramachandran 1071 Juniper Networks 1072 Email: csekar@juniper.net 1074 12. References 1076 12.1. Normative References 1078 [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01] 1079 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 1080 "Stateless and Scalable Network Slice Identification for 1081 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01 1082 (work in progress), July 2020. 1084 [I-D.ietf-lsr-flex-algo] 1085 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1086 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1087 algo-13 (work in progress), October 2020. 1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", BCP 14, RFC 2119, 1091 DOI 10.17487/RFC2119, March 1997, 1092 . 1094 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1095 Label Switching Architecture", RFC 3031, 1096 DOI 10.17487/RFC3031, January 2001, 1097 . 1099 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1100 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1101 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1102 . 1104 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1105 (TE) Extensions to OSPF Version 2", RFC 3630, 1106 DOI 10.17487/RFC3630, September 2003, 1107 . 1109 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1110 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1111 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1112 . 1114 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1115 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1116 2008, . 1118 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1119 S. Ray, "North-Bound Distribution of Link-State and 1120 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1121 DOI 10.17487/RFC7752, March 2016, 1122 . 1124 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1125 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1126 May 2017, . 1128 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1129 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1130 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1131 July 2018, . 1133 12.2. Informative References 1135 [I-D.draft-dt-teas-rfc3272bis-11] 1136 Farrel, A., "Overview and Principles of Internet Traffic 1137 Engineering", draft-dt-teas-rfc3272bis-11 (work in 1138 progress), May 2020. 1140 [I-D.draft-nsdt-teas-ns-framework-04] 1141 Gray, E. and J. Drake, "Framework for Transport Network 1142 Slices", draft-nsdt-teas-ns-framework-04 (work in 1143 progress), July 2020. 1145 [I-D.draft-nsdt-teas-transport-slice-definition-04] 1146 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1147 Tantsura, "IETF Definition of Transport Slice", draft- 1148 nsdt-teas-transport-slice-definition-04 (work in 1149 progress), September 2020. 1151 [I-D.nsdt-teas-ietf-network-slice-definition] 1152 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1153 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 1154 teas-ietf-network-slice-definition-00 (work in progress), 1155 October 2020. 1157 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1158 and W. Weiss, "An Architecture for Differentiated 1159 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1160 . 1162 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1163 McManus, "Requirements for Traffic Engineering Over MPLS", 1164 RFC 2702, DOI 10.17487/RFC2702, September 1999, 1165 . 1167 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1168 and A. Bierman, Ed., "Network Configuration Protocol 1169 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1170 . 1172 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1173 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1174 . 1176 Authors' Addresses 1178 Tarek Saad 1179 Juniper Networks 1181 Email: tsaad@juniper.net 1183 Vishnu Pavan Beeram 1184 Juniper Networks 1186 Email: vbeeram@juniper.net