idnits 2.17.1 draft-peng-teas-network-slicing-02.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 == 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: For P2P traffic engineering service, 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 could consist of pure adjacency-SID per AII specific. The segment list could be computed by headend or SDN controller. The head-end of the segment list maintains the corresponding SR-TE tunnel or SR policy. -- The document date (December 17, 2019) is 1591 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: 'RFC2119' is defined on line 1035, 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-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-01 == Outdated reference: A later version (-02) exists of draft-peng-lsr-flex-algo-opt-slicing-00 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 10 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: June 19, 2020 ZTE Corporation 6 Fengwei. Qin 7 China Mobile 8 December 17, 2019 10 Packet Network Slicing using Segment Routing 11 draft-peng-teas-network-slicing-02 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 June 19, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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. Network Slicing Requirements . . . . . . . . . . . . . . . . 3 59 2.1. Dedicated Virtual Networks . . . . . . . . . . . . . . . 3 60 2.2. End-to-End Slicing . . . . . . . . . . . . . . . . . . . 4 61 2.3. Unified NSI . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 63 2.5. Summarized Requirements . . . . . . . . . . . . . . . . . 5 64 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 65 4. Overview of Existing Identifiers . . . . . . . . . . . . . . 5 66 4.1. AG and EAG Bit . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Multi-Topology Identifier . . . . . . . . . . . . . . . . 6 68 4.3. SR Policy Color . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. Flex-algorithm Identifier . . . . . . . . . . . . . . . . 7 70 4.5. New Slice-based Identifier Introduced . . . . . . . . . . 7 71 5. Overview of AII-based Mechanism . . . . . . . . . . . . . . . 8 72 5.1. Physical Network Partition by AII . . . . . . . . . . . . 8 73 5.2. Path within AII specific Slice . . . . . . . . . . . . . 9 74 5.2.1. SR-BE Path within AII specific Slice . . . . . . . . 9 75 5.2.2. SR-TE Path within AII specific Slice . . . . . . . . 10 76 5.3. Traffic Steering to SR policy within Slice . . . . . . . 10 77 5.4. Simple Variant of AII-based Slicing Scheme . . . . . . . 10 78 6. Resource Allocation per AII . . . . . . . . . . . . . . . . . 11 79 6.1. L3 Link Resource AII Configuration . . . . . . . . . . . 11 80 6.2. L2 Link Resource AII Configuration . . . . . . . . . . . 11 81 6.3. Node Resource AII Configuration . . . . . . . . . . . . . 12 82 6.4. Service Function Resource AII Configuration . . . . . . . 12 83 7. E2E Slicing with Centralized Mode . . . . . . . . . . . . . . 13 84 8. E2E Slicing with Distributed Mode . . . . . . . . . . . . . . 13 85 9. Combined with SR Flex-algorithm for Stack Depth Optimization 14 86 9.1. Flex-algo Using AII Criteria . . . . . . . . . . . . . . 14 87 9.2. Best-effort Color Template Mapping to Flex-algo . . . . . 14 88 9.3. Traffic Engineering Color Template Mapping to Flex-algo . 15 89 10. Network Slicing Examples . . . . . . . . . . . . . . . . . . 15 90 10.1. Intra-domain Network Slicing Example . . . . . . . . . . 16 91 10.1.1. Best-effort Service over Network Slice Example . . . 16 92 10.1.2. TE Service over Network Slice Example . . . . . . . 16 93 10.1.3. TE Service over Network Slice with Flex-algo Example 16 94 10.2. Inter-domain Network Slicing via BGP-LS Example . . . . 17 95 10.2.1. Best-effort Service Example . . . . . . . . . . . . 17 96 10.2.2. TE Service Example . . . . . . . . . . . . . . . . . 17 97 10.2.3. TE Service Using Flex-algo Example . . . . . . . . . 18 98 10.3. Inter-domain Network Slicing via BGP-LU Example . . . . 18 99 11. Implementation Suggestions . . . . . . . . . . . . . . . . . 19 100 11.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . 19 101 11.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 105 15. Normative references . . . . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 108 1. Introduction 110 According to 5G context, network slicing is the collection of a set 111 of technologies to create specialized, dedicated logical networks as 112 a service (NaaS) in support of network service differentiation and 113 meeting the diversified requirements from vertical industries. 114 Through the flexible and customized design of functions, isolation 115 mechanisms, and operation and management (O&M) tools, network slicing 116 is capable of providing dedicated virtual networks over a shared 117 infrastructure. A Network Slice Instance (NSI) is the realization of 118 network slicing concept. It is an E2E logical network, which 119 comprises of a group of network functions, resources, and connection 120 relationships. An NSI typically covers multiple technical domains, 121 which include a terminal, access network (AN), transport network (TN) 122 and a core network (CN), as well as a DC domain that hosts third- 123 party applications from vertical industries. Different NSIs may have 124 different network functions and resources. They may also share some 125 of the network functions and resources. 127 For a transport network, network slicing requires the underlying 128 network to support partitioning of the network resources to provide 129 the client with dedicated (private) networking, computing, and 130 storage resources drawn from a shared pool. The slices may be seen 131 as virtual networks. 133 2. Network Slicing Requirements 135 2.1. Dedicated Virtual Networks 137 An end-to-end virtual network with dedicated resources is the 138 advantage of network slicing than traditional DiffServ QoS and VPN. 139 For example, DiffServ QoS can distinguish VoIP traffic and other type 140 of traffic (such as high-definition video, web browsing), but can not 141 distinguish the same type of traffic from different tenants, nor 142 isolation of these traffic at all. 144 Another example is the IoT traffic of health monitoring network which 145 connected hospital and outpatient, it always has strict privacy and 146 safety requirements, including where the data can be stored and who 147 can access the data, all this can not be satisfied by DiffServ QoS as 148 it has not any function of network computing and storage. 150 Dedicated VN is a distinct object purchased by a customer, and it 151 provides specific function with predictable performance, guaranteed 152 level of isolation and safety. It is not just as QoS. 154 2.2. End-to-End Slicing 156 Only an end-to-end slice and fine-grained network can match ultra 157 delay and safety requirements of special service. End-to-end means 158 that it is constructed with AN-slice, TN-slice, and CN-slice part. 160 Although 3GPP technical specifications mainly focus on the operation 161 and management of AN-slice and CN-slice, which include some NF 162 (network function) components, TN-slice is also created and destroyed 163 according to the related NSI lifecycle. In fact, the 3GPP management 164 system will request expected link requirements related to the network 165 slice (e.g., topology, QOS parameters) with the help of the 166 management system that handles the TN part related to the slice. 168 For TN part, the link requirements are independent of the existing 169 domain partition of the network, i.e., any intra- or inter-domain 170 link is the candidate resource for the slice. It is also independent 171 of the existing underlay frame or routing technologies (IGP, BGP, 172 Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the 173 candidate resource. 175 2.3. Unified NSI 177 An NSI is indentified by S-NSSAI (Single Network Slice Selection 178 Assistance Information), which is allocated per PDU session and has 179 semantic global within the AN and CN. 181 For the purpose of operation and management simplicity, it is also 182 better to have a unified identifier with semantic global to 183 distinguish different TN-slice during the whole TN. TN-slice 184 identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n. 186 Instead, using different slice identifier across multi-domain of TN 187 for the specific TN-slice will introduce much and unnecessary 188 complexity, especially for case two devices belongs to different 189 domain try to exchange slice-based information directly, without the 190 help of SDN controller to translate the unified TN-slice identifier 191 to an individual domain-wide indentifier. 193 2.4. Traffic Engineering 195 5G system is expected to be able to provide optimized support for a 196 variety of different communication services, different traffic loads, 197 and different end-user communities. For example, the communication 198 services using network slicing may include: vehicle-to-everything 199 (V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service 200 with FMC (fixed-mobile convergence), massive IoT connections. Among 201 these service types, high data rates, high traffic densities, low- 202 latency, high-reliability are highlighted requirements. 204 Traffic engineering mechanism in TN must support the above 205 requirements, bandwidth and delay are two primary TE constraints. 207 2.5. Summarized Requirements 209 In summary, the following requirements would be satisfied: 211 REQ1: Provide a distinct virtual network, including dedicated 212 topology, computation, and storage resource, not only traditional 213 QoS; 215 REQ2: Unified NSI for easy operation and maintenance; 217 REQ3: E2E network slicing, including both intra-domain and inter- 218 domain case; 220 REQ4: Customization resource for QoS purpose, bandwidth and delay are 221 basic constraints; 223 REQ5: Layer 2 as well as Layer 3 link resource partition; 225 3. Conventions Used in This Document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC2119. 231 4. Overview of Existing Identifiers 233 Currently there are multiple existing mature identifiers that could 234 be used to identify the virtual network resource in the transport 235 network, such as: 237 o Administrative Group (AG) described in [RFC3630], [RFC5329], 238 [RFC5305] and Extended Administrative Groups (EAGs) described in 239 [RFC7308] 241 o Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915], 242 [RFC5340] 244 o SR policy color described in 245 [I-D.ietf-spring-segment-routing-policy] 247 o FA-id described in [I-D.ietf-lsr-flex-algo] 249 However, all these identifiers are not sufficient to meet the above 250 requirements of TN-slice. Note that all these identifiers have use 251 case of their own, besides the network slicing use case. Next, we 252 will discuss each of them to determine their matching of slicing 253 requirements. 255 4.1. AG and EAG Bit 257 AG and EAG are limited to serve as a link color scheme used in TE 258 path computation to meet the requirements of TE service for a tenant. 259 It is difficult to use them for an NSI allocation mapping (assuming 260 that each bit position of AG/EAG represents an NSI). Hence, they do 261 not meet REQ1. At the same time, AG or EAG cannot be a FIB 262 identifier for best-effort service for the same tenant. 264 AG and EAG are only as L3 link attribute, not appropriate for 265 L2-bundles member, i.e., not meeting REQ5. 267 Note that AG and EAG have semantic global, so they meet REQ2,3. 269 4.2. Multi-Topology Identifier 271 MTR is limited to serve as an IGP logical topology scheme only used 272 in the intra-domain scenario. Thus it is challenging to select 273 inter-area link resources based on MT-ID when E2E inter-domain TE 274 path needs to be created for a tenant. That is, it does not meet 275 REQ3. 277 Different IGP domain within the same TN-slice may be configured with 278 different MT-ID. Thus MT-ID does not meet REQ2. 280 MT-ID is only as L3 link attribute, not appropriate for L2-bundles 281 member, so it does not meet REQ5. 283 4.3. SR Policy Color 285 The color of SR policy defines a TE purpose, which includes a set of 286 constraints such as bandwidth, delay, TE metric, etc. Therefore 287 color is an abstract target, and it is difficult to get a distinct 288 virtual network according to a specific color value. In most cases, 289 only the headend and some other border nodes need to maintain the 290 color template, and a color-based virtual network is hard to present 291 because of too few participants and lack of interaction scheme. That 292 is, the color does not meet REQ1. 294 We can continue to define TE affinity information in color-template, 295 but that is only appropriate for L3 link, not for L2-bundles member, 296 so the color does not meet REQ5. 298 Note that the color has global semantic, so it meets REQ3. 300 4.4. Flex-algorithm Identifier 302 Indeed, FA-id is a short mapping of SR policy color, and it may 303 inherit the matched-degree of the Policy Color. However, FA-id has 304 its own characteristics. A specific FA-id can have more distributed 305 participants and define explicit link resource so that an explicit FA 306 plane can be created. Unfortunately, different best-effort and TE 307 service of the same slice-tenant will define different constraints, 308 resulting in the need to occupy more FA-id resources for one slice- 309 tenant. The relationship between FA-id and slice is not clear. That 310 is, FA-id does not meet REQ1. 312 On the other hand, FA-id, like MT-ID, is limited to serve as an IGP 313 algorithm scheme used in the intra-domain scenario. It is 314 challenging to select inter-area (especially inter-AS) link resources 315 according to FA-id when the E2E inter-domain TE path needs to be 316 created for the tenant. So, FA-id does not meet REQ3. 318 Different IGP domain within the same TN-slice may configure different 319 FA-ids, so it does not meet REQ2. 321 What is more important, tha the path in FA plane identified by FA-id 322 is MP2P LSP, so it is hard to define bandwidth reservation for 323 service. So, FA-id does not meet REQ4. Unless each link is totally 324 dedicated to a single FA plane, i.e., link resources are not shared 325 among multiple FA plane. 327 The link include/exclude rules defined by FA-id is only appropriate 328 for the L3 link, not for L2-bundles member, so FA-id does not meet 329 REQ5. 331 4.5. New Slice-based Identifier Introduced 333 Thus, there needs to introduce a new characteristic of NSI that meets 334 the above-listed requirements to isolate underlay resources, and it 335 is a slice-based identifier. 337 Firstly, it could serve as TE criteria for TE service, this aspect is 338 like AG/EAG; and secondly, as a FIB table identifier for best-effort 339 service, this aspect is like MT-ID or FA-id. 341 This document introduces a new property of NSI called "Administrative 342 Instance Identifier" (AII) and corresponding method of how to 343 instantiate it in the underlay network to match the above-listed 344 requirements. 346 5. Overview of AII-based Mechanism 348 [I-D.ali-spring-network-slicing-building-blocks] described how SR 349 policy [I-D.ietf-spring-segment-routing-policy] can be used to create 350 service slice. This document continues to discuss AII-based 351 mechanism to enhance SR policy to support tenant slice as well as 352 service slice. It will signal the association of AII and shared 353 resources required to create and manage an NSI, and steer the packets 354 to the path within the specific NSI according to SR policy color. 356 SR policy color has semantic global in order to be conveniently 357 exchanged between two PE routers. They configure the same color 358 template information for the same color value. AII, also with global 359 semantic, can be contained in color template to enhance SR policy to 360 create a TE path within global TN-slice identified by AII. Besides 361 TE service served by explicit SR policy instance, best-effort service 362 is served by AII-specific FIB that is created by default once AII 363 configured. 365 The following is how AII-based mechanism works. 367 5.1. Physical Network Partition by AII 369 At the initial stage, each link in a physical network can be colored 370 to conform with network slicing requirements. As previously 371 mentioned, AII can be used to color links to partition underlay 372 resources. Also, we may continue to use AG or EAG to color links for 373 traditional TE within a virtual network specified by an AII. A 374 single or multiple AIIs could be configured on each intra-domain or 375 inter-domain link regardless of IGP instance configuration. At the 376 minimum, a link always belongs to default AII (the value is 0). The 377 number of AIIs configured on a node's links determines the number of 378 virtual networks the node belongs to. 380 The extension of the existing IGP-TE mechanisms [RFC3630] and 381 [RFC5305] to distribute AII information in an AS as a new TE 382 parameter of a link will be defined in another document. 384 An SDN controller, using BGP-LS [RFC7752] or another interface, will 385 have a distinct view of each virtual network specified by AII. The 386 extension of BGP-LS will also be defined in another document. 388 5.2. Path within AII specific Slice 390 Using the CSPF algorithm, a TE path for any best-effort (BE) or 391 traffic-engineered (TE) service can be calculated within a virtual 392 network specified by the AII. The computation criteria could be 393 or for the BE 394 and TE respectively. Combined with segment routing, the TE path 395 could be represented as: 397 o a single node-SID of the destination node, for the best-effort 398 service in the domain; 400 o node-SIDs of the border node and the destination node, adjacency- 401 SID of inter-domain link, for the inter-domain best-effort 402 service; 404 o an explicit adjacency-SID list or compressed with several loose 405 node-SID, for P2P traffic engineered service. 407 5.2.1. SR-BE Path within AII specific Slice 409 Because packets of the best-effort service could be transported over 410 an MP2P LSP without congestion control, SR best-effort FIB for each 411 virtual network specified by AII to forward best-effort packets may 412 be created in the IGP domain. Thus, CSPF computation with criteria 413 is distributed on each node in the IGP domain. 414 That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the 415 distributed CSPF computation is triggered by AII. 417 Besides the best-effort service, SR best-effort FIB entry for 418 specific AII also provide an escape way for traffic engineering 419 service within the same slice when the expected TE purpose can not be 420 meet. 422 To distinguish forwarding behavior of different virtual networks, 423 prefix-SID need to be allocated per AII and advertised in the IGP 424 domain. 426 For inter-domain case, in addition to the destination node-SID, 427 several node-SIDs of the domain border node and adjacency-SID of 428 inter-domain link are also needed to construct the E2E segment list. 429 The segment list could be computed with the help of the SDN 430 controller, which needs to take account of AII information during the 431 computation. Even for best-effort service, the head-end has to 432 maintain the corresponding SR-TE tunnel or SR policy. 434 As same as the prefix-SID, adjacency-SID needs to be allocated per 435 AII to distinguish the forwarding behavior of different virtual 436 networks. 438 5.2.2. SR-TE Path within AII specific Slice 440 For P2P traffic engineering service, especially such as the ulra- 441 reliable low-latency communication service, it SHOULD not transfer 442 over an MP2P LSP to avoid the risk of traffic congestion. The 443 segment list could consist of pure adjacency-SID per AII specific. 444 The segment list could be computed by headend or SDN controller. The 445 head-end of the segment list maintains the corresponding SR-TE tunnel 446 or SR policy. 448 However, label stack depth of the segment list MAY be optimized at a 449 later time based on local policies. 451 5.3. Traffic Steering to SR policy within Slice 453 At this moment, we can steer traffic of overlay service to the above 454 SR best-effort FIB, SR-TE tunnel, or SR policy instance for the 455 specific virtual network. The overlay service could specify a color 456 for TE purposes. 458 For example, color 1000 means to say "I need 459 best-effort forwarding within AII 10 resource", color 1001 means 460 to say "I need traffic engineering 461 forwarding within AII 10 resource, and only using link with AG equal 462 to 0x1 to reach guarantee of not exceeding 10ms delay time". 464 Service with color 1000 will be steered to an SR best-effort FIB 465 entry, or an SR-TE tunnel/policy in case of inter-domain. 467 Service with color 1001 will be steered to an SR-TE tunnel/policy. 469 5.4. Simple Variant of AII-based Slicing Scheme 471 There is a simple variant of AII-based slicing scheme for initial 472 slicing requirement of service, where the SDN controller in 473 management partition the whole E2E network topology to multiple 474 strictly isolated VNs identified by AII in local, but let the 475 forwarding equipments be totally unware of that. 477 The overlay service is steered to the SR policy whose path is limited 478 within specific VN using a pure adjacency-segment list. 480 This variant need not introduce any complex virtual network 481 technologies to forwarding equipments, however only for limited 482 scenes. 484 6. Resource Allocation per AII 486 6.1. L3 Link Resource AII Configuration 488 In IGP domain, each numbered or unnumbered L3 link could be 489 configured with AII information and synchronized among IGP neighbors. 490 The IGP link-state database will contain L3 links with AII 491 information to support TE path computation taking account of AII 492 criteria. For a numbered L3 link, it could be represented as a tuple 493 494 , for unnumbered it could be . Each L3 link could be configured 496 to belong to a single AII or multiple AIIs. Note that an L3 link 497 always belongs to default AII(0). 499 For different tuple it would allocate a different 500 adjacency-SID, as well as advertising with different resource portion 501 such as bandwidth occupied. 503 Note that AII is independent of IGP instance. An L3 link that is not 504 part of the IGP domain, such as the special purpose for a static 505 route, or an inter-domain link, can also be configured with AII 506 information and allocate adjacency-SID per AII as the same as IGP 507 links. BGP-LS could be used to collect link state data with AII 508 information to the controller, BGP-LS has already provided a 509 mechanism to collect link state data from many source protocols, such 510 as IGP, Direct, Static configuration, etc., to cover network slicing 511 requirements. 513 6.2. L2 Link Resource AII Configuration 515 [I-D.ietf-isis-l2bundles] described how to encode adjacency-SID for 516 each L2 member link of an L3 parent link. In the network slicing 517 scenario, it is beneficial to deploy LAG or another virtual 518 aggregation interface between two nodes. If that, the dedicated link 519 resources belong to different virtual networks could be added or 520 removed on demand, they are treated as L2 member links of a single L3 521 virtual interface. It is the single L3 virtual interface which needs 522 to occupy IP resource and join the IGP instance. Creating a new 523 slice-specific link on demand or removing the old one is likely to 524 affect little configurations. 526 For network slicing purpose, [I-D.ietf-isis-l2bundles] need to be 527 extended to advertise the AII attribute for each L2 member link. For 528 different tuple it would allocate a different 529 adjacency-SID, as well as advertising with different resource portion 530 such as bandwidth occupied. 532 In practice, for hard isolation purpose, different L2 member link of 533 the same L3 parent link SUGGESTED to be configured to belong to 534 different AII, with different adjacency-SID. Note that in this case, 535 the L3 parent link belongs to default AII(0), but each L2 member link 536 belongs to the specific non-default AII. An L2 member link maybe a 537 Flex-E channel or ODUK tunnel created/destroyed on demand. 539 In the control plane, routing protocol packets following the L3 540 parent link will select the L2 member link with the highest priority. 542 In the forwarding plane, data packets that belong to the specific 543 virtual network will pass along the L2 member link with the specific 544 AII value. 546 TE path computation based on link-state database need inspect the 547 detailed L2 members of an L3 adjacency to select the expected L2 link 548 resource. 550 6.3. Node Resource AII Configuration 552 For topology resource, each node needs to allocate node-SID per AII 553 when it joins the related virtual network. All nodes in the IGP 554 domain can run the CSPF algorithm with criteria 555 to compute best-effort next-hop to any other destination nodes for a 556 virtual network AII-specific based on the link-state database that 557 containing AII information, so that SR best-effort FIB can be 558 constructed for each AII. Static routes could also be added to the 559 AII-specific FIB. 561 An intra-domain overlay best-effort service belongs to a virtual 562 network could be directly matched in the SR best-effort FIB for the 563 specific AII. 565 An inter-domain overlay best-effort service belongs to a virtual 566 network could be over a segment list containing domain border node- 567 SID and destination node-SID which could be matched in the SR best- 568 effort FIB for the specific AII. 570 6.4. Service Function Resource AII Configuration 572 [I-D.ietf-spring-sr-service-programming] introduces the notion of 573 service segments, and describes how to implement service segments and 574 achieve stateless service programming in SR-MPLS and SRv6 networks. 575 The ability of encoding the service segments along with the 576 topological segment enables service providers to forward packets 577 along a specific network path and through VNFs or physical service 578 appliances available in the network. Typically, a Service Function 579 may be any purposeful execution for the packet, such as DPI, 580 firewall, NAT, etc. 582 The Service Function is independent of topology, it can also be 583 instantiated per AII, each with different priority to be executed or 584 scheduled. For example, a docker container including specific 585 Service Funciton process can be generated or destroyed on demand 586 according to the life-cycle of a particular slice. It will have a 587 particular CPU scheduling priority. 589 At a node, multiple instance of the same type of Service Function for 590 different slice will allocate different Service SID and advertise to 591 other nodes. 593 7. E2E Slicing with Centralized Mode 595 [RFC7752] BGP-LS describes the methodology that using BGP protocol to 596 transfer the Link-State information that maybe originated from IGP 597 instance (for intra-domain topology information) or from local direct 598 interface or static configuration(for inter-domain topology 599 information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also 600 describes a method to firstly put inter-domain interconnections to 601 IGP instance, then always import data from IGP protocol source to 602 BGP-LS. In any case BGP-LS need extend to transfer the Link-State 603 data with AII information. 605 An E2E inner-AS SR-TE instance with particular color template could 606 be initiated on PE1, PE1 is head-end and PE2 is destination node. 607 BGP-LS could be used to inform the SDN controller about the underlay 608 network topology information including AII attribute. Thus the 609 controller could calculate E2E TE path within the particular virtual 610 network. Especially AII specific Adacency-SID of inter-domain link 611 is included in the E2E SID list. 613 8. E2E Slicing with Distributed Mode 615 In some deployments, especially the network evolution from seamless 616 MPLS in reality, operators adopt BGP-LU to build inter-domain MPLS 617 LSP, and overlay service will be directly over BGP-LU LSP. 619 In this case, the network is divided into some domains and each 620 domain will run its own IGP process. These IGP process are isolated 621 to each other to be simple. That means it is inconvenient to realize 622 network slicing depending on IGP itself with inter-area route leak or 623 redistribution. 625 For an E2E BGP-LU LSP, if overlay service has TE requirements that 626 defined by a color, the BGP-LU LSP need also have a sense of color, 627 i.e., BGP-LU label could be allocated per color. 629 At entry node of each domain, BGP-LU LSP generated for specific color 630 will be over intra-domain SR-TE or SR Best-effort path generated for 631 that color again. At exit node of each domain, BGP-LU LSP generated 632 for specific color will select inter-domain forwarding resource per 633 color. Especially, an ASBR will select slice-specfic inter-AS link 634 according to AII information of color template. 636 [RFC7911] defined that multiple paths UPDATE message for the same 637 destination prefix can be advertised in BGP, each UPDATE can contain 638 the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with 639 different color value. That is a simple existing way to realize BGP- 640 LU color function, with needless new BGP extensions. 642 9. Combined with SR Flex-algorithm for Stack Depth Optimization 644 [I-D.ietf-lsr-flex-algo] introduced a mechanism to do label stack 645 depth optimization for an SR policy in IGP domain part. As the color 646 of SR policy defined a TE purpose, traditionally the headend or SDN 647 controller will compute an expected TE path to meet that purpose. 649 It is necessary to map a color (32 bits) to an FA-id (8 bits) when SR 650 flex-algorithm enabled for an SR policy. Besides that, it is 651 necessary to enable the FA-id on each node that wants to join the 652 same FA plane manually. The FAD could copy the TE constraints (not 653 including bandwidth case) contained in the color template. 655 We need to consider the cost of losing the flexibility of color when 656 executing the flex-algo optimization, and also consider the gap 657 between P2P TE requirements and MP2P SR FA LSP capability, to reach 658 the right balance when deciding which SR policy need optimization. 660 9.1. Flex-algo Using AII Criteria 662 Because the first feature of AII is a TE criteria of link and node, 663 it could be served as a parameter of Flex-algo Definition. 664 [I-D.peng-lsr-flex-algo-opt-slicing] described how to extend IGP 665 Flex-algo to compute constraint based paths over the AII specific 666 network slice. 668 9.2. Best-effort Color Template Mapping to Flex-algo 670 As described above, for best-effort service we have already 671 constructed SR best-effort FIB per AII, that is mostly like Flex- 672 algo. Thus, it is not necessary to map to FA-id again for a color 673 template which has defined a best-effort behavior within the 674 dedicated AII. Of course, if someone forced to remap it, there is no 675 downside for the operation, the overlay best-effort service (with a 676 color which defined specific AII, best-effort requirement, and 677 mapping FA-id) in IGP domain will try to recurse over 678 or FIB entry. 680 9.3. Traffic Engineering Color Template Mapping to Flex-algo 682 An SR-TE tunnel/policy that served for traffic engineering service of 683 a virtual network specified by an AII was generated and computed 684 according to the relevant color template, which contained specific 685 AII and some other traditional TE constraints. If we config mapping 686 FA-id under the color template, the SR-TE tunnel/policy instance 687 could inherit forwarding information from corresponding SR Flex-Algo 688 FIB entry. 690 10. Network Slicing Examples 692 In this section, we will further illustrate the point through some 693 examples. All examples share the same figure below. 695 .-----. .-----. 696 ( ) ( ) 697 .--( )--. .--( )--. 698 +---+----link A1----+---+ +---+----link A1----+---+ 699 |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2| 700 | |----link B1----| |---link B1---| |----link B1----| | 701 +---+----link B2----+---+ +---+----link B2----+---+ 702 ( ) ( ) 703 '--( AS1 )--' '--( AS2 )--' 704 ( ) ( ) 705 '-----' '-----' 707 Figure 1 Network Slicing via AII 709 Suppose that each link belongs to separate virtual network, e.g., 710 link Ax belongs to the virtual network colored by AII A, link Bx 711 belongs to the virtual network colored by AII B. link x1 has an IGP 712 metric smaller than link x2, but TE metric lager. 714 To simplify the use case, each AS just contained a single IGP area. 716 10.1. Intra-domain Network Slicing Example 718 10.1.1. Best-effort Service over Network Slice Example 720 From the perspective of node PE1 in AS1, it will calculate best- 721 effort forwarding entry for each AII instance (including default AII) 722 to destinations in the same IGP area. For example: 724 For entry, forwarding information could be 725 ECMP during link A1 and link B1, with destination node-SID 100 for 726 . 728 For entry, forwarding information could be 729 link A1, with destination node-SID 200 for . 732 For entry, forwarding information could be 733 link B1, with destination node-SID 300 for . 736 10.1.2. TE Service over Network Slice Example 738 It could also initiate an SR-TE instance (SR tunnel or SR policy) 739 with the particular color template on PE1, PE1 is headend and ASBR1 740 is destination node. For example: 742 For SR-TE instance 1 with color template which defined criteria 743 including {default AII, min TE metric}, forwarding information could 744 be ECMP during two segment list {adjacency-SID 1002 for @PE1} and {adjacency-SID 1004 for @PE1}. 747 For SR-TE instance 2 with the color template which defined criteria 748 including {AII=A, min TE metric}, forwarding information could be 749 presented as the segment list {adjacency-SID 2002 for @PE1}. 752 For SR-TE instance 3 with the color template which defined criteria 753 including {AII=B, min TE metric}, forwarding information could be 754 presented as the segment list {adjacency-SID 3004 for @PE1}. 757 10.1.3. TE Service over Network Slice with Flex-algo Example 759 Furthermore, we can use SR Flex-algo to optimize the above SR-TE 760 instance. For example, for SR-TE instance 1, we can define FA-ID 201 761 with FAD that contains the same information as the color template, in 762 turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3. 764 Note that each FA-ID also needs to be enabled on ASBR1. So that the 765 corresponding SR FA entry could be: 767 For entry, forwarding information 768 could be ECMP during link A2 and link B2, with destination node-SID 769 600 for . 771 For entry, forwarding information 772 could be link A2, with destination node-SID 700 for . 775 For entry, forwarding information 776 could be link B2, with destination node-SID 800 for . 779 10.2. Inter-domain Network Slicing via BGP-LS Example 781 10.2.1. Best-effort Service Example 783 For SR-TE instance 4 with color template which defined criteria 784 including {default AII, min IGP metric}, forwarding information could 785 be segment list {node-SID 100 for , 786 adjacency-SID 1001 for @ASBR1, node-SID 400 for 787 }. 789 For SR-TE instance 5 with color template which defined criteria 790 including {AII=A, min IGP metric}, forwarding information could be 791 segment list {node-SID 200 for , 792 adjacency-SID 1001 for @ASBR1, node-SID 500 for 793 }. 795 For SR-TE instance 6 with color template which defined criteria 796 including {AII=B, min IGP metric}, forwarding information could be 797 segment list {node-SID 300 for , 798 adjacency-SID 1003 for @ASBR1, node-SID 600 for 799 }. 801 10.2.2. TE Service Example 803 For SR-TE instance 7 with color template which defined criteria 804 including {default AII, min TE metric}, forwarding information could 805 be ECMP during two segment list {adjacency-SID 1002 for @PE1, adjacency-SID 1001 for @ASBR1, adjacency- 807 SID 1002 for @ASBR2} and {adjacency-SID 1004 for 808 @PE1, adjacency-SID 1003 for 809 @ASBR1, adjacency-SID 1004 for @ASBR2}. 811 For SR-TE instance 8 with color template which defined criteria 812 including {AII=A, min TE metric}, forwarding information could be 813 segment list {adjacency-SID 2002 for @PE1, 814 adjacency-SID 2001 for @ASBR1, adjacency-SID 2002 815 for @ASBR2}. 817 For SR-TE instance 9 with color template which defined criteria 818 including {AII=B, min TE metric}, forwarding information could be 819 segment list {adjacency-SID 3004 for @PE1, 820 adjacency-SID 3003 for @ASBR1, adjacency-SID 3004 821 for @ASBR2}. 823 10.2.3. TE Service Using Flex-algo Example 825 For TE service, if we use SR Flex-algo to do optimizaztion, the above 826 forwarding information of each TE instance could inherit the 827 corresponding SR FA entry, it would look like this: 829 For SR-TE instance 7, forwarding information could be ECMP during two 830 segment list {node-SID 600 for , 831 adjacency-SID 1001 for @ASBR1, node-SID 600 for } and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency- 834 SID 1004 for @ASBR2}. 836 For SR-TE instance 8 with color template which defined criteria 837 including {AII=A, min TE metric}, forwarding information could be 838 segment list {node-SID 700 for , 839 adjacency-SID 2001 for @ASBR1, node-SID 700 for }. 842 For SR-TE instance 9 with color template which defined criteria 843 including {AII=B, min TE metric}, forwarding information could be 844 segment list {node-SID 800 for , 845 adjacency-SID 3003 for @ASBR1, node-SID 800 for }. 848 10.3. Inter-domain Network Slicing via BGP-LU Example 850 In figure 1, PE2 can allocate and advertise six labels for its 851 loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1 852 defines {default AII, min IGP metric}, color 2 defines {AII=A, min 853 IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4 854 defines {default AII, min TE metric}, color 5 defines {AII=A, min TE 855 metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise 856 these labels to ASBR2 and ASBR2 then continues to allocate six labels 857 each for prefix PE2 plus different color. Other nodes will have the 858 same operation. Ultimately PE1 will maintain six BGP-LU LSP. 860 For example, the BGP-LU LSP for color 1 will be over SR best-effort 861 FIB entry node-SID 100 for to pass through 862 AS1, over adjacency-SID 1001 for @ASBR1 to pass 863 inter-AS, over SR best-effort FIB entry node-SID 400 for to pass through AS2. 866 For example, The BGP-LU LSP for color 4 will over SR-TE instance 1 867 (see section 10.1.2), or SR best-effort FIB entry node-SID 600 for 868 (see section 10.1.3) to pass through 869 AS1, over adjacency-SID 1001 for @ASBR1 to pass 870 inter-AS, over SR-TE instance 1' or corresponding SR FA entry to pass 871 through AS2. Note that ASBR1 need also understand the meaning of a 872 specific color and select forwarding resource between two AS. 874 11. Implementation Suggestions 876 The implementation cost is low by means of existing segment routing 877 infrastructure. 879 11.1. SR-MPLS 881 As a node often contains control plane and forwarding plane, a 882 suggestion is that only default AII specific FTN table, i.e, 883 traditional FTN table, need be installed on forwarding plane, so that 884 there are not any modification and upgrade requirement for hardware 885 and existing MPLS forwarding mechanism. FTN entry for non-default 886 AII instance will only be maintained on the control plane and be used 887 for overlay service iteration according to next-hop plus color (color 888 will give AII information and mapping FA-id information). Note that 889 ILM entry for all AII need be installed on forwarding plane, that 890 does not bring any confusion because of prefix-SID allocation per 891 AII. 893 SR NHLFE entry and other iteration entry such as 894 can contain AII information for expected packet scheduling. The 895 Slice Type value of AII can distinguish flows by coarse-grained 896 classification, while the Instance value of AII can be used for more 897 scheduling policy. 899 11.2. SRv6 901 For SRv6 case, IPv6 address resource is directly used to represent 902 SID, so that different IPv6 block could be allocated to different 903 slice. There are two possible ways to advertise slice specfic IPv6 904 block: 906 o Traditional prefix reachability, but only for default AII (0) 907 specific IPv6 block. 909 o New SRv6 Locator advertisement, for nonzero AII specific IPv6 910 block. 912 Forwarding entries for the default AII specific locators advertised 913 in prefix reachability MUST be installed in the forwarding plane of 914 receiving routers. 916 Forwarding entries for the nonzero AII specific locators advertised 917 in the SRv6 Locator MUST be also installed in the forwarding plane of 918 receiving SRv6 capable routers when the associated AII is supported 919 by the receiving node. 921 The entries of both the above two cases SHOULD be installed in the 922 unified FIB table, i.e., a single FIB table for default AII, because 923 different IPv6 block is allocated to different slice. Instead, more 924 FIB tables created for each VN in dataplane will bring comlexity for 925 overlay service iteration, that is why MTR has no practical 926 deployment. 928 The forwarding information of FIB entry can contain AII information 929 for expected packet scheduling. 931 12. IANA Considerations 933 This document requests IANA to create a new top-level registry called 934 "Network Slicing Parameters". This registry is being defined to 935 serve as a top-level registry for keeping all other Network Slicing 936 sub-registries. 938 Additionally, a new sub-registry "AII (TN-slice Identifier) 939 codepoint" is to be created under top-level "Network Slicing 940 Parameters" registry. This sub-registry maintains 32-bit identifiers 941 and has the following registrations: 943 +============+======================================================+ 944 | Slice Type | Instance | Description | 945 |(High 8bits)| (Low 24bits) | | 946 +============+==============+=======================================+ 947 | | 0 | Default Slice: the original physical | 948 | 0(Normal) | | network. | 949 | +--------------+---------------------------------------+ 950 | | nonzero | Normal Slice, for user defined. | 951 +------------+--------------+---------------------------------------+ 952 | | 0 | Resevered. | 953 | +--------------+---------------------------------------+ 954 | 1(eMBB) | | Slice suitable for the handling of 5G | 955 | | nonzero | enhanced Mobile Broadband, for user | 956 | | | defined. | 957 +------------+--------------+---------------------------------------+ 958 | | 0 | Resevered. | 959 | +--------------+---------------------------------------+ 960 | 2(URLLC) | | Slice suitable for the handling of | 961 | | nonzero | ultra- reliable low latency | 962 | | | communications, for user defined. | 963 +------------+--------------+---------------------------------------+ 964 | | 0 | Resevered. | 965 | +--------------+---------------------------------------+ 966 | 3(MIoT) | nonzero | Slice suitable for the handling of | 967 | | | massive IoT, for user defined. | 968 +------------+--------------+---------------------------------------+ 969 | | 0 | Resevered. | 970 | +--------------+---------------------------------------+ 971 | 4(V2X) | nonzero | Slice suitable for the handling of | 972 | | | V2X services, for user defined. | 973 +------------+--------------+---------------------------------------+ 974 | 5-255 | any | Unassigned. | 975 +------------+--------------+---------------------------------------+ 977 Table 1. AII Codepoint 979 13. Security Considerations 981 TBD. 983 14. Acknowledgements 985 TBD. 987 15. Normative references 989 [I-D.ali-spring-network-slicing-building-blocks] 990 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 991 "Building blocks for Slicing in Segment Routing Network", 992 draft-ali-spring-network-slicing-building-blocks-02 (work 993 in progress), November 2019. 995 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 996 Wang, A., Chen, H., Talaulikar, K., Zhuang, S., and S. Ma, 997 "BGP-LS Extension for Inter-AS Topology Retrieval", draft- 998 ietf-idr-bgpls-inter-as-topology-ext-07 (work in 999 progress), September 2019. 1001 [I-D.ietf-idr-tunnel-encaps] 1002 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 1003 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 1004 (work in progress), December 2019. 1006 [I-D.ietf-isis-l2bundles] 1007 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 1008 E. Aries, "Advertising L2 Bundle Member Link Attributes in 1009 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 1010 May 2017. 1012 [I-D.ietf-lsr-flex-algo] 1013 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1014 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1015 algo-05 (work in progress), November 2019. 1017 [I-D.ietf-spring-segment-routing-policy] 1018 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1019 P. Mattes, "Segment Routing Policy Architecture", draft- 1020 ietf-spring-segment-routing-policy-06 (work in progress), 1021 December 2019. 1023 [I-D.ietf-spring-sr-service-programming] 1024 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1025 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1026 Henderickx, W., and S. Salsano, "Service Programming with 1027 Segment Routing", draft-ietf-spring-sr-service- 1028 programming-01 (work in progress), November 2019. 1030 [I-D.peng-lsr-flex-algo-opt-slicing] 1031 Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm 1032 Optimazition for Netwrok Slicing", draft-peng-lsr-flex- 1033 algo-opt-slicing-00 (work in progress), November 2019. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, 1037 DOI 10.17487/RFC2119, March 1997, 1038 . 1040 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1041 (TE) Extensions to OSPF Version 2", RFC 3630, 1042 DOI 10.17487/RFC3630, September 2003, 1043 . 1045 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1046 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1047 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1048 . 1050 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1051 Topology (MT) Routing in Intermediate System to 1052 Intermediate Systems (IS-ISs)", RFC 5120, 1053 DOI 10.17487/RFC5120, February 2008, 1054 . 1056 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1057 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1058 2008, . 1060 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 1061 "Traffic Engineering Extensions to OSPF Version 3", 1062 RFC 5329, DOI 10.17487/RFC5329, September 2008, 1063 . 1065 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1066 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1067 . 1069 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 1070 Traffic Engineering (MPLS-TE)", RFC 7308, 1071 DOI 10.17487/RFC7308, July 2014, 1072 . 1074 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1075 S. Ray, "North-Bound Distribution of Link-State and 1076 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1077 DOI 10.17487/RFC7752, March 2016, 1078 . 1080 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1081 "Advertisement of Multiple Paths in BGP", RFC 7911, 1082 DOI 10.17487/RFC7911, July 2016, 1083 . 1085 Authors' Addresses 1087 Shaofu Peng 1088 ZTE Corporation 1090 Email: peng.shaofu@zte.com.cn 1092 Ran Chen 1093 ZTE Corporation 1095 Email: chen.ran@zte.com.cn 1097 Gregory Mirsky 1098 ZTE Corporation 1100 Email: gregimirsky@gmail.com 1102 Fengwei Qin 1103 China Mobile 1105 Email: qinfengwei@chinamobile.com