idnits 2.17.1 draft-kim-spring-mobile-network-use-cases-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 42 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6459' is mentioned on line 136, but not defined == Missing Reference: 'HSS' is mentioned on line 234, but not defined == Missing Reference: 'MME' is mentioned on line 236, but not defined == Missing Reference: 'PCRF' is mentioned on line 236, but not defined == Missing Reference: 'S-GW' is mentioned on line 238, but not defined == Missing Reference: 'P-GW' is mentioned on line 238, but not defined == Missing Reference: 'UE' is mentioned on line 240, but not defined == Missing Reference: 'AS' is mentioned on line 244, but not defined == Missing Reference: 'SGi-LAN' is mentioned on line 244, but not defined == Missing Reference: 'I-D.ietf-6man-segment-routing-header' is mentioned on line 398, but not defined == Unused Reference: 'RFC7855' is defined on line 459, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.Y. Kim 2 Internet Draft ETRI 3 Intended status: Informational G.M. Lee 4 LJMU 5 Expires: April 2017 6 October 31, 2016 8 SPRING Use cases for Mobile Network 9 draft-kim-spring-mobile-network-use-cases-03 11 Abstract 13 The ability for a node to specify a forwarding path, other than the 14 normal shortest path, that a particular packet will traverse, 15 benefits a number of network functions. Source-based routing 16 mechanisms have previously been specified for network protocols, but 17 have not seen widespread adoption. In this context, the term 18 'source' means 'the point at which the explicit route is imposed'. 20 The objective of this document is to illustrate some use cases that 21 provide the traffic engineering and the load balancing for mobile 22 and transport network, applying segment routing. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on April 31, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. 68 Table of Contents 70 1. Introduction ................................................ 4 71 1.1. Terminology and abbreviations ........................... 5 72 2. Mobile network overview ...................................... 6 73 2.1. GTP tunneling 8 74 2.2. Quality of Service (QoS) 9 75 3. Use case ................................................... 10 76 4. Security Considerations ..................................... 11 77 5. IANA Considerations ........................................ 11 78 6. References ................................................. 11 79 6.1. Normative References 11 80 6.2. Informative References 12 81 7. Acknowledgments ............................................ 13 83 1. Introduction 85 In a mobile network, GTP is the protocol developed for tunneling and 86 encapsulation of data units and control messages in GPRS. GTP for 87 the Evolved 3GPP system comes in two variants, control and user 88 plane. The control plane GTP-C handles the signaling, and it is 89 needed in addition to the protocol for pure transfer of user related 90 data, GTP-U. [3GPP TS 23.060] 92 GTP-U is used for carrying user data within the GPRS core network 93 and between the radio access network and the core network. The user 94 data transported can be packets in any of IPv4 or IPv6 formats. GTP- 95 C is out of scope in this document. 97 IP packets are forwarded through the GTP tunnel between the P-GW and 98 the eNB for transmission to the UE in a mobile network. These GTP 99 tunnels are established per EPS bearer when a user is attached to 100 the LTE network. EPS uses the concept of EPS bearers to route IP 101 traffic from a gateway in the PDN to the UE. A bearer is an IP 102 packet flow with a defined quality of service (QoS) between the 103 gateway and the UE. 105 On the other hand, IP transport networks may provide data 106 transmission and interaction between the gateways and the UE. The 107 mobile nodes like the gateways are connected to an IP transport 108 network in overlay. Therefore the mapping between transport nodes 109 and mobile nodes may be needed to consistently guarantee QoS in 110 terms of priority control, traffic engineering and load balancing. 112 For simplicity we only describe GTP tunneling in the context of LTE 113 (Long Term Evolution), which aims to provide seamless Internet 114 Protocol (IP) connectivity between user equipment (UE) and the 115 packet data network (PDN). Indeed GTP tunneling also applies to 116 earlier generations of mobile networks, such as purely UMTS-based 117 mobile networks. 119 On the other hand, segment routing mechanisms [draft-ietf-spring- 120 problem-statement] have been developed to provide the traffic 121 engineering and the load balancing for networks. These mechanisms 122 could be also applicable to an IP-based mobile and transport network. 123 Therefore this document addresses how to utilize segment routing 124 mechanisms in a mobile network. 126 The objective of this document is to illustrate some use cases that 127 provide QoS in a mobile and transport network by applying segment 128 routing. 130 1.1. Terminology and abbreviations 132 Much of the terminology used in this document has been defined by 133 the 3rd Generation Partnership Project (3GPP), which defines 134 standards for mobile service provider networks. Although a few terms 135 are defined here for convenience, further terms can be found in 136 [RFC6459]. 138 AS Access Switch 140 AR Aggregation Router 142 ARP Allocation and Retention Priority 144 CE Customer Edge Router 146 D-IP Destination IP address 148 eNB enhanced NodeB 150 ECMP Equal Cost Multi-path Protocol 152 EPC Evolved Packet Core 154 EPS Evolved Packet System 156 ER Edge Router 158 G-PDU GTP-U Protocol Data Unit 160 GTP GPRS (General Packet Radio Service) Tunneling Protocol 162 GTP-U GTP layer for the user plane 164 HSS Home Subscriber System (control plane element) 166 IMSI The International Mobile Subscriber Identity 168 LTE Long Term Evolution 170 MME Mobility Management Entity (control plane element) 171 P-GW Packet Gateway 173 PCE Path Computation Element 175 PCRF Policy and Charging Rules Function 177 PDN Packet Data Network 179 PDU Protocol Data Unit 181 PE Provider Edge Router 183 QCI QoS Class Identifier 185 QoS Quality of Service 187 S-GW Serving Gateway, primary function is user plane mobility 189 S-IP Source IP address 191 T-PDU Transport Protocol Data Unit 193 TEID 3GPP standardized Policy and Charging Rules Function 195 UDP User Datagram Protocol 197 UE User Equipment 199 VoIP Voice over IP 201 2. Mobile network overview 203 The major functional components of a LTE network are shown in Figure 204 1 and include user equipment (UE) like smartphones or tablets, the 205 LTE radio unit named enhanced NodeB (eNB), the serving gateway (S- 206 GW) which together with the mobility management entity (MME) takes 207 care of mobility and the packet gateway (P-GW), which finally 208 terminates the actual mobile service. These elements are described 209 in detail in [TS.23.401]. Other important components are the home 210 subscriber system (HSS) and the policy and charging rule function 211 (PCRF), which are described in [TS.23.203]. The P-GW interface 212 towards the SGi-LAN is called the SGi-interface, which is described 213 in [TS.29.061]. 215 In LTE, a mobile network consists of some LTE components 216 (specifically EPS) and GTP connections between eNB and S-GW, and 217 between S-GW and P-GW are established, as shown in Figure 1. An IP 218 packet for a UE is encapsulated in a GTP-U packet and tunneled cross 219 multiple interfaces (the S5/S8 interface from the P-GW to the S-GW, 220 the S1 interface from the S-GW to the eNB), and the radio interface 221 from the eNB to the UE. 223 The LTE components would be connected in overlay to MPLS components 224 such as AS, AR and ER in an IP transport network. The interactions 225 between LTE components occur through MPLS components. 227 EPS provides the user with IP connectivity to a PDN for accessing 228 the Internet, as well as for running services such as Voice over IP 229 (VoIP). An EPS bearer is typically associated with a QoS. Multiple 230 bearers can be established for a user in order to provide different 231 QoS streams or connectivity to different PDNs. 233 +----------------------------------------+ 234 | Mobile Network [HSS] | [OTT Appl. Platform] 235 | | | | 236 | +--------- [MME] [PCRF]-----+--------+ | 237 | | | | | | | 238 | + [S-GW] [P-GW] | | Internet 239 | | S1-U |S5/S8 | | | | 240 | [UE] -- [eNB]----------+------+ | | | 241 | | | | | | 242 +===========|===================|========+ +-----+-----+-------+ 243 | | | | | | 244 | [AS] - [AR(PE)] == [ER(PE)] == +--+----[SGi-LAN] | 245 | | | | | 246 | | | | | 247 | | | [Appl. Platform] | 248 | IP Transport Network | | | 249 +----------------------------------------+ +-------------------+ 251 Figure 1 Architecture for mobile and transport network 253 2.1. GTP tunneling 255 GTP-U tunnels are used to carry encapsulated T-PDUs and signalling 256 messages between a given pair of GTP-U Tunnel Endpoints. The Tunnel 257 Endpoint ID (TEID) which is present in the GTP header shall indicate 258 which tunnel a particular T-PDU belongs to. In this manner, packets 259 are multiplexed and de-multiplexed by GTP-U between a given pair of 260 Tunnel Endpoints. G-PDU is user data packet (T-PDU) plus GTP-U 261 header, sent between GTP network nodes. T-PDU is a user data packet, 262 for example an IP datagram, sent between a UE and a network entity 263 in an external packet data network. A T-PDU is the payload that is 264 tunneled in the GTP-U tunnel [3GPP TS 29.281]. 266 GTPv1-U tunnel endpoints do not need to perform any IP routing 267 functions in respect to inner IP packet since it shall be 268 encapsulated at the GTPv1-U sender with a GTP header, Outer UDP and 269 IP header. 271 Outer UDP/IP is the only path protocol defined to transfer GTP 272 messages in a mobile network. The UDP source port may be allocated 273 dynamically by the sending GTP-U entity. Dynamic allocation of the 274 UDP source port may help balancing the load in the network even 275 though the scheme does not allow to deterministically force a 276 specific path, using ECMP. 278 For illustration, Figure 2 shows how the GTP encapsulation process 279 works. The user data packet itself including the header and payload 280 is preserved and kept unchanged. The packet is just added a GTP 281 header used by the receiving end to identify which tunnel the packet 282 is associated to. This GTP encapsulated packet is transported 283 between the two tunnel endpoints using a transport layer header, 284 specifically an outer IP/UDP header. 286 +----------+-----------+--------+----------+-----------+ 287 | Outer IP | Outer UDP | GTP-U | User Data Packet | 288 | Header | Header | Header | (IP datagram) | 289 +----------+-----------+--------+----------+-----------+ 290 |<-------------------->|<----------------------------->| 291 |Transport layer header| GTP-U message | 292 Figure 2 GTP encapsulation 294 2.2. Quality of Service (QoS) 296 In a typical case, multiple applications may be running in a UE at 297 any time, each one having different QoS requirements. For example, a 298 UE can be engaged in a VoIP call while at the same time browsing a 299 web page or downloading an FTP file. VoIP has more stringent 300 requirements for QoS in terms of delay and delay jitter than web 301 browsing and FTP, while the latter requires a much lower packet loss 302 rate. In order to support multiple QoS requirements, different 303 bearers are set up within the Evolved Packet System, each being 304 associated with a QoS. 306 In the access network, it is the responsibility of the eNB to ensure 307 the necessary QoS for a bearer over the radio interface. Each bearer 308 has an associated QoS Class Identifier (QCI), and an Allocation and 309 Retention Priority (ARP). The QCI specifies values for the priority 310 handling, acceptable delay budget and packet loss rate for each QCI 311 label. The QCI label for a bearer determines how it is handled in 312 the eNB. 314 IP packets mapped to the same EPS bearer receive the same bearer- 315 level packet forwarding treatment. In order to provide different 316 bearer-level QoS, a separate EPS bearer must therefore be 317 established for each QoS flow. User IP packets must then be filtered 318 into the appropriate EPS bearers [3GPP TS.23.203]. 320 Meanwhile, considerations about traffic engineering schemes and 321 different QoS requirements would not explicitly mentioned until now 322 in terms of IP transport network. 324 In addition, a simple traffic engineering scheme using ECMP would 325 lead to no load balancing and result to inefficient use of transport 326 resources because mobile services have different type of application 327 and QoS requirements. Congestion on the shortest path link could be 328 difficult to avoid when network status is not normal, for example 329 the higher than usual traffic demand and dynamically changing 330 traffic patterns. 332 In this regard, segment routing is regarded as a good way to provide 333 traffic engineering and load balancing for IP transport network in 334 mobile environment. 336 3. Use case 338 The term "source" means "the point at which the explicit route is 339 imposed". Therefore GTP-U Tunnel Endpoint (e.g., eNB, S-GW, P-GW) 340 could be a "source" by applying segment routing. In addition, an EPS 341 bearer is typically associated with a QoS. Therefore, in order to 342 provide different bearer-level QoS, GTP-U Tunnel Endpoints could 343 ensure the necessary QoS for a bearer. With this the transport 344 network can provide a same level of QoS as much as mobile network 345 does. 347 LTE nodes (e.g., eNB, S-GW and P-GW) in overlay are connected to the 348 routers (e.g., A, B, C, etc.) in a transport network and have 349 interactions with each other via them. LTE components are assumed to 350 have multiple interfaces to the routers and an interface for packet 351 forwarding would be selected, depending on PCE's decision. PCE (Path 352 Computation Element) makes path computation using traffic matrix 353 that describes the bandwidth requirements between sources and 354 destinations in a network. 356 In order to more clearly explain use cases for a mobile network, LTE 357 nodes with multi-paths through IP transport nodes are shown in 358 Figure 3. Each LTE node is connected to IP transport nodes that have 359 corresponding two transport paths alternatively. Two shortest paths 360 between LTE nodes, B-C and G-H, are assumed respectively. Two 361 alternative paths between LTE nodes, A-E-D and F-I, are assumed 362 respectively. 364 An UE is connected to Internet (actually, a certain server) via both 365 mobile and transport nodes. In the example when the higher than 366 usual traffic is occurring, the shortest path between eNB and S-GW 367 as well as S-GW and P-GW (segment list B-C and G-H, respectively) 368 has low delay but is highly utilized. As a result, no load balancing 369 will happen and QoS requirements of the different applications will 370 not be satisfied. In this regard, an alternative path should be 371 selected by considering network status (segment list A-E-D and F-I, 372 respectively). With explicit path allocation to dynamically changing 373 traffic patterns, inefficient use of transport resources and QoS 374 degradations could be avoided. Therefore in a mobile network, 375 segment routing would lead to more optimal load distribution and 376 forwarding for different types of applications. 378 For example, a specific path would be chosen by analyzing QCI since 379 it could represent QoS characteristics in terms of packet delay and 380 packet loss. Higher delay and underutilized path could be used for 381 delivery of delay insensitive service as represented by QCI. 383 UE-----eNB=====S-GW=====P-GW----Internet 384 | \ / | |\ / | 385 A B-C D F G--H I 386 \ / \ | 387 E----+ +-----+ 389 Figure 3 LTE nodes connected to multi-paths via IP transport nodes 391 4. Security Considerations 393 This document doesn't introduce new security considerations when 394 applied to the MPLS dataplane. 396 There are a number of security concerns with source routing at the 397 IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header 398 defined in [I-D.ietf-6man-segment-routing-header] and its associated 399 security measures address these concerns. 401 5. IANA Considerations 403 This document does not require any action from IANA. 405 6. References 407 6.1. Normative References 409 None 411 6.2. Informative References 413 [3GPP TS.23.060] 415 "General Packet Radio Service (GPRS); Service description", 416 3GPP TS 23.060 13.3.0, June 2015. 418 [3GPP TS.23.203] 420 "Policy and charging control architecture", 3GPP TS 23.203 421 13.4.0, June 2015. 423 [3GPP TS.23.401] 425 "General Packet Radio Service (GPRS) enhancements for 426 Evolved Universal Terrestrial Radio Access Network (E- 427 UTRAN) access", 3GPP TS 23.401 12.3.0, December 2013. 429 [3GPP TS. 29.061] 431 "Interworking between the Public Land Mobile Network 432 (PLMN) supporting packet based services and Packet Data 433 Networks (PDN)", 3GPP TS 29.061 12.4.0, December 2013. 435 [3GPP TS. 29.274] 437 "3GPP Evolved Packet System (EPS); Evolved General Packet 438 Radio Service (GPRS) Tunnelling Protocol for Control plane 439 (GTPv2-C); Stage 3", 3GPP TS 29.274 13.2.0, June 2015. 441 [3GPP TS.29.281] 443 "General Packet Radio System (GPRS) Tunnelling Protocol 444 User Plane (GTPv1-U)", 3GPP TS 29.281 12.1.0, December 445 2014. 447 [draft-ietf-6man-segment-routing-header] 449 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 450 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 451 Routing Header (SRH)", draft-ietf-6man-segment-routing- 452 header-01 (work in progress), March 2016. 454 [draft-ietf-sfc-use-case-mobility] 455 W. Haeffner, J. Napper, M. Stiemerling, D. Lopez and J. 456 Uttaro, "Service Function Chaining Use Cases in Mobile 457 Networks", draft-ietf-sfc-use-case-mobility-01, July 2014. 459 [RFC7855] 461 S. Previdi, C. Filsfils, B. Decraene, S. Litkowski, R. 462 Geib, R. Shakir and R. Raszuk, " Source Packet Routing in 463 Networking (SPRING) Problem Statement and Requirements", 464 RFC 7855, May 2016. 466 [draft-ietf-spring-ipv6-use-cases] 468 J. Brzozowski, J. Leddy, I. Leung, S. Previdi, M. Townsley, 469 C. Martin, C. Filsfils and R. Maglione, "IPv6 SPRING Use 470 Cases", draft-ietf-spring-ipv6-use-cases-05, September 471 2015. 473 [RFC5095] 475 Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 476 of Type 0 Routing Headers in IPv6", RFC 5095, December 477 2007. 479 [wan-traffic-engineering] 481 "Wide Area Network Traffic Engineering", Ericsson White 482 Paper, December 2015. 484 7. Acknowledgments 486 TBD 488 Authors' Addresses 490 Jeongyun Kim (editor) 491 ETRI 492 218 Gajeong-ro, Yuseong-gu, Daejeon, 305-700, KR 494 Email: jykim@etri.re.kr 496 Gyu Myoung Lee 497 Liverpool John Moores University 498 James Parsons Building, Byrom Street, Liverpool, L3 3AF, UK 500 Email: G.M.Lee@ljmu.ac.uk