idnits 2.17.1 draft-camarilloelmalky-springdmm-srv6-mob-usecases-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 15, 2019) is 1715 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) == Missing Reference: 'SGi' is mentioned on line 423, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING and DMM P. Camarillo, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 16, 2020 H. Elmalky, Ed. 6 Individual 7 S. Matsushima 8 SoftBank 9 D. Voyer 10 Bell Canada 11 A. Cui 12 AT&T 13 B. Peirens 14 Proximus 15 August 15, 2019 17 SRv6 Mobility Use-Cases 18 draft-camarilloelmalky-springdmm-srv6-mob-usecases-02 20 Abstract 22 This document describes the SRv6 use-cases in the mobile network in 23 association with different mobile generations (3G, 4G, and 5G). It 24 also highlights potential interworking with SR-MPLS in relevant use- 25 cases. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 16, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. SP Network Simplification use-cases . . . . . . . . . . . 5 71 3.1.1. Radio-core Handoff . . . . . . . . . . . . . . . . . 5 72 3.1.1.1. Radio-transport programmability . . . . . . . . . 5 73 3.1.1.2. User-plane state transfer, offload, and mutation 6 74 3.1.1.3. Rip-n-replace of GTP with SRv6 . . . . . . . . . 8 75 3.1.2. End-to-end network slicing [N3, N9, N6 and transport] 9 76 3.1.3. GiLAN Service Programming [N6 and N9] . . . . . . . . 9 77 3.1.3.1. Service Programming on Gi-LAN for 3G/4G [SGi] . . 10 78 3.1.3.2. Service Programming for 5G [N6 and N9] . . . . . 10 79 3.1.4. ID-Location Isolation at anchors . . . . . . . . . . 10 80 3.2. New mobility use-cases . . . . . . . . . . . . . . . . . 10 81 3.2.1. eMBB (Enhanced Mobile Broadband) . . . . . . . . . . 10 82 3.2.1.1. Fixed/Mobile Convergence (HA, FWA & WA) . . . . . 10 83 3.2.1.2. Mobile Enforced SD-WAN . . . . . . . . . . . . . 11 84 3.2.2. mMTC (massive Machine Type Communications) . . . . . 11 85 3.2.2.1. Stationary IoT Devices (industrial applications) 11 86 3.2.3. URLLC (Ultra Reliable Low Latency Communications) . . 12 87 4. Work in progress . . . . . . . . . . . . . . . . . . . . . . 12 88 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 89 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 6.2. Informative References . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 4G/LTE mobile networks are complex and the use cases that 5G has been 97 architected to address, introduce new requirements and additional 98 complexity to both the RAN and the mobile core. The current 99 architecture employs the GPRS tunneling protocol (GTP) as the primary 100 vehicle for user plane interconnect in the RAN and 5GC. GTP is 101 currently used in two contexts, from the RAN to the first anchor 102 point; the S-PGW/UPF (S1-U/N3 interface) and for inter S-PGW/UPF 103 connectivity (S5-S8/N9 interface). While the tunnels themselves do 104 not impose significant state beyond that needed, they do have a 105 significant control plane setup component and are a potential target 106 for network delayering. 108 Segment Routing [I-D.ietf-spring-segment-routing] is a network 109 architecture that simplifies networks by removing state from the 110 network infrastructure, creating a scalable SDN architecture for 111 overlays (VPNs), underlay (SLA, Traffic Engineering, FRR) and service 112 programming (GiLAN). The IPv6 instantiation -also known as SRv6 113 [I-D.ietf-spring-srv6-network-programming]- takes this even further 114 with the introduction of the Network Programming concept, allowing to 115 bind segments to any kind of VNF anywhere in the network -from 116 private DCs to public cloud services. 118 Segment routing embodies a number of potentially useful properties 119 for consideration in a 4G/5G mobile networking context: 121 1.- Direct manipulation of path routing by the head-end 123 SRv6 provides the ability to direct traffic through an arbitrary path 124 without the imposition of path state in the network or requiring a 125 separate signaling system. It does this without signaling by 126 encoding the path state in the packet header. This means the path 127 head-end can instantly fulfill changes to a path by simply changing 128 the header encoded information. 130 This capability has numerous applications as far as networking in 131 general (traffic engineering, policy routing etc.), but has 132 additional applicability to mobile networks: 134 o The ability of a path head-end to manipulate the intermediate hops 135 in a path can be exploited for end system mobility, the 136 penultimate hop simply becomes the "care of" address. 138 o The ability of path head-end to imply an asymmetric return path 139 for a specific forwarding equivalence class (FEC). 141 o Densification in the radio topology embodied in concepts like 142 coordinated multipoint and multi-connectivity require the 143 instantaneous redirection of traffic from the coordinating radio 144 controller to any of several base stations. This is critical to 145 exploit ephemeral "rich paths" that 4G & 5G radio technologies 146 depend upon to achieve high rates of information transfer. 148 2.- Network programmability 150 The ability to bind segments to network functions provides an 151 increased level of abstraction in service delivery combined with a 152 practical realization. This would have applications in the GiLAN/N6, 153 combined with the ability to specify a path from the head-end as 154 applications in the GiLAN/N6. 156 3.- Overall simplification of the control plane 158 As noted previously SRv6 dispenses with a signaling system. This has 159 obvious benefits as a simplification to overall network operation, 160 but may have additional benefits in the "signaling rich" environment 161 of mobile networks. 163 This memo serves to critically explore the applicability of SRv6 to 164 4G/5G mobile networks. It does that via an exploration of how SRv6 165 can simplify current mobile network architecture to improve the 166 status quo of eMBB operation, and then delves into the new use cases 167 that 5G is targeted towards. 169 2. Terminology 171 This document focuses on the use-cases, and it's associated 172 terminologies. The full list of terminologies exists in 173 [I-D.ietf-spring-srv6-network-programming]. 175 In this document we focus on the 5G systems architecture, as 176 specified in [TS.23501]. This document also refers to 3G and 4G 177 networks as specified in [TS.23002]. 179 The uplink/upstream traffic is the traffic originated at the UE, 180 while the downlink/downstream traffic is traffic destined towards the 181 UE. 183 3. Use-cases 185 Use-cases have been classified into multiple categories depending on 186 their fit into the mobile-network domain (Radio, Transport, Core) or 187 mobile network generation (3G/4G, or 5G). 189 3.1. SP Network Simplification use-cases 191 3.1.1. Radio-core Handoff 193 3.1.1.1. Radio-transport programmability 195 Advances in radio technology, the deployment of new spectrum for 5G 196 and the quest for ever increasing spectral efficiency results in 197 increasingly complex RAN and air interface topologies. The result is 198 that the RAN end of a GTP tunnel may appear as a single end point to 199 the core network, but the actual realization is substantially more 200 complex. 202 Modern radio scheduling is increasingly focused on using techniques 203 such as MIMO to multiply the instantaneous bandwidth available for 204 information transfer for a given unit of spectrum. A "rich path" can 205 be very ephemeral so any latency between path measurement and 206 initiating data transfer to a UE can be parasitic in the overall 207 system efficiency. 209 3.1.1.1.1. Multi-connectiveity and coordinated multi-point 211 There are multiple scenarios where a UE can be associated with more 212 than one antenna and the associated spectrum: 214 Coordinated multipoint (CoMP) involves a UE associated with multiple 215 geographically distributed antennas serving a common block of 216 spectrum, and the radio controller selecting the best antenna at any 217 given time. The other antennas being quiescent in the sector 218 occupied by the UE at the time of transmission to avoid overlap. 219 This can be in the context of an RRC/RLC split (F1-U interface) or a 220 Phy Hi/Phy Lo split (F2-U interface). 222 Multi-connectivity can see a UE associated with multiple antennas 223 each serving different spectral allocations. Applications include 224 offload from a macro cell to a small cell. The possibility of 225 simultaneous transfer from multiple antennas also exists. And again 226 this can be on the basis of an F1 or F2 split in the RAN. 228 In both cases the radio controller is required to be able to 229 instantly redirect traffic based on current radio measurements to any 230 of a constellation of antennas serving a given UE. 232 3.1.1.1.2. Fronthaul 234 Modern radio systems have been deconstructed in order to drive 235 efficiency across a variety of metrics. In essence various stages of 236 waveform construction have been abstracted and exposed on interfaces 237 as part of the 5G RAN architecture. In the most simplest form it 238 allows putting functionality where it is easy to service, such as the 239 equipment at the bottom of the tower rather than the top. In a rich 240 radio connectivity context it permits co-location of radio scheduling 241 and waveform generation which drives spectral efficiency, but where 242 applied also results in significant multiples of bandwidth, and very 243 tight jitter and delay requirements. The current specification for 244 the F2-U or e(CPRI) packet interface has a maximum latency of 75 usec 245 and correspondingly tight jitter requirements. 247 3.1.1.2. User-plane state transfer, offload, and mutation 249 A proper session handoff between radio, transport, and mobile-core 250 requires storing/recalling user-plane session state on multiple 251 levels. The use of SRv6 reduces the number of states needed in the 252 network nodes by mapping the UE session state into IPv6 SID (Segment 253 IDs) in SRH. Furthermore, mutation of SID-lists shall enable SMF to 254 program data-paths (handling-state) and policies (serving-state) on 255 per-subscriber / per-application level. 257 That session state can be broken down into two categories: 259 1.- Handling state: Who is the session handler? 261 o A 1-to-1 mapping between GTP tunnel (TEID) and S-PGW/UPF 263 o Usually stored at load-balancers deployed ahead of S-PGW/UPF 264 instances or embedded inside the S-PGW/UPF system. 266 2.- Serving state: What is the serving-policy associated with this 267 session? 269 o A 1-to-1 mapping between the UE and a specific policy to be 270 enforced on the subscriber traffic. 272 o The policy may include (but not limited to) the authorization & 273 accounting profile, one or multiple QoS profiles, one or multiple 274 service-chaining/programming profiles. 276 o A 1-to-1 mapping between a UE session and it's stats-registers at 277 the S-PGW/UPF. 279 o It is typical that S-PGW/UPF may break down the service-state into 280 sub-states reflecting groups of 5-tuple flows, or employ other 281 techniques (ex. DPI, deep packet inspection) to break down the 282 serving-state even further within the same 5-tuple flow. 284 The ability to transfer, offload, or mutate the user-plane state with 285 no/minimum disruption to end-users is one of the most significant 286 challenges facing the mobile network's scalability towards mMTC use- 287 cases (The current GTP-U mandates a per-session tunnel creation & 288 handling). Moreover, the direct 1-to-1 binding between UE session ID 289 and Location affects the optimal-path selection, which is one of the 290 most significant challenges facing URLLC use-cases in 5G. 292 The use of SRv6 shall simplify the state storage dramatically where a 293 single SID-list embedded in the UE session packet can store the 294 handling-state and the majority of the serving-state. SRv6 295 programmability and traffic-engineering shall allow an easy way to 296 transfer, offload, or mutate that state. 298 3.1.1.2.1. State-offload: 300 Upstream state-offload: 301 the use of SRv6 shall allow the S-PGW/UPF anchor(s) to offload the 302 load-balancing function from a dedicated load-balancer in mobile-core 303 to be a standard function in packet-forwarding in transport network 304 where any SR-aware node on the path between eNB and S-PGW/UPF can 305 forward the UE session to the proper S-PGW/UPF handling instant by 306 relying on the handling-state stored in the SID-list in each packet. 308 Downstream state-offload: 309 The L3 anchor (PGW/UPF) is the first node that handles the subscriber 310 traffic in the downstream direction, depending on the policy 311 associated with the subscriber traffic. The PGW/UPF may decide to 312 hairpin the traffic through multiple application (service chain) 313 before sending it towards the radio-network. This implies double 314 packet-processing on PGW/UPF instant (50% penalty on the VNF useful 315 throughput). 317 The use of SRv6 shall allow the PGW/UPF to impose a specific data- 318 path on a group of 5-tuple flows without the need for hairpins all 319 the traffic through PGW/UPF. Which means the PGW/UPF can offload the 320 first packet processing towards another none-SR- node earlier in the 321 downstream path (ex. Service-proxy, or packet inspector) as per 322 specific service-pipeline policy. 324 Moreover, that offload-service can be programmed once the S-PGW/UPF 325 terminate the subs-session on the upstream direction. Alternatively, 326 the offload-service can be programmed on-demand after the first few 327 packets been hair-pinned through the PGW/UPF on the downstream path. 329 3.1.1.2.2. State-transfer: 331 Handling-state: 332 SRv6 shall enable the handling-state to be embedded in the data-flow 333 as metadata (in a form of SID-list). This means that all load- 334 balancing operations can be performed by any of the SR-aware 335 intermediate nodes in a stateless fashion with a zero-state transfer 336 at failure scenarios. 338 Serving-state: 339 Depending on the applied policy, a significant portion of the 340 serving-state can be embedded in the data-flow as metadata (in a form 341 of SID-list). This means that serving nodes (S-PGW/UPF) have a 342 smaller amount of data to store/recall to serve the UE session. 344 3.1.1.2.3. State-mutation: 346 SRv6 provides a more natural way to mutate the handling-state and 347 serving-state to follow the optimal data path or fulfill traffic- 348 engineering constrain(s). 350 In contrast to the current limitation of mutating the state only at 351 SGW (session L2-anchor point) or PGW (session L3-anchor point). SRv6 352 shall allow the state mutation on any authorized SR-aware node 353 between radio and mobile core. 355 3.1.1.3. Rip-n-replace of GTP with SRv6 357 A possible mechanism to do an early-deployment of SRv6 is to keep the 358 tunnel-nature of GTP but do a simple data-plane replacement of 359 IP/UDP/GTP-U with SRv6 for specific PDU sessions. In this case, 360 there is no session aggregation, and the SRv6 segment corresponding 361 to the overlay creation now carries the TEID, QFI and RQI as part of 362 the SID arguments. 364 In this use-case there is no subscriber-traffic integration with the 365 underlay or service programming. There could be some integration but 366 it is based on static policies and not configured via the currently 367 existing mobility management. 369 This is an interworking mechanism that shall used for an early stage 370 implementation with no changes to the N4 interface. 372 3.1.2. End-to-end network slicing [N3, N9, N6 and transport] 374 One of operator's main challenges is providing end-to-end network 375 slicing, taking into consideration the RAN, the S-PGW/UPF and the 376 VNFs in the GiLAN; but more importantly taking also into 377 consideration the transport network. 379 SRv6 can help bridging the gap in between all of these since it 380 integrates the overlay, underlay and service programming into a 381 single protocol. End-to-end SR policies can be defined that span 382 across the RAN, S-PGW/UPF and transport network, without requiring 383 any stitching configuration at the domain boundaries. From an 384 overlay perspective, it is clear that SRv6 can provide -if desired- 385 isolation among different RAN or S-PGW/UPF nodes. 387 In the transport network, the SRv6 overlay can integrate with an 388 existing SRv6 or SR-MPLS transport network to provide traffic 389 engineering in the underlay network infrastructure. SR provides 390 operators with a stateless mechanism to build network slices with 391 different optimization objectives or constrains i.e. low-latency 392 (uRLLC), resource isolation (disjointness), etc... 394 Also, SR provides mechanisms for in-band performance monitoring. 395 This implies that the end-to-end network slice can react upon 396 topology changes -that for example might change the low-latency 397 path-. 399 3.1.3. GiLAN Service Programming [N6 and N9] 401 Service Programming, in coordination with SRv6 can be used for 402 optimal placement of VNFs in the Gi-LAN of mobile operators for 403 flawless VNF management and placement -DC resource utilization-. 405 SRv6 transparently integrates VNFs 406 [I-D.xuclad-spring-sr-service-programming], in the same SR policy 407 used for overlay creation and underlay control. The VNFs are cloud- 408 infrastructure agnostic -can be hosted on a private DC or public 409 cloud-, and there is no state per-flow or per-chain in the network 410 infrastructure. This implies a huge flexibility for mobile 411 operators. Note that VMs can be distributed in different tenants, or 412 can be migrated while there is live traffic without any major 413 manageability complexity, state to update in the network 414 infrastructure or packet loss. Note also that in the case of network 415 slicing, the VNFs can be shared across multiple slices or can be 416 restricted to only a particular slice. This can be chosen on a per- 417 VNF granularity. 419 In addition, SRv6 offers mechanisms to do VNF load-balancing and to 420 convey additional flow information to stateless VNFs using the SRv6 421 SID arguments, by leveraging the network programming concept. 423 3.1.3.1. Service Programming on Gi-LAN for 3G/4G [SGi] 425 SRv6-based NFV provides an approach to optimally steer traffic 426 through Gi-LAN network functions in 3G/4G networks. 428 The PGW can steer uplink traffic into a specific SR policy that 429 contains as many segments as VNFs that the packet must traverse. The 430 packet follows the path specified in the SR policy, traversing the 431 set of VNFs before getting delivered to the external PDN -i.e. 432 internet-. 434 3.1.3.2. Service Programming for 5G [N6 and N9] 436 In 5G networks SRv6 can offer NFV control, as done in the Gi-LAN for 437 3G-4G networks (N6 interface), but can also integrate the VNFs within 438 the N9 interface. This means that we can have more flexibility 439 regarding the distribution and association of the functions/VNFs/ 440 micro-services, and bring applications closer to the user, where they 441 might be better located for the operator and improve the overall 442 customer experience. 444 3.1.4. ID-Location Isolation at anchors 446 TBD 448 3.2. New mobility use-cases 450 3.2.1. eMBB (Enhanced Mobile Broadband) 452 3.2.1.1. Fixed/Mobile Convergence (HA, FWA & WA) 454 The end users of different access networks under control of the same 455 service provider would obtain significant benefit if there is a tight 456 integration for service delivery in between the mobile access network 457 and the fixed network. 459 This is the example of a residential user that is accessing content 460 from his mobile phone, and once he arrives home his phone 461 automatically connects to his home wireless network provided whose 462 connectivity is provided by the same operator. As per today, these 463 networks have different architectures, with different control-planes 464 and data-planes, and with different policy control and service 465 management. 467 SRv6 helps uniting the gap in between different access networks by 468 optimizing the data path in between hierarchical networks and 469 directly adding an SR policy that spans from the mobile packet core 470 up to the broadband network BNG. Such capability will simplify the 471 delivery of fixed-services on top of wireless infrastructure. it will 472 also enable the simultaneous use of wireless and fixed connections 473 towards end-user. 475 3.2.1.2. Mobile Enforced SD-WAN 477 TBD 479 3.2.2. mMTC (massive Machine Type Communications) 481 3.2.2.1. Stationary IoT Devices (industrial applications) 483 There are many types of IoT devices, ranging from connected cars to 484 massive machine type devices like meter readers, which are 485 stationary. One of these examples is electricity meters. These 486 devices are static and might only attach to other gNBs due to 487 changing RF conditions. 489 Massive machine type devices is projected to grow to 10's of billions 490 in operator networks in the next few years. However, the traditional 491 3GPP GTP tunnel/bearer based connection-oriented architecture does 492 not scale for billions of IoT devices due to the amount of signaling 493 overhead associated with GTP tunnel setup/tear- down and the UE 494 context information maintained at various parts of the mobile 495 network. 497 Unlike smart devices, electric meters never move and each generates 498 low RPU for carriers. For this reason, to efficiently support the 499 massive machine type of stationary IoT devices, a simpler and more 500 scalable control and user plane architecture is needed that can 501 reduce the amount of signaling overhead and the UE context 502 information kept in the network. This new architecture will need to 503 work across all types of access technologies to improve adaptability 504 to future RAT networks. 506 SRv6 can help improve scalability in the RAN, transport, and packet 507 core networks significantly by removing GTP tunnels for each 508 individual stationary IoT device, and replacing by the aggregated 509 SRv6 route information for all the similar stationary IoT devices. 510 For instance, at the eNB/gNB, only the first electric meter device 511 for an electric company needs the SRv6 route set up procedure, which 512 has one SRv6 look up table entry associated with it. No subsequent 513 SRv6 route set up procedures and no additional SRv6 table entries for 514 the succeeding electric meters are needed at the same eNB/gNB. This 515 effectively reduces the signaling overhead and UE context overhead by 516 (1-1/N)% (where N is the number of the electric company meter readers 517 in the same eNB/gNB). In the case of RAN virtualization with an 518 aggregated vBBU for many cell sites, the reduction of the signaling 519 and UE context overhead will be greater since N is a much bigger 520 number. 522 The significant reduction of the signalling overhead and UE context 523 overhead can be translated to the cost reduction of running 524 operators' wireless network. In addition, this new architecture 525 using SRv6 allows flexible service edge treatment, service chaining, 526 such as billing, TE or other capabilities. 528 3.2.3. URLLC (Ultra Reliable Low Latency Communications) 530 TBD 532 4. Work in progress 534 o Use of SRv6 in optimizing interface (reference N4 as defined by 535 3GPP xxx r16) between control-plane and user-plane. 537 o Security implications & benefits of SRv6 in mobile networks. 539 5. Acknowledgements 541 We would like to thank Francois Clad, Darren Dukes, Zafar Ali, Peter 542 Bosch, Simon Spraggs and Tom Anschutz for their help. 544 6. References 546 6.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [TS.23501] 554 3GPP, "System Architecture for the 5G System", 3GPP TS 555 23.501 15.2.0, June 2018. 557 6.2. Informative References 559 [I-D.ietf-spring-segment-routing] 560 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 561 Litkowski, S., and R. Shakir, "Segment Routing 562 Architecture", draft-ietf-spring-segment-routing-15 (work 563 in progress), January 2018. 565 [I-D.ietf-spring-srv6-network-programming] 566 Filsfils, C., Camarillo, P., Leddy, J., 567 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 568 Network Programming", draft-ietf-spring-srv6-network- 569 programming-01 (work in progress), July 2019. 571 [I-D.xuclad-spring-sr-service-programming] 572 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 573 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 574 Henderickx, W., and S. Salsano, "Service Programming with 575 Segment Routing", draft-xuclad-spring-sr-service- 576 programming-02 (work in progress), April 2019. 578 [TS.23002] 579 3GPP, "Network Architecture", 3GPP TS 23.23002 15.0.0, 580 March 2018. 582 Authors' Addresses 584 Pablo Camarillo Garvia (editor) 585 Cisco Systems, Inc. 586 Spain 588 Email: pcamaril@cisco.com 590 Clarence Filsfils 591 Cisco Systems, Inc. 592 Belgium 594 Email: cf@cisco.com 596 Hani Elmalky (editor) 597 Individual 598 United States of America 600 Email: hani.elmalky@gmail.com 601 Satoru Matsushima 602 SoftBank 603 1-9-1,Higashi-Shimbashi,Minato-Ku 604 Tokyo 105-7322 605 Japan 607 Email: satoru.matsushima@g.softbank.co.jp 609 Daniel Voyer 610 Bell Canada 611 Canada 613 Email: daniel.voyer@bell.ca 615 Anna Cui 616 AT&T 617 United States of America 619 Email: zc1294@att.com 621 Bart Peirens 622 Proximus 623 Belgium 625 Email: bart.peirens@proximus.com