idnits 2.17.1 draft-matsushima-spring-dmm-srv6-mobile-uplane-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 17, 2017) is 2475 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: 'MN' is mentioned on line 191, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING and DMM S. Matsushima 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: January 18, 2018 Cisco Systems, Inc. 6 July 17, 2017 8 SRv6 for Mobile User-Plane 9 draft-matsushima-spring-dmm-srv6-mobile-uplane-01 11 Abstract 13 This document discusses the applicability of SRv6 (Segment Routing 14 IPv6) to user-plane of mobile networks that SRv6 source routing 15 capability with its programmability can fulfill the user-plane 16 functions, such as access and anchor functions. It takes advantage 17 of underlying layer awareness and flexibility to deploy user-plane 18 functions that enables optimizing data-path for applications. 19 Network slicing and an interworking way between SRv6 and existing 20 mobile user-plane are also discussed in this document. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 18, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 58 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . . 3 60 5. User-Plane Functions . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Access Node Segment . . . . . . . . . . . . . . . . . . . 5 62 5.2. Layer-2 Anchor Segment . . . . . . . . . . . . . . . . . 6 63 5.3. Layer-3 Anchor Segment . . . . . . . . . . . . . . . . . 6 64 5.4. Stateless Interworking Segment . . . . . . . . . . . . . 7 65 5.5. Rate Limit Segment . . . . . . . . . . . . . . . . . . . 8 66 6. Network Slicing Considerations . . . . . . . . . . . . . . . 8 67 7. Control Plane Considerations . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 10.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 In mobile networks, mobility management systems provide connectivity 78 while mobile nodes move around. While the control-plane of the 79 system signals movements of a mobile node, user-plane establishes 80 tunnel between the mobile node and anchor node over IP based backhaul 81 and core networks. 83 This document discusses the applicability of SRv6 (Segment Routing 84 IPv6) to those mobile networks. SRv6 provides source routing to 85 networks where operators can explicitly indicate route for the 86 packets from and to the mobile node. SRv6 endpoint nodes act as 87 roles of anchor of mobile user-plane. 89 2. Conventions and Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 All segment routing and SRv6 network programming terms are defined in 96 [I-D.ietf-spring-segment-routing] and 97 "[I-D.filsfils-spring-srv6-network-programming]. 99 3. Motivations 101 Today's and future applications are requiring highly optimized data- 102 path between mobile nodes and the entities of those applications in 103 perspectives of latency, bandwidth, etc,. However current 104 architecture of mobile management is agnostic about underlying 105 topologies of transport layer. It rigidly fragments the user-plane 106 in radio access, core and service networks and connects them by 107 tunneling techniques through the user-plane functions such as access 108 and anchor nodes. Those agnostic and rigidness make it difficult for 109 the operator to optimize the data-path. 111 While the mobile network industry has been trying to solve that, 112 applications shift to use IPv6 data-path and network operators adopt 113 it as their IP transport as well. SRv6 integrates both application 114 data-path and underlying transport layer in data-path optimization 115 aspects that does not require any other techniques. 117 SRv6 source routing capability with programmable functions 118 [I-D.filsfils-spring-srv6-network-programming] could fulfills the 119 user-plane functions of mobility management. It takes advantage of 120 underlying layer awareness and flexibility to deploy user-plane 121 functions. Those are the motivations to adopt SRv6 for mobile user- 122 plane. 124 4. Mobile User-Plane 126 This section describes user-plane using SRv6 for mobile networks. 127 This clarifies mobile user-plane functions to which SRv6 endpoint 128 applied. 130 Figure 1 shows mobile user-plane functions which are connected 131 through SRv6 enabled IPv6 networks. In the Figure 1, an mobile node 132 (MN) connects to an SRv6 endpoint serving access node role for the 133 MN. When the endpoint receives packets from the MN, it pushes SRH to 134 the packets. The segment list in the SRH indicates the rest of user- 135 plane segments which are L2 and L3 anchors respectively. Then the 136 endpoint send the packets to the SRv6 enabled IPv6 network. In 137 opposite direction, when an SRv6 endpoint serving L3 anchor role for 138 the MN receives packets to it, the endpoint push SRH consist of the 139 L2 anchor and access node segments to the packets. 141 User-plan 142 Function 143 144 O------O 145 | SRv6 | 146 | End | 147 | Point| 148 O------O 149 User-plan || User-plan 150 [MN] Function _____||_____ Function 151 | / \ 152 ___v___ O------O / \ O------O ________ 153 / Radio \ | SRv6 | / SRv6 \ | SRv6 | / \ 154 / Access \==| End |===/ enabled \===| End |===/ Service \ 155 \ NW / | Point| \ IPv6 / | Point| \ NW / 156 \________/ O------O \ NW / O------O \________/ 157 \ / 158 \____________/ 160 Figure 1: Mobile User-plane with SRv6 162 An SRv6 segment represents those each function, such as Access Node, 163 Layer-2 (L2) Anchor and Layer-3 (L3) Anchor. This makes mobile 164 networks highly flexible to deploy any user-plane functions to which 165 nodes in user flow basis. An SRv6 segment can represent a set of 166 flows in any granularity of aggregation even though it is just for a 167 single flow. 169 Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile 170 user-plane, which is defined in [RFC5213] and [TS.29281]. An SRv6 171 segment in the endpoint represents interworking function which 172 enables interworking between existing access node and SRv6 anchor 173 segment, or SRv6 access node segment and existing anchor node. 175 Existing mobile user-plane with IPv6 underlay is expected to be 176 widely deployed. As IPv6 network should be interoperable with SRv6 177 enabled network and SRv6 endpoints can be accommodated on it, 178 interworking with existing IPv6 network is out of scope of this 179 document. 181 ________ _______ 182 / \ O------O / \ 183 / Service \===|L2/L3 | / Service \ 184 \ NW / |Anchor| User-plan \ NW / 185 \________/ |Node | Function \_______/ 186 O------O || 187 \\_______ O------O ________ O------O 188 / \ | SRv6 | / SRv6 \ | SRv6 | 189 / Existing \===| End |===/ enabled \===| End | 190 \ IPv4 NW / | Point| \ IPv6 NW / | Point| 191 [MN] \________/ O------O \________/ O------O 192 | // || 193 ___v____ O------O ___||__ 194 / Radio \ | | / Radio \ 195 / Access \==|Access| [MN]~~~/ Access \ 196 \ NW / |Node | \ NW / 197 \________/ O------O \________/ 199 Figure 2: Interworking with Existing Mobile Networks 201 The detail of SRv6 segments representing user-plane functions are 202 described in Section 5. 204 5. User-Plane Functions 206 This section describes mobile user-plane functions applied to SRv6 207 segment. SRv6 endpoint is capable to do that. Terminology of 208 endpoint functions refers to the net-pgm draft. SRv6 endpoint 209 functions are considered for each direction, such as uplink (UL) from 210 mobile node to the correspondent node, and downlink (DL) from the 211 correspondent node to mobile node. 213 5.1. Access Node Segment 215 Access node segment provides SRv6 endpoint the role to which mobile 216 node is connected directly. eNodeB could be referenced as an entity 217 implementing the access node in 3GPP term. The applicable SRv6 218 functions for the access nodes are following: 220 UL: T.Insert, or T.Encaps 222 DL: End.X, or End.DX2/4 223 In uplink, an endpoint of an access node segment does T.Insert 224 process for the receiving packets from mobile node when the packets 225 matched to the policy bound to the segment in case IPv6 is the outer 226 header of the packet. When the header is IPv4, or other types, the 227 endpoint does T.Encap process for the packets. The segment list 228 represents policy of data-path for the flows from mobile node. 230 In downlink, the endpoint does End.X process for receiving packets 231 when the active segment represents access node to the mobile node. 232 When the segment left of receiving packets is zero, and IPv4 is 233 indicated as the effective next header (ENH), the endpoint does 234 End.DX4 process for the packets. When the ENH indicates layer-2 235 type, the endpoint does End.DX2 process for it. 237 5.2. Layer-2 Anchor Segment 239 Layer-2 anchor segment provides SRv6 endpoint the role to be anchor 240 point while mobile node move around within a serving area which could 241 be assumed as a layer-2 network. Serving Gateway (SGW) could be 242 referenced as an entity implementing the layer-2 anchor in 3GPP term. 243 The applicable SRv6 functions for the layer-2 anchor are following: 245 UL: End, or End.B6 247 DL: Same as UL 249 In uplink, an endpoint of a L2 anchor segment does End process for 250 the packets when the active segment represents the L2 anchor. When 251 the segment is bound to another policy of data-path, the endpoint 252 does End.B6 process for the packets to be inserted a SRH which 253 consists of segment list along with the policy. The last segment of 254 the inserted SRH must be the edge endpoint of the SRv6 domain of 255 mobile network. 257 In downlink, there's no difference between the uplink behavior. 259 5.3. Layer-3 Anchor Segment 261 Layer-3 anchor segment provides SRv6 endpoint the role to be anchor 262 point across a mobile network consists of multiple serving areas. 263 Packet data network gateway (PGW) could be referenced as an entity 264 implementing the layer-3 anchor. The applicable SRv6 functions for 265 the layer-3 anchor are following: 267 UL: End.T, End.DT4, or End.DX2 269 DL: T.Insert, or T.Encaps 270 In uplink, an endpoint of a L3 anchor segment does End.T process for 271 the packets when the active segment represents the L3 anchor and 272 specific IPv6 routing table is bound to it. Those routing tables may 273 be accommodated in the endpoint for networks which require individual 274 routing policies. When the segment left of receiving packet is zero 275 and IPv4 is indicated as the effective next header (ENH), the 276 endpoint does End.DT4 process for the packets with specific IPv4 277 routing table bound to the segment. When the ENH indicates layer-2 278 type, the endpoint does End.DX2 process for it. 280 In downlink, an endpoint of a L3 anchor segment does T.Insert process 281 for the packets when the IPv6 flow of packets matched to the policy 282 bound to the segment. When the matched flow is IPv4, or other types, 283 the endpoint does T.Encap process for the packets. The segment list 284 represents policy of data-path for the flows. 286 5.4. Stateless Interworking Segment 288 Interworking segment provides SRv6 endpoint the role to be 289 interworking point between existing mobile user-plane and SRv6 mobile 290 user-plane. It is expected that the endpoint of interworking segment 291 could be unaware from the control-plane of the mobility management. 292 While there are combinations of interworking either existing or SRv6 293 network in which user-plane functions accommodate, interworking 294 segment should cover all combinations without mobility state. 296 To fulfill the above requirements, SID for interworking segment is 297 encoding identifiers of corresponding tunnel in existing network as 298 argument of the SID. Tunnel encoding format in SID is following: 300 +----------------------+------+-------+-------+ 301 |Locater of interwork | DA | SA | Tun-ID| 302 +----------------------+------+-------+-------+ 303 128-a-b-c a b c 305 Figure 3: Stateless Interworking SID Encoding 307 In SRv6 to existing network direction, an endpoint of an interworking 308 segment allocate a node local SID prefix to interworking segments. 309 When the endpoint receives packet and the active segment of the 310 packet indicates the SID, the endpoint pop the SRH of the SID, and 311 then the endpoint encaps the payload with the encoded information in 312 the SID which are tunnel identifier of tunnel header, source and 313 destination IPv4 address of IPv4 header described in Figure 3. Then 314 the endpoint send out the packet to the existing network along with 315 its routing policy. 317 In existing network to SRv6 network direction, existing network 318 allocates IPv4 address spaces routed to interworking SRv6 network. 319 SRv6 network allocates a domain-wise SID prefix for interworking 320 segments. When a SRv6 endpoint connects to existing network receives 321 packet destined to the allocated IPv4 address, the endpoint decaps 322 outer IPv4 and tunnel header. And then the endpoint does T.Insert 323 process with the SID which consists of the allocated domain-wise SID 324 prefix, source and destination addresses, and tunnel identifier as 325 described in Figure 3. Then the endpoint send out the packet to the 326 SRv6 network along with its routing policy. 328 In case of IPv4 flow packet over the user-plane, the endpoint does 329 IPv6 header encaps and decaps instead of SRH insert and pop process. 330 The IPv6 header includes interworking segment SID in the SRH. 332 Noted that to make sure stateless interworking, entities of control- 333 plane in mobile management should cooperate with SRv6 user-plane 334 settings. Further control-plane consideration is discussed in 335 Section 7. 337 5.5. Rate Limit Segment 339 Mobile user-plane requires rate-limit feature. SID is able to encode 340 limiting rate as an argument in SID. Multiple flows of packets 341 should have same group identifier in SID when those flows are in an 342 same AMBR group. This helps to keep user-plane stateless. That 343 enables SRv6 endpoint nodes which are unaware from the mobile 344 control-plane information. Encoding format of rate limit segment SID 345 is following: 347 +----------------------+----------+-----------+ 348 | Locater of rate-limit| group-id | limit-rate| 349 +----------------------+----------+-----------+ 350 128-i-j i j 352 Figure 4: Stateless Interworking SID Encoding 354 6. Network Slicing Considerations 356 Mobile network may be required to create a network slicing that 357 represent a set of network resources and isolate those resource from 358 other slices. User-plane functions represented as SRv6 segments 359 would be part of a slice. 361 To represent a set of user-plane function segments for a slice, 362 sharing same prefix through those SIDs within the slice could be a 363 straightforward way. SIDs in a network slice may include other type 364 of functions in addition to the mobile user-plane functions described 365 in this document, and underlay integration to meet SLA and quality 366 requirements. 368 While network slicing has been discussed in the IETF and other 369 standardization bodies, what functionalities are required for network 370 slicing in mobile user-plane is further study item and to be 371 discussed. 373 7. Control Plane Considerations 375 Mobile control-plane entities must allocate SIDs to user-plane 376 function segments in case of those entities are distributed to 377 accommodate in the SRv6 endpoints, or those are separated from the 378 endpoint but each of them corresponds to each SRv6 endpoint. In 379 latter case, control-plane entity must advertise allocated SID to the 380 endpoint through some means. 382 When a centralized controller interfaces to mobile control-planes is 383 capable to allocate SIDs to the controlling SRv6 endpoints, the 384 mobile control-planes just need to indicate the endpoint nodes and 385 their user-plane roles to the controller. In this case, the 386 controller must allocate appropriate SIDs for the user-plane roles to 387 the indicated SRv6 endpoints. The controller must advertise 388 allocated SIDs to the endpoints. 390 To indicate endpoints and their user-plane functions from mobile 391 control-plane to user-plane, the endpoint or the controller could 392 take advantage of [I-D.ietf-dmm-fpc-cpdp]. It provides interface to 393 the control-plane to manage the user-plane of mobile networks. 395 In case of stateless interworking, SID allocating entity needs to be 396 aware SID prefix which interworking SRv6 endpoint and SRv6 domain 397 allocate discussed in Section 5.4. The mobile control-plane also 398 need to allocate tunnel endpoint IPv4 address to which corresponding 399 interworking segment destined from existing user-plane that is also 400 discussed in Section 5.4. 402 8. Security Considerations 404 TBD 406 9. IANA Considerations 408 This document has no actions for IANA. 410 10. References 412 10.1. Normative References 414 [I-D.filsfils-spring-srv6-network-programming] 415 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 416 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 417 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 418 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 419 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 420 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 421 Camarillo, "SRv6 Network Programming", draft-filsfils- 422 spring-srv6-network-programming-01 (work in progress), 423 June 2017. 425 [I-D.ietf-spring-segment-routing] 426 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 427 and R. Shakir, "Segment Routing Architecture", draft-ietf- 428 spring-segment-routing-12 (work in progress), June 2017. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 10.2. Informative References 437 [I-D.ietf-dmm-fpc-cpdp] 438 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 439 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 440 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-07 441 (work in progress), March 2017. 443 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 444 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 445 RFC 5213, DOI 10.17487/RFC5213, August 2008, 446 . 448 [TS.29281] 449 3GPP, , "General Packet Radio System (GPRS) Tunnelling 450 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 451 September 2011. 453 Authors' Addresses 454 Satoru Matsushima 455 SoftBank 456 Tokyo 457 Japan 459 Email: satoru.matsushima@g.softbank.co.jp 461 Clarence Filsfils 462 Cisco Systems, Inc. 463 Belgium 465 Email: cf@cisco.com