idnits 2.17.1 draft-peng-teas-network-slicing-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Other different constraints sets can also be defined to calculate TE paths for different overlay services within the same slice, regardless of the endogenous criteria of the slice. It is suggested that the set of constraints defined should contain the endogenous constraint of the slice. For some traffic engineering services that have strict requirements, especially such as the ulra-reliable low-latency communication service, it SHOULD not transfer over an MP2P LSP to avoid the risk of traffic congestion. The segment list should consist of pure adjacency-SIDs and other service funciton SIDs per AII, with guaranteed resources. The segment list could be computed by headend or SDN controller. -- The document date (October 20, 2020) is 1283 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) == Unused Reference: 'I-D.ali-spring-network-slicing-building-blocks' is defined on line 1145, but no explicit reference was found in the text == Unused Reference: 'I-D.nsdt-teas-transport-slice-definition' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1191, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-02 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgpls-inter-as-topology-ext-09 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-19 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-transport-slice-definition (ref. 'I-D.nsdt-teas-transport-slice-definition') ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Shaofu. Peng 3 Internet-Draft Ran. Chen 4 Intended status: Standards Track Gregory. Mirsky 5 Expires: April 23, 2021 ZTE Corporation 6 Fengwei. Qin 7 China Mobile 8 October 20, 2020 10 Packet Network Slicing using Segment Routing 11 draft-peng-teas-network-slicing-04 13 Abstract 15 This document presents a mechanism aimed at providing a solution for 16 network slicing in the transport network for 5G services. The 17 proposed mechanism uses a unified administrative instance identifier 18 to distinguish different virtual network resources for both intra- 19 domain and inter-domain network slicing scenarios. Combined with the 20 segment routing technology, the mechanism could be used for both 21 best-effort and traffic engineered services for tenants. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 23, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Architecture of TN Slicing . . . . . . . . . . . . . . . . . 4 59 2.1. Key Technologies of Transport slice . . . . . . . . . . . 5 60 3. Slicing Requirements . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Dedicated Virtual Networks . . . . . . . . . . . . . . . 6 62 3.2. End-to-End Slicing . . . . . . . . . . . . . . . . . . . 6 63 3.3. Unified NSI . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Traffic Engineering . . . . . . . . . . . . . . . . . . . 7 65 3.5. Summarized Requirements . . . . . . . . . . . . . . . . . 7 66 4. Conventions Used in This Document . . . . . . . . . . . . . . 8 67 5. Overview of Existing Identifiers . . . . . . . . . . . . . . 8 68 5.1. AG and EAG Bit . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Multi-Topology Identifier . . . . . . . . . . . . . . . . 9 70 5.3. SR Policy Color . . . . . . . . . . . . . . . . . . . . . 9 71 5.4. Flex-algorithm Identifier . . . . . . . . . . . . . . . . 9 72 5.5. New Slice-based Identifier Introduced . . . . . . . . . . 10 73 6. Overview of AII-based Mechanism . . . . . . . . . . . . . . . 10 74 6.1. Physical Network Partition by AII . . . . . . . . . . . . 11 75 6.2. Path within AII specific Slice . . . . . . . . . . . . . 11 76 6.2.1. SR-BE Path within AII specific Slice . . . . . . . . 12 77 6.2.2. SR-TE Path within AII specific Slice . . . . . . . . 13 78 6.3. Traffic Steering to SR policy within Slice . . . . . . . 13 79 6.4. Simple Variant of AII-based Slicing Scheme . . . . . . . 13 80 7. Resource Allocation per AII . . . . . . . . . . . . . . . . . 14 81 7.1. L3 Link Resource AII Configuration . . . . . . . . . . . 14 82 7.2. L2 Link Resource AII Configuration . . . . . . . . . . . 15 83 7.3. Node Resource AII Configuration . . . . . . . . . . . . . 15 84 7.4. Service Function Resource AII Configuration . . . . . . . 16 85 8. E2E Slicing with Centralized Mode . . . . . . . . . . . . . . 16 86 9. E2E Slicing with Distributed Mode . . . . . . . . . . . . . . 17 87 10. Combined with SR Flex-algorithm for Stack Depth Optimization 17 88 10.1. Flex-algo Using AII Criteria . . . . . . . . . . . . . . 18 89 10.2. Best-effort Color Template Mapping to Flex-algo . . . . 18 90 10.3. Traffic Engineering Color Template Mapping to Flex-algo 18 91 11. Network Slicing Examples . . . . . . . . . . . . . . . . . . 18 92 11.1. Intra-domain Network Slicing Example . . . . . . . . . . 19 93 11.1.1. Best-effort Service over Network Slice Example . . . 19 94 11.1.2. TE Service over Network Slice Example . . . . . . . 19 95 11.1.3. TE Service over Network Slice with Flex-algo Example 20 96 11.2. Inter-domain Network Slicing via BGP-LS Example . . . . 20 97 11.2.1. Best-effort Service Example . . . . . . . . . . . . 20 98 11.2.2. TE Service Example . . . . . . . . . . . . . . . . . 21 99 11.2.3. TE Service Using Flex-algo Example . . . . . . . . . 21 100 11.3. Inter-domain Network Slicing via BGP-LU Example . . . . 22 101 12. Implementation Suggestions . . . . . . . . . . . . . . . . . 22 102 12.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . 22 103 12.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 105 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 106 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 107 16. Normative references . . . . . . . . . . . . . . . . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 110 1. Introduction 112 According to 5G context, network slicing is the collection of a set 113 of technologies to create specialized, dedicated logical networks as 114 a service (NaaS) in support of network service differentiation and 115 meeting the diversified requirements from vertical industries. 116 Through the flexible and customized design of functions, isolation 117 mechanisms, and operation and management (O&M) tools, network slicing 118 is capable of providing dedicated virtual networks over a shared 119 infrastructure. A Network Slice Instance (NSI) is the realization of 120 network slicing concept. It is an E2E logical network, which 121 comprises of a group of network functions, resources, and connection 122 relationships. An NSI typically covers multiple technical domains, 123 which include a terminal, access network (AN), transport network (TN) 124 and a core network (CN), as well as a DC domain that hosts third- 125 party applications from vertical industries. Different NSIs may have 126 different network functions and resources. They may also share some 127 of the network functions and resources. 129 For a transport network, network slicing requires the underlying 130 network to support partitioning of the network resources to provide 131 the client with dedicated (private) networking, computing, and 132 storage resources drawn from a shared pool. The slices may be seen 133 as virtual networks. 135 This document describes how to realize TN-slice in the underlay 136 network, and analyze the necessity and usage of a new slice-based 137 identifier to represent specific virtual network that is requested by 138 the user of 5G service who have the specific resources and connection 139 requirements. This new slice-based identifier is expected to be not 140 only used for management system, but also for control and data plane 141 in the underlay network. 143 2. Architecture of TN Slicing 145 Relationship with NS Design Team: 147 The current scope of NS design team will focus on the framework of 148 the TN Slice.We would like to make some contributions of it, and we 149 will sent this section to the NS Design Team for dicussion. 151 +-----------+ +-----------+ +-----------+ 152 |Tenant VPN | | eMBB | | uRLLC | ...... Client/Tenant 153 +-----------+ +-----------+ +-----------+ Layer 155 ----------------------------------------------------------------------------------------------------- 156 L2VPN L3VPN EVPN Service Layer 157 o 158 o--o---o / o--o---o 159 /| \ o--o---o / 160 o o o /| \ o 161 o o o 162 ------------------------------------------------------------------------------------------------------ 163 Virtual-Network-1 Virtual-Network-2 164 __________________________________ ________________________________ 165 / / / / 166 / ++++ ++++ ++++ / / ++++ ++++ / 167 / + +---+ +---+ + / / + +--------+ + / 168 / ++++ ++++ ++++ / / ++++ ++++ / 169 / | | / / | | / Transport-Slice 170 / ++++ ++++ / / ++++ ++++ / Layer 171 / + +----+ + / / +--+------- +--+ / 172 / ++++ ++++ / / ++++ ++++ / 173 /__ ______________________________/ /_____________________________ / 175 ------------------------------------------------------------------------------------------------------ 176 ++++ ++++ ++++ 177 +--+------------+--+-----------+--+ 178 ++++ ++++ ++++ Physical Network 179 | | | Layer 180 | | | 181 ++++ ++++ ++++ 182 +--+-----------+--+----------+--+ 183 ++++ ++++ ++++ 185 Figure 1 Architecture of TN Slicing 187 Based on the concept and architecture of Transport slice, the basic 188 requirements and features of Transport slice are as following: 190 o On-Demand network reconstitution: The slice network can be 191 reconstituted in network topology and node capability to meet 192 service needs. Each slice network has its own specific bandwidth, 193 latency and lifecycle. Different Transport Slice networks are 194 isolated from each other, and have independent topology and 195 network resources. 197 o Decoupling of Service Slice Layer and Physical Network Layer: The 198 Service Slice Layer and the Physical Network Layer are decoupled, 199 and unaware of the details of each other, which simplifies the 200 deployment of services. 202 o Similarity of Transport Slice Network and Physical Network for 203 Service Layer: A Transport Slice Network Layer provides network 204 resources to the upper layer (Service Layer) which is the same as 205 the resources provided directly by a physical network from the 206 point view of the upper layer. Services such as VPN service etc. 207 can be deployed directly on the Transport slice network just as 208 they are deployed on the physical network. One Transport slice 209 network can support the deployment of more than one services or 210 VPNs. 212 o Data Plane Isolation of Transport Slice Network: The TN provides 213 two types of traffic isolation between different TN slices: hard 214 isolation and soft isolation. Hard isolation is implemented by 215 providing independent circuit switched connections for the 216 exclusive use of one slice, such as MTN (Metro Transport Network, 217 see ITU-T G.mtn), and ODUk. Soft isolation is implemented by 218 using a packet technology (e.g., Ethernet VLAN, MPLS tunnel, and 219 VPN). Services of different slices are isolated from each other. 221 o Transport Slice Network: There may be multiple Sub-TN-slices in a 222 Transport Slice Network, and those Sub-Transport slices may be 223 nested. Different sub-TN-slices can be also combined together for 224 an end-to-end TN slice service. 226 2.1. Key Technologies of Transport slice 228 For the transport network forwarding plane slicing, there are 229 basically two kinds of isolation technology: soft isolation 230 technology and hard isolation technology. The soft isolation is a 231 Layer 2 or Layer 3 technology, such as SR/IP/MPLS based tunnel 232 technology and VPN/VLAN based virtualization technology. The hard 233 isolation is a Layer 1 or optical-layer slicing technology based on 234 physically rigid pipelines, such as MTN, OTN and Wavelength Division 235 Multiplexing (WDM) technologies. In applications, the hybrid hard 236 and soft isolation solution is always used. The hard isolation 237 ensures service isolation, and the soft isolation supports service 238 bandwidth reuse. 240 So, The Key Technologies of Transport slice should include: Layer-one 241 Data Plane, Layer-Two Data Plane, and Layer-Three Data Plane. 243 3. Slicing Requirements 245 3.1. Dedicated Virtual Networks 247 An end-to-end virtual network with dedicated resources is the 248 advantage of network slicing than traditional DiffServ QoS and VPN. 249 For example, DiffServ QoS can distinguish VoIP traffic and other type 250 of traffic (such as high-definition video, web browsing), but can not 251 distinguish the same type of traffic from different tenants, nor 252 isolation of these traffic at all. 254 Another example is the IoT traffic of health monitoring network which 255 connected hospital and outpatient, it always has strict privacy and 256 safety requirements, including where the data can be stored and who 257 can access the data, all this can not be satisfied by DiffServ QoS as 258 it has not any function of network computing and storage. 260 Dedicated VN is a distinct object purchased by a customer, and it 261 provides specific function with predictable performance, guaranteed 262 level of isolation and safety. It is not just as QoS. 264 3.2. End-to-End Slicing 266 Only an end-to-end slice and fine-grained network can match ultra 267 delay and safety requirements of special service. End-to-end means 268 that it is constructed with AN-slice, TN-slice, and CN-slice part. 270 Although 3GPP technical specifications mainly focus on the operation 271 and management of AN-slice and CN-slice, which include some NF 272 (network function) components, TN-slice is also created and destroyed 273 according to the related NSI lifecycle. In fact, the 3GPP management 274 system will request expected link requirements related to the network 275 slice (e.g., topology, QOS parameters) with the help of the 276 management system that handles the TN part related to the slice. 278 For TN part, the link requirements are independent of the existing 279 domain partition of the network, i.e., any intra- or inter-domain 280 link is the candidate resource for the slice. It is also independent 281 of the existing underlay frame or routing technologies (IGP, BGP, 282 Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the 283 candidate resource. 285 From the end-to-end slicing requirement, the inter domain resource 286 guarantee needs to be paid more attention to. 288 3.3. Unified NSI 290 An NSI is indentified by S-NSSAI (Single Network Slice Selection 291 Assistance Information), which is allocated per PDU session and has 292 semantic global within the AN and CN. 294 For the purpose of operation and management simplicity, it is also 295 better to have a unified identifier with semantic global to 296 distinguish different TN-slice within the whole TN. TN-slice 297 identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n. 299 Instead, using different slice identifier across multi-domain of TN 300 for the specific TN-slice will introduce much and unnecessary 301 complexity, especially for case two devices belongs to different 302 domain try to exchange slice-based information directly through the 303 protocol mechanism in control plane, without the help of SDN 304 controller to translate the unified TN-slice identifier to an 305 individual domain-wide indentifier. 307 3.4. Traffic Engineering 309 5G system is expected to be able to provide optimized support for a 310 variety of different communication services, different traffic loads, 311 and different end-user communities. For example, the communication 312 services using network slicing may include: vehicle-to-everything 313 (V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service 314 with FMC (fixed-mobile convergence), massive IoT connections. Among 315 these service types, high data rates, high traffic densities, low- 316 latency, high-reliability are highlighted requirements. 318 Traffic engineering mechanism in TN must support the above 319 requirements, bandwidth and delay are two primary TE constraints. 321 3.5. Summarized Requirements 323 In summary, the following requirements would be satisfied for the 324 realization of TN-slice: 326 REQ1: Provide a distinct virtual network, including dedicated 327 topology, computation, and storage resource, not only traditional 328 QoS; 329 REQ2: Unified NSI for easy operation and maintenance; 331 REQ3: E2E network slicing, including both intra-domain and inter- 332 domain case; 334 REQ4: Customization resource for QoS purpose, bandwidth and delay are 335 basic constraints; 337 REQ5: Layer 2 as well as Layer 3 link resource partition; 339 4. Conventions Used in This Document 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in RFC2119. 345 5. Overview of Existing Identifiers 347 Currently there are multiple existing mature identifiers that could 348 be used to identify all or part of the virtual network's resources in 349 the transport network, such as: 351 o Administrative Group (AG) described in [RFC3630], [RFC5329], 352 [RFC5305] and Extended Administrative Groups (EAGs) described in 353 [RFC7308] 355 o Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915], 356 [RFC5340] 358 o SR policy color described in 359 [I-D.ietf-spring-segment-routing-policy] 361 o FA-id described in [I-D.ietf-lsr-flex-algo] 363 However, all these identifiers are not sufficient to meet the above 364 requirements of TN-slice. Note that all these identifiers have use 365 case of their own, besides the network slicing use case. Next, we 366 will discuss each of them to determine their matching of slicing 367 requirements. 369 5.1. AG and EAG Bit 371 AG and EAG are limited to serve as a link color scheme used in TE 372 path computation to meet the requirements of TE service for a tenant. 373 It is difficult to use them for an NSI allocation mapping (assuming 374 that each bit position of AG/EAG represents an NSI), and also 375 difficult to use them to represent non-link resources. Hence, they 376 do not meet REQ1, 2. Additionally, AG or EAG cannot be as an 377 identifier to organize specific forwarding tables or policys for 378 different virtual networks. 380 AG and EAG can be used as the attribute of both L3 interface and 381 L2-bundles member, to meet REQ5. 383 Although AG and EAG have semantic global, they don't fully meet REQ3. 384 For example, for an E2E path, inter domain links can also be selected 385 by their AG/EAG attributes, but they can't be adhered to intra domain 386 links through AG/EAG to let a complete view of virtual network be 387 presented. 389 5.2. Multi-Topology Identifier 391 MTR is limited to serve as an IGP logical topology scheme only used 392 in the intra-domain scenario. Thus it is challenging to select 393 inter-area link resources based on MT-ID when E2E inter-domain TE 394 path needs to be created for a tenant. And, by definition, MTR is 395 only used to represent topology resources and cannot be used for 396 various other types of resources. That is, it does not meet REQ1, 3. 398 Different IGP domain within the same TN-slice may be configured with 399 different MT-ID. Thus MT-ID does not meet REQ2. 401 MT-ID is only as L3 link attribute, not appropriate for L2-bundles 402 member, so it does not meet REQ5. 404 5.3. SR Policy Color 406 The color of SR policy defines a TE purpose, which includes a set of 407 constraints such as bandwidth, delay, TE metric, etc. Therefore 408 color is an abstract target, and it is difficult to get a distinct 409 virtual network according to a specific color value. In most cases, 410 only the headend and some other border nodes need to maintain the 411 color template, and a color-based virtual network is hard to present 412 because of too few participants and lack of interaction scheme. That 413 is, the color does not meet REQ1, 2. 415 We can continue to define TE affinity information in color-template, 416 to select L3 link or L2-bundles member,to meet REQ5. 418 Note that the color has global semantic, so it meets REQ3. 420 5.4. Flex-algorithm Identifier 422 Indeed, FA-id is a short mapping of SR policy color, and it may 423 inherit the matched-degree of the Policy Color. However, FA-id has 424 its own characteristics. A specific FA-id can have more distributed 425 participants and define explicit link resource so that an explicit FA 426 plane can be created. Unfortunately, different service of the same 427 tenant-slice will define different constraints, resulting in the need 428 to occupy more FA-id resources for single tenant-slice. The 429 relationship between FA-id and slice is not clear. That is, FA-id 430 does not meet REQ1. 432 On the other hand, FA-id, like MT-ID, is limited to serve as an IGP 433 algorithm scheme used in the intra-domain scenario. It is 434 challenging to select inter-area (especially inter-AS) link resources 435 according to FA-id when the E2E inter-domain TE path needs to be 436 created for the tenant. So, FA-id does not meet REQ3. 438 Different IGP domain within the same TN-slice may configure different 439 FA-ids, so it does not meet REQ2. 441 What is more important, the path in FA plane identified by FA-id is 442 MP2P LSP, so it is hard to define bandwidth reservation for service. 443 So, FA-id does not meet REQ4. Unless each link is totally dedicated 444 to a single FA plane, i.e., link resources are not shared among 445 multiple FA plane. 447 It is possible to let the link include/exclude rules defined by FA-id 448 be appropriate for both L3 link and L2-bundles member, to meet REQ5. 450 5.5. New Slice-based Identifier Introduced 452 Thus, there needs to introduce a new characteristic of NSI that meets 453 the above-listed requirements to isolate underlay resources, and it 454 is a slice-based identifier. 456 Firstly, it could serve as TE criteria for TE service, this aspect is 457 like AG/EAG; and secondly, as an identifier to orgnize specific 458 forwarding tables or policys for different virtual networks, this 459 aspect is like MT-ID or FA-id. 461 This document introduces a new property of NSI called "Administrative 462 Instance Identifier" (AII) and corresponding method of how to 463 instantiate it in the underlay network to match the above-listed 464 requirements. 466 6. Overview of AII-based Mechanism 468 SR policy [I-D.ietf-spring-segment-routing-policy], just like 469 traditional RSVP-TE LSP, can be used to realize IETF network slice in 470 underlay network. This document introduce AII-based mechanism to 471 enhance SR policy to support tenant-slice as well as service-slice. 472 It will signal the association of AII and shared resources required 473 to create and manage an NSI, and steer the packets to the path within 474 the specific NSI according to SR policy color. 476 SR policy color has semantic global in order to be conveniently 477 exchanged between two endpoints within TN-slice. These two endpoints 478 can configure the same color template information for the same color 479 value. AII, also with global semantic, can be contained in color 480 template to enhance SR policy to create a TE path within global TN- 481 slice identified by AII. Besides TE service served by explicit SR 482 policy instance, best-effort service can be served by AII-specific 483 forwarding tables or policys that are created by default once AII 484 configured. 486 The following is how AII-based mechanism works. 488 6.1. Physical Network Partition by AII 490 Each node and link in the physical network can be colored 491 dynamically, with shared or dedicated resources, to conform with 492 network slicing requirements. As previously mentioned, AII can be 493 used to color nodes and links to partition underlay resources. Also, 494 we may continue to use AG or EAG to color links for traditional TE 495 within a virtual network specified by an AII. A single or multiple 496 AIIs could be configured on each intra-domain or inter-domain link 497 regardless of IGP instance configuration. At the minimum, a link 498 always belongs to default AII (the value is 0). 500 The extension of the existing IGP-TE mechanisms [RFC3630] and 501 [RFC5305] to distribute AII information as a new TE parameter of a 502 link in the underlay network will be defined in another document. 504 Using BGP-LS [RFC7752], an SDN controller,can collect topology 505 information of each virtual network specified by AII with related 506 resources, and have a distinct view of each virtual network. 507 Extension of BGP-LS will also be defined in another document. 509 6.2. Path within AII specific Slice 511 Using the CSPF algorithm, a TE path for any best-effort (BE) or 512 traffic-engineered (TE) service can be calculated within a virtual 513 network specified by the AII. The computation criteria could be 514 or for the 515 BE and TE respectively. Combined with segment routing, the TE path 516 could be represented as: 518 o A single node-SID of the destination node, for the best-effort 519 service intra-domain; 521 o Several node-SIDs of the border node and the destination node, 522 adjacency-SID of inter-domain link, for the inter-domain best- 523 effort service; 525 o An explicit adjacency-SID list or compressed with several loose 526 node-SIDs, for traffic engineered service. 528 To distinguish forwarding behavior of different virtual networks, 529 Prefix-SID and Adjacency-SID need to be allocated per AII with 530 related resources, and advertised in the IGP domain. 532 6.2.1. SR-BE Path within AII specific Slice 534 Because packets of the best-effort service could be transported over 535 an MP2P LSP without congestion control, SR-BE path for each virtual 536 network specified by AII to forward best-effort packets may be 537 created in the IGP domain. 539 This document will register some standard AII value (see section 540 "IANA Considerations") to represent different type of slice. For 541 example, a slice type "normal" represent any slices that have 542 endogenous "min IGP metric" criteria to compute SPF path within the 543 slice. Thus, for a virtual network with slice type "normal", CSPF 544 computation with criteria is distributed on 545 each node within the virtual network. 547 Similarly, a slice type "uRLLC" represent any slices that have 548 endogenous "min delay metric" (Min Unidirectional Link Delay as 549 defined in [RFC7810]) criteria to compute SPF path within the slice. 550 For a virtual network with slice type "uRLLC", CSPF computation with 551 criteria is distributed on each node within the 552 virtual network. 554 Similarly, a slice type "TE" represent any slices that have 555 endogenous "TE metric" (TE default metric as defined in [RFC5305]) 556 criteria to compute SPF path within the slice. For a virtual network 557 with slice type "TE metric", CSPF computation with criteria is distributed on each node within the virtual network. 560 That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the 561 distributed CSPF computation is triggered by AII, using determined 562 criteria without negotiation among noeds. 564 Besides the best-effort service, SR-BE path for specific AII also 565 provide an escape way for traffic engineering service within the same 566 virtual network when the expected TE purpose can not be meet. 568 6.2.2. SR-TE Path within AII specific Slice 570 Other different constraints sets can also be defined to calculate TE 571 paths for different overlay services within the same slice, 572 regardless of the endogenous criteria of the slice. It is suggested 573 that the set of constraints defined should contain the endogenous 574 constraint of the slice. For some traffic engineering services that 575 have strict requirements, especially such as the ulra-reliable low- 576 latency communication service, it SHOULD not transfer over an MP2P 577 LSP to avoid the risk of traffic congestion. The segment list should 578 consist of pure adjacency-SIDs and other service funciton SIDs per 579 AII, with guaranteed resources. The segment list could be computed 580 by headend or SDN controller. 582 However, stack depth of the segment list MAY be optimized at a later 583 time based on local policies. 585 6.3. Traffic Steering to SR policy within Slice 587 The traffic of overlay service can be steerred to the above SR-BE 588 path or SR-TE tunnel/policy instance for the specific virtual 589 network. The overlay service could specify a color for TE purpose. 591 For example, color 1000 means to say "I need 592 best-effort forwarding within AII 10 resource", color 1001 means 593 to say "I need traffic engineering 594 forwarding within AII 10 resource, and only use links with AG 0x1 to 595 reach guarantee of not exceeding 10ms delay upper bound". 597 Service with color 1000 will be steered to an SR-BE entry of the 598 table identified by AII, or an SR-TE tunnel/policy in case of inter- 599 domain. 601 Service with color 1001 will be steered to an SR-TE tunnel/policy. 603 6.4. Simple Variant of AII-based Slicing Scheme 605 There is a simple variant of AII-based slicing scheme for initial 606 slicing requirement of service, where the SDN controller in 607 management partition the whole E2E network topology to multiple 608 strictly isolated VNs identified by AII in local, but let the 609 forwarding equipments of the underlay network be totally unware of 610 that. 612 The overlay service is steered to the SR policy whose path is limited 613 within specific VN using a pure adjacency-segment list. 615 This variant need not introduce any complex protocol mechanism of 616 control plane in the underlay network, however only for limited 617 scenes. There are no states per AII, except that QoS policy per AII 618 need to be configured in the underlay network. 620 7. Resource Allocation per AII 622 7.1. L3 Link Resource AII Configuration 624 In IGP domain, each numbered or unnumbered L3 link could be 625 configured with AII information and synchronized among IGP neighbors. 626 The IGP link-state database will contain L3 links with AII 627 information to support TE path computation taking account of AII 628 criteria. For a numbered L3 link, it could be represented as a tuple 629 630 , for unnumbered it could be . Each L3 link could be configured 632 to belong to a single AII or multiple AIIs. Note that an L3 link 633 always belongs to default AII(0). 635 For different tuple it would allocate a different 636 adjacency-SID, as well as advertising with different resource portion 637 such as bandwidth occupied. 639 Note that AII is independent of IGP instance. An L3 link that is not 640 part of the IGP domain, such as the special purpose for a static 641 route, or an inter-domain link, can also be configured with AII 642 information and allocate adjacency-SID per AII as the same as IGP 643 links. BGP-LS could be used to collect link state data with AII 644 information to the controller, BGP-LS has already provided a 645 mechanism to collect link state data from many source protocols, such 646 as IGP, Direct, Static configuration, etc., to cover network slicing 647 requirements. 649 When an L3 link joins to to multiple VNs, as traditional ways that 650 these VNs can share the total bandwidth resouce of the link with 651 preemption mode based on packet priority, this is what we know as 652 soft slicing. However, In some other scenarios, a hard slicing 653 scheme can be used to establish a hardened pipe to meet the slicing 654 business requirements, at this time each VN need dedicated bandwidth 655 resouce reserved from the same link, and at each node QoS policy per 656 AII (e.g, traffic shaper per slice) should be used to ensure that the 657 traffic between different slices is isolated and does not affect each 658 other. 660 7.2. L2 Link Resource AII Configuration 662 [RFC8668] described how to encode adjacency-SID for each L2 member 663 link of an L3 parent link. In the network slicing scenario, it is 664 beneficial to deploy LAG or another virtual aggregation interface 665 between two nodes. If that, the dedicated link resources belong to 666 different virtual networks could be added or removed on demand, they 667 are treated as L2 member links of a single L3 virtual interface. It 668 is the single L3 virtual interface which needs to occupy IP resource 669 and join the IGP instance. Creating a new slice-specific link on 670 demand or removing the old one is likely to affect little 671 configurations. 673 For network slicing purpose, [RFC8668] need to be extended to 674 advertise the AII attribute for each L2 member link. In practice, 675 for hard isolation purpose, different L2 member link of the same L3 676 parent link is SUGGESTED to be configured to belong to different 677 single AII, with different adjacency-SID. Note that in this case, 678 the L3 parent link belongs to default AII(0) (i.e, for this L3 link 679 it is not necessary to allocate adjacency-SID per AII any more), but 680 each L2 member link belongs to the specific non-default AII as well 681 as the shared default AII. An L2 member link maybe a Flex-E channel 682 or ODUK tunnel created/destroyed on demand. 684 In practice, for hard isolation purpose, different L2 member link of 685 the same L3 parent link SUGGESTED to be configured to belong to 686 different AII, with different adjacency-SID. Note that in this case, 687 the L3 parent link belongs to default AII(0), but each L2 member link 688 belongs to the specific non-default AII. An L2 member link maybe a 689 Flex-E channel or ODUK tunnel created/destroyed on demand. 691 In the control plane, routing protocol packets following the L3 692 parent link will select the L2 member link with the highest priority. 694 In the forwarding plane, data packets that belong to the specific 695 virtual network will pass along the L2 member link with the specific 696 AII value. 698 TE path computation based on link-state database need inspect the 699 detailed L2 members of an L3 adjacency to select the expected L2 link 700 resource. 702 7.3. Node Resource AII Configuration 704 For topology resource, each node needs to allocate node-SID per AII 705 when it joins the related virtual network. All nodes in the IGP 706 domain can run the CSPF algorithm with criteria to compute SR-BE path to any other destination nodes for an 708 AII-specific virtual network based on the link-state database that 709 containing AII information, so that SR-BE FIB can be constructed for 710 each AII. Static routes could also be added to the AII-specific FIB. 712 An intra-domain overlay best-effort service belongs to an AII 713 specific virtual network could be directly over the SR-BE path within 714 that VN. 716 An inter-domain overlay best-effort service belongs to an AII 717 specific virtual network could be over a path containing a single 718 destination node-SID or a segment list containing domain border node- 719 SID and destination node-SID within that VN. 721 7.4. Service Function Resource AII Configuration 723 [I-D.ietf-spring-sr-service-programming] introduces the notion of 724 service segments, and describes how to implement service segments and 725 achieve stateless service programming in SR-MPLS and SRv6 networks. 726 The ability of encoding the service segments along with the 727 topological segment enables service providers to forward packets 728 along a specific network path and through VNFs or physical service 729 appliances available in the network. Typically, a Service Function 730 may be any purposeful execution for the packet, such as DPI, 731 firewall, NAT, etc. 733 The Service Function is independent of topology, it can also be 734 instantiated per AII, each with different priority to be executed or 735 scheduled. For example, a docker container including specific 736 Service Funciton process can be generated or destroyed on demand 737 according to the life-cycle of a particular slice. It will have a 738 particular CPU scheduling priority. 740 At a node, multiple instance of the same type of Service Function for 741 different slice will allocate different Service SID and advertise to 742 other nodes. 744 8. E2E Slicing with Centralized Mode 746 [RFC7752] BGP-LS describes the methodology that using BGP protocol to 747 transfer the Link-State information that maybe originated from IGP 748 instance (for intra-domain topology information) or from local direct 749 interface or static configuration(for inter-domain topology 750 information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also 751 describes a method to firstly put inter-domain interconnections to 752 IGP instance, then always import data from IGP protocol source to 753 BGP-LS. In any case BGP-LS need extend to transfer the Link-State 754 data with AII information. 756 An E2E inner-AS SR-TE instance with particular color template could 757 be initiated on PE1, PE1 is head-end and PE2 is destination node. 758 BGP-LS could be used to inform the SDN controller about the underlay 759 network topology information including AII attribute. Thus the 760 controller could calculate E2E TE path within the particular virtual 761 network. Especially an AII specific Adacency-SID of inter-domain 762 link can be included in the E2E SID list. 764 9. E2E Slicing with Distributed Mode 766 In some deployments, especially the network evolution from seamless 767 MPLS in practice, operators adopt BGP-LU to build inter-domain MPLS 768 LSP, and overlay service will be directly over BGP-LU LSP. 770 In this case, the network is divided into some domains and each 771 domain will run its own IGP process. These IGP process are isolated 772 to each other to be simple. That means it is inconvenient to realize 773 network slicing depending on IGP itself with inter-area route leak or 774 redistribution. 776 For an E2E BGP-LU LSP, if overlay service has TE requirements that 777 defined by a color, the BGP-LU LSP need also have a sense of color, 778 i.e., BGP-LU label could be allocated per color. 780 At entry node of each domain, BGP-LU LSP generated for specific color 781 will be over intra-domain SR-TE or SR-BE path generated for that 782 color again. At exit node of each domain, BGP-LU LSP generated for 783 specific color will select inter-domain forwarding resource per 784 color. Especially, an ASBR will select slice-specfic inter-AS link 785 according to AII information of color template. 787 [RFC7911] defined that multiple paths UPDATE message for the same 788 destination prefix can be advertised in BGP, each UPDATE can contain 789 the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with 790 different color value. That is a simple existing way to realize BGP- 791 LU color function, with needless new BGP extensions. 793 10. Combined with SR Flex-algorithm for Stack Depth Optimization 795 [I-D.ietf-lsr-flex-algo] introduced a mechanism to do segment stack 796 depth optimization for an SR policy in IGP domain part. As the color 797 of SR policy defined a TE purpose, traditionally the headend or SDN 798 controller will compute an expected TE path to meet that purpose. 800 It is necessary to map a color (32 bits) to an FA-id (8 bits) when SR 801 flex-algorithm enabled for an SR policy. Besides that, it is 802 necessary to enable the FA-id on each node that wants to join the 803 same FA plane manually. The FAD could copy the TE constraints (not 804 including bandwidth case) contained in the color template. 806 We need to consider the cost of losing the flexibility of color when 807 executing the flex-algo optimization, and also consider the gap 808 between P2P TE requirements and MP2P SR FA LSP capability, to reach 809 the right balance when deciding which SR policy need optimization. 811 10.1. Flex-algo Using AII Criteria 813 Because the first feature of AII is a TE criteria of link and node, 814 it could be served as a parameter of Flex-algo Definition. 815 [I-D.peng-lsr-flex-algo-opt-slicing] described how to extend IGP 816 Flex-algo to compute constraint based paths over the AII specific 817 network slice. 819 10.2. Best-effort Color Template Mapping to Flex-algo 821 As described above, for best-effort service within an AII specific 822 virtual network, we have already constructed SR-BE FIB tables per 823 AII, that is mostly like Flex-algo. Thus, it is not necessary to map 824 to FA-id again for a color template which has defined a best-effort 825 behavior within an AII specific virtual network. Of course, if 826 someone forced to remap it, there is no downside for the operation, 827 the overlay best-effort service (with a color which defined specific 828 AII, best-effort requirement, and mapping FA-id) in IGP domain will 829 try to recurse over or FIB entry. 831 10.3. Traffic Engineering Color Template Mapping to Flex-algo 833 An SR-TE tunnel/policy that served for traffic engineering service of 834 an AII speficif virtual network was generated and computed according 835 to the relevant color template, which contained specific AII and some 836 other traditional TE constraints. If we config mapping FA-id under 837 the color template, the SR-TE tunnel/policy instance will inherit 838 forwarding information from corresponding SR Flex-Algo FIB entry. If 839 we config merging FA-id under the color template, the SR-TE tunnel/ 840 policy instance will have a TE path within Flex-algo plane. 842 11. Network Slicing Examples 844 In this section, we will further illustrate the point through some 845 examples. All examples share the same figure below. 847 .-----. .-----. 848 ( ) ( ) 849 .--( )--. .--( )--. 850 +---+----link A1----+---+ +---+----link A1----+---+ 851 |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2| 852 | |----link B1----| |---link B1---| |----link B1----| | 853 +---+----link B2----+---+ +---+----link B2----+---+ 854 ( ) ( ) 855 '--( AS1 )--' '--( AS2 )--' 856 ( ) ( ) 857 '-----' '-----' 859 Figure 2 Network Slicing via AII 861 Suppose that each link belongs to separate virtual network, e.g., 862 link Ax belongs to the virtual network colored by AII A, link Bx 863 belongs to the virtual network colored by AII B. link x1 has an IGP 864 metric smaller than link x2, but TE metric lager. 866 To simplify the use case, each AS just contained a single IGP area. 868 11.1. Intra-domain Network Slicing Example 870 11.1.1. Best-effort Service over Network Slice Example 872 From the perspective of node PE1 in AS1, it will calculate best- 873 effort forwarding entry for each AII instance (including default AII) 874 to destinations in the same IGP area. For example: 876 For entry, forwarding information could be 877 ECMP during link A1 and link B1, with destination node-SID 100 for 878 . 880 For entry, forwarding information could be 881 link A1, with destination node-SID 200 for . 884 For entry, forwarding information could be 885 link B1, with destination node-SID 300 for . 888 11.1.2. TE Service over Network Slice Example 890 It could also initiate an SR-TE instance (SR tunnel or SR policy) 891 with the particular color template on PE1, PE1 is headend and ASBR1 892 is destination node. For example: 894 For SR-TE instance 1 with color template which defined criteria 895 including {default AII, min TE metric}, forwarding information could 896 be ECMP during two segment list {adjacency-SID 1002 for @PE1} and {adjacency-SID 1004 for @PE1}. 899 For SR-TE instance 2 with the color template which defined criteria 900 including {AII=A, min TE metric}, forwarding information could be 901 presented as the segment list {adjacency-SID 2002 for @PE1}. 904 For SR-TE instance 3 with the color template which defined criteria 905 including {AII=B, min TE metric}, forwarding information could be 906 presented as the segment list {adjacency-SID 3004 for @PE1}. 909 11.1.3. TE Service over Network Slice with Flex-algo Example 911 Furthermore, we can use SR Flex-algo to optimize the above SR-TE 912 instance. For example, for SR-TE instance 1, we can define FA-ID 201 913 with FAD that contains the same information as the color template, in 914 turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3. 915 Note that each FA-ID also needs to be enabled on ASBR1. So that the 916 corresponding SR FA entry could be: 918 For entry, forwarding information 919 could be ECMP during link A2 and link B2, with destination node-SID 920 600 for . 922 For entry, forwarding information 923 could be link A2, with destination node-SID 700 for . 926 For entry, forwarding information 927 could be link B2, with destination node-SID 800 for . 930 11.2. Inter-domain Network Slicing via BGP-LS Example 932 11.2.1. Best-effort Service Example 934 For SR-TE instance 4 with color template which defined criteria 935 including {default AII, min IGP metric}, forwarding information could 936 be segment list {node-SID 100 for , 937 adjacency-SID 1001 for @ASBR1, node-SID 400 for 938 }. 940 For SR-TE instance 5 with color template which defined criteria 941 including {AII=A, min IGP metric}, forwarding information could be 942 segment list {node-SID 200 for , 943 adjacency-SID 1001 for @ASBR1, node-SID 500 for 944 }. 946 For SR-TE instance 6 with color template which defined criteria 947 including {AII=B, min IGP metric}, forwarding information could be 948 segment list {node-SID 300 for , 949 adjacency-SID 1003 for @ASBR1, node-SID 600 for 950 }. 952 11.2.2. TE Service Example 954 For SR-TE instance 7 with color template which defined criteria 955 including {default AII, min TE metric}, forwarding information could 956 be ECMP during two segment list {adjacency-SID 1002 for @PE1, adjacency-SID 1001 for @ASBR1, adjacency- 958 SID 1002 for @ASBR2} and {adjacency-SID 1004 for 959 @PE1, adjacency-SID 1003 for 960 @ASBR1, adjacency-SID 1004 for @ASBR2}. 962 For SR-TE instance 8 with color template which defined criteria 963 including {AII=A, min TE metric}, forwarding information could be 964 segment list {adjacency-SID 2002 for @PE1, 965 adjacency-SID 2001 for @ASBR1, adjacency-SID 2002 966 for @ASBR2}. 968 For SR-TE instance 9 with color template which defined criteria 969 including {AII=B, min TE metric}, forwarding information could be 970 segment list {adjacency-SID 3004 for @PE1, 971 adjacency-SID 3003 for @ASBR1, adjacency-SID 3004 972 for @ASBR2}. 974 11.2.3. TE Service Using Flex-algo Example 976 For TE service, if we use SR Flex-algo to do optimizaztion, the above 977 forwarding information of each TE instance could inherit the 978 corresponding SR FA entry, it would look like this: 980 For SR-TE instance 7, forwarding information could be ECMP during two 981 segment list {node-SID 600 for , 982 adjacency-SID 1001 for @ASBR1, node-SID 600 for } and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency- 985 SID 1004 for @ASBR2}. 987 For SR-TE instance 8 with color template which defined criteria 988 including {AII=A, min TE metric}, forwarding information could be 989 segment list {node-SID 700 for , 990 adjacency-SID 2001 for @ASBR1, node-SID 700 for }. 993 For SR-TE instance 9 with color template which defined criteria 994 including {AII=B, min TE metric}, forwarding information could be 995 segment list {node-SID 800 for , 996 adjacency-SID 3003 for @ASBR1, node-SID 800 for }. 999 11.3. Inter-domain Network Slicing via BGP-LU Example 1001 In figure 1, PE2 can allocate and advertise six labels for its 1002 loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1 1003 defines {default AII, min IGP metric}, color 2 defines {AII=A, min 1004 IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4 1005 defines {default AII, min TE metric}, color 5 defines {AII=A, min TE 1006 metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise 1007 these labels to ASBR2 and ASBR2 then continues to allocate six labels 1008 each for prefix PE2 plus different color. Other nodes will have the 1009 same operation. Ultimately PE1 will maintain six BGP-LU LSP. 1011 For example, the BGP-LU LSP for color 1 will be over SR best-effort 1012 FIB entry node-SID 100 for to pass through 1013 AS1, over adjacency-SID 1001 for @ASBR1 to pass 1014 inter-AS, over SR best-effort FIB entry node-SID 400 for to pass through AS2. 1017 For example, The BGP-LU LSP for color 4 will over SR-TE instance 1 1018 (see section 10.1.2), or SR best-effort FIB entry node-SID 600 for 1019 (see section 10.1.3) to pass through 1020 AS1, over adjacency-SID 1001 for @ASBR1 to pass 1021 inter-AS, over SR-TE instance 1' or corresponding SR FA entry to pass 1022 through AS2. Note that ASBR1 need also understand the meaning of a 1023 specific color and select forwarding resource between two AS. 1025 12. Implementation Suggestions 1027 The implementation cost is low by means of existing segment routing 1028 infrastructure. 1030 12.1. SR-MPLS 1032 As a node often contains control plane and forwarding plane, a 1033 suggestion is that only default AII specific FTN table, i.e, 1034 traditional FTN table, need be installed on forwarding plane, so that 1035 there are not any modification and upgrade requirement for hardware 1036 and existing MPLS forwarding mechanism. FTN entry for non-default 1037 AII instance will only be maintained on the control plane and be used 1038 for overlay service iteration according to next-hop plus color (color 1039 will give AII information and mapping FA-id information). Note that 1040 ILM entry for all AII need be installed on forwarding plane, that 1041 does not bring any confusion because of prefix-SID allocation per 1042 AII. 1044 SR NHLFE entry and other iteration entry such as 1045 can contain AII information for expected packet scheduling. It is 1046 recommended that QoS policy per AII should be maintained in the 1047 underlay network. The Slice Type value of AII can distinguish flows 1048 by coarse-grained classification, while the Instance value of AII can 1049 be used for more scheduling policy. 1051 12.2. SRv6 1053 For SRv6 case, IPv6 address resource is directly used to represent 1054 SID, so that different IPv6 block could be allocated to different 1055 slice. There are two possible ways to advertise slice specfic IPv6 1056 block: 1058 o Traditional prefix reachability, but only for default AII (0) 1059 specific IPv6 block. 1061 o New SRv6 Locator advertisement, for nonzero AII specific IPv6 1062 block. 1064 Forwarding entries for the default AII specific locators advertised 1065 in prefix reachability MUST be installed in the forwarding plane of 1066 receiving routers. 1068 Forwarding entries for the nonzero AII specific locators advertised 1069 in the SRv6 Locator MUST be also installed in the forwarding plane of 1070 receiving SRv6 capable routers when the associated AII is supported 1071 by the receiving node. 1073 The entries of both the above two cases SHOULD be installed in the 1074 unified FIB table, i.e., a single FIB table for default AII, because 1075 different IPv6 block is allocated to different slice. Instead, more 1076 FIB tables created for each VN in dataplane will bring comlexity for 1077 overlay service iteration, that is why MTR has no practical 1078 deployment. 1080 The forwarding information of FIB entry can contain AII information 1081 for expected packet scheduling. 1083 13. IANA Considerations 1085 This document requests IANA to create a new top-level registry called 1086 "Network Slicing Parameters". This registry is being defined to 1087 serve as a top-level registry for keeping all other Network Slicing 1088 sub-registries. 1090 Additionally, a new sub-registry "AII (TN-slice Identifier) 1091 codepoint" is to be created under top-level "Network Slicing 1092 Parameters" registry. This sub-registry maintains 32-bit identifiers 1093 and has the following registrations: 1095 +============+======================================================+ 1096 | Slice Type | Instance | Description | 1097 |(High 8bits)| (Low 24bits) | | 1098 +============+==============+=======================================+ 1099 | | 0 | Reservered for Default Slice: the | 1100 | 0(Normal) | | original physical network. | 1101 |endogenous: +--------------+---------------------------------------+ 1102 | IGP-metric | nonzero | Normal Slice, for user defined. | 1103 +------------+--------------+---------------------------------------+ 1104 | | 0 | Resevered. | 1105 | 1(uRLLC) +--------------+---------------------------------------+ 1106 |endogenous: | | Slice suitable for the handling of | 1107 | delay | nonzero | ultra- reliable low latency | 1108 | | | communications, for user defined. | 1109 +------------+--------------+---------------------------------------+ 1110 | 2(TE) | 0 | Resevered. | 1111 |endogenous: +--------------+---------------------------------------+ 1112 | TE-metric | nonzero | General TE Slice, for user defined. | 1113 +------------+--------------+---------------------------------------+ 1114 | | 0 | Resevered. | 1115 | 3(eMBB) +--------------+---------------------------------------+ 1116 |endogenous: | | Slice suitable for the handling of 5G | 1117 | TBD | nonzero | enhanced Mobile Broadband, for user | 1118 | | | defined. | 1119 +------------+--------------+---------------------------------------+ 1120 | | 0 | Resevered. | 1121 | 4(MIoT) +--------------+---------------------------------------+ 1122 |endogenous: | nonzero | Slice suitable for the handling of | 1123 | TBD | | massive IoT, for user defined. | 1124 +------------+--------------+---------------------------------------+ 1125 | | 0 | Resevered. | 1126 | 5(V2X) +--------------+---------------------------------------+ 1127 |endogenous: | nonzero | Slice suitable for the handling of | 1128 | TBD | | V2X services, for user defined. | 1129 +------------+--------------+---------------------------------------+ 1130 | 6-255 | any | Unassigned. | 1131 +------------+--------------+---------------------------------------+ 1133 Table 1. AII Codepoint 1135 14. Security Considerations 1137 TBD. 1139 15. Acknowledgements 1141 TBD. 1143 16. Normative references 1145 [I-D.ali-spring-network-slicing-building-blocks] 1146 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1147 "Building blocks for Slicing in Segment Routing Network", 1148 draft-ali-spring-network-slicing-building-blocks-02 (work 1149 in progress), November 2019. 1151 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 1152 Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS 1153 Extension for Inter-AS Topology Retrieval", draft-ietf- 1154 idr-bgpls-inter-as-topology-ext-09 (work in progress), 1155 September 2020. 1157 [I-D.ietf-idr-tunnel-encaps] 1158 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 1159 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 1160 encaps-19 (work in progress), September 2020. 1162 [I-D.ietf-lsr-flex-algo] 1163 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1164 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1165 algo-12 (work in progress), October 2020. 1167 [I-D.ietf-spring-segment-routing-policy] 1168 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1169 P. Mattes, "Segment Routing Policy Architecture", draft- 1170 ietf-spring-segment-routing-policy-08 (work in progress), 1171 July 2020. 1173 [I-D.ietf-spring-sr-service-programming] 1174 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1175 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1176 Henderickx, W., and S. Salsano, "Service Programming with 1177 Segment Routing", draft-ietf-spring-sr-service- 1178 programming-03 (work in progress), September 2020. 1180 [I-D.nsdt-teas-transport-slice-definition] 1181 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1182 Tantsura, "IETF Definition of Transport Slice", draft- 1183 nsdt-teas-transport-slice-definition-04 (work in 1184 progress), September 2020. 1186 [I-D.peng-lsr-flex-algo-opt-slicing] 1187 Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm 1188 Optimazition for Netwrok Slicing", draft-peng-lsr-flex- 1189 algo-opt-slicing-02 (work in progress), September 2020. 1191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1192 Requirement Levels", BCP 14, RFC 2119, 1193 DOI 10.17487/RFC2119, March 1997, 1194 . 1196 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1197 (TE) Extensions to OSPF Version 2", RFC 3630, 1198 DOI 10.17487/RFC3630, September 2003, 1199 . 1201 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1202 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1203 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1204 . 1206 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1207 Topology (MT) Routing in Intermediate System to 1208 Intermediate Systems (IS-ISs)", RFC 5120, 1209 DOI 10.17487/RFC5120, February 2008, 1210 . 1212 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1213 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1214 2008, . 1216 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 1217 "Traffic Engineering Extensions to OSPF Version 3", 1218 RFC 5329, DOI 10.17487/RFC5329, September 2008, 1219 . 1221 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1222 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1223 . 1225 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 1226 Traffic Engineering (MPLS-TE)", RFC 7308, 1227 DOI 10.17487/RFC7308, July 2014, 1228 . 1230 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1231 S. Ray, "North-Bound Distribution of Link-State and 1232 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1233 DOI 10.17487/RFC7752, March 2016, 1234 . 1236 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1237 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1238 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1239 . 1241 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1242 "Advertisement of Multiple Paths in BGP", RFC 7911, 1243 DOI 10.17487/RFC7911, July 2016, 1244 . 1246 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 1247 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 1248 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 1249 December 2019, . 1251 Authors' Addresses 1253 Shaofu Peng 1254 ZTE Corporation 1256 Email: peng.shaofu@zte.com.cn 1258 Ran Chen 1259 ZTE Corporation 1261 Email: chen.ran@zte.com.cn 1263 Gregory Mirsky 1264 ZTE Corporation 1266 Email: gregimirsky@gmail.com 1268 Fengwei Qin 1269 China Mobile 1271 Email: qinfengwei@chinamobile.com