SPRING and DMM S. Matsushima Internet-Draft SoftBank Intended status: Standards Track C. Filsfils Expires: January 18, 2018 Cisco Systems, Inc. July 17, 2017 SRv6 for Mobile User-Plane draft-matsushima-spring-dmm-srv6-mobile-uplane-01 Abstract This document discusses the applicability of SRv6 (Segment Routing IPv6) to user-plane of mobile networks that SRv6 source routing capability with its programmability can fulfill the user-plane functions, such as access and anchor functions. It takes advantage of underlying layer awareness and flexibility to deploy user-plane functions that enables optimizing data-path for applications. Network slicing and an interworking way between SRv6 and existing mobile user-plane are also discussed in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 18, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Matsushima & Filsfils Expires January 18, 2018 [Page 1] Internet-Draft SRv6-mobile-uplane July 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . . 3 5. User-Plane Functions . . . . . . . . . . . . . . . . . . . . 5 5.1. Access Node Segment . . . . . . . . . . . . . . . . . . . 5 5.2. Layer-2 Anchor Segment . . . . . . . . . . . . . . . . . 6 5.3. Layer-3 Anchor Segment . . . . . . . . . . . . . . . . . 6 5.4. Stateless Interworking Segment . . . . . . . . . . . . . 7 5.5. Rate Limit Segment . . . . . . . . . . . . . . . . . . . 8 6. Network Slicing Considerations . . . . . . . . . . . . . . . 8 7. Control Plane Considerations . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In mobile networks, mobility management systems provide connectivity while mobile nodes move around. While the control-plane of the system signals movements of a mobile node, user-plane establishes tunnel between the mobile node and anchor node over IP based backhaul and core networks. This document discusses the applicability of SRv6 (Segment Routing IPv6) to those mobile networks. SRv6 provides source routing to networks where operators can explicitly indicate route for the packets from and to the mobile node. SRv6 endpoint nodes act as roles of anchor of mobile user-plane. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Matsushima & Filsfils Expires January 18, 2018 [Page 2] Internet-Draft SRv6-mobile-uplane July 2017 All segment routing and SRv6 network programming terms are defined in [I-D.ietf-spring-segment-routing] and "[I-D.filsfils-spring-srv6-network-programming]. 3. Motivations Today's and future applications are requiring highly optimized data- path between mobile nodes and the entities of those applications in perspectives of latency, bandwidth, etc,. However current architecture of mobile management is agnostic about underlying topologies of transport layer. It rigidly fragments the user-plane in radio access, core and service networks and connects them by tunneling techniques through the user-plane functions such as access and anchor nodes. Those agnostic and rigidness make it difficult for the operator to optimize the data-path. While the mobile network industry has been trying to solve that, applications shift to use IPv6 data-path and network operators adopt it as their IP transport as well. SRv6 integrates both application data-path and underlying transport layer in data-path optimization aspects that does not require any other techniques. SRv6 source routing capability with programmable functions [I-D.filsfils-spring-srv6-network-programming] could fulfills the user-plane functions of mobility management. It takes advantage of underlying layer awareness and flexibility to deploy user-plane functions. Those are the motivations to adopt SRv6 for mobile user- plane. 4. Mobile User-Plane This section describes user-plane using SRv6 for mobile networks. This clarifies mobile user-plane functions to which SRv6 endpoint applied. Figure 1 shows mobile user-plane functions which are connected through SRv6 enabled IPv6 networks. In the Figure 1, an mobile node (MN) connects to an SRv6 endpoint serving access node role for the MN. When the endpoint receives packets from the MN, it pushes SRH to the packets. The segment list in the SRH indicates the rest of user- plane segments which are L2 and L3 anchors respectively. Then the endpoint send the packets to the SRv6 enabled IPv6 network. In opposite direction, when an SRv6 endpoint serving L3 anchor role for the MN receives packets to it, the endpoint push SRH consist of the L2 anchor and access node segments to the packets. Matsushima & Filsfils Expires January 18, 2018 [Page 3] Internet-Draft SRv6-mobile-uplane July 2017 User-plan Function O------O | SRv6 | | End | | Point| O------O User-plan || User-plan [MN] Function _____||_____ Function | / \ ___v___ O------O / \ O------O ________ / Radio \ | SRv6 | / SRv6 \ | SRv6 | / \ / Access \==| End |===/ enabled \===| End |===/ Service \ \ NW / | Point| \ IPv6 / | Point| \ NW / \________/ O------O \ NW / O------O \________/ \ / \____________/ Figure 1: Mobile User-plane with SRv6 An SRv6 segment represents those each function, such as Access Node, Layer-2 (L2) Anchor and Layer-3 (L3) Anchor. This makes mobile networks highly flexible to deploy any user-plane functions to which nodes in user flow basis. An SRv6 segment can represent a set of flows in any granularity of aggregation even though it is just for a single flow. Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile user-plane, which is defined in [RFC5213] and [TS.29281]. An SRv6 segment in the endpoint represents interworking function which enables interworking between existing access node and SRv6 anchor segment, or SRv6 access node segment and existing anchor node. Existing mobile user-plane with IPv6 underlay is expected to be widely deployed. As IPv6 network should be interoperable with SRv6 enabled network and SRv6 endpoints can be accommodated on it, interworking with existing IPv6 network is out of scope of this document. Matsushima & Filsfils Expires January 18, 2018 [Page 4] Internet-Draft SRv6-mobile-uplane July 2017 ________ _______ / \ O------O / \ / Service \===|L2/L3 | / Service \ \ NW / |Anchor| User-plan \ NW / \________/ |Node | Function \_______/ O------O || \\_______ O------O ________ O------O / \ | SRv6 | / SRv6 \ | SRv6 | / Existing \===| End |===/ enabled \===| End | \ IPv4 NW / | Point| \ IPv6 NW / | Point| [MN] \________/ O------O \________/ O------O | // || ___v____ O------O ___||__ / Radio \ | | / Radio \ / Access \==|Access| [MN]~~~/ Access \ \ NW / |Node | \ NW / \________/ O------O \________/ Figure 2: Interworking with Existing Mobile Networks The detail of SRv6 segments representing user-plane functions are described in Section 5. 5. User-Plane Functions This section describes mobile user-plane functions applied to SRv6 segment. SRv6 endpoint is capable to do that. Terminology of endpoint functions refers to the net-pgm draft. SRv6 endpoint functions are considered for each direction, such as uplink (UL) from mobile node to the correspondent node, and downlink (DL) from the correspondent node to mobile node. 5.1. Access Node Segment Access node segment provides SRv6 endpoint the role to which mobile node is connected directly. eNodeB could be referenced as an entity implementing the access node in 3GPP term. The applicable SRv6 functions for the access nodes are following: UL: T.Insert, or T.Encaps DL: End.X, or End.DX2/4 Matsushima & Filsfils Expires January 18, 2018 [Page 5] Internet-Draft SRv6-mobile-uplane July 2017 In uplink, an endpoint of an access node segment does T.Insert process for the receiving packets from mobile node when the packets matched to the policy bound to the segment in case IPv6 is the outer header of the packet. When the header is IPv4, or other types, the endpoint does T.Encap process for the packets. The segment list represents policy of data-path for the flows from mobile node. In downlink, the endpoint does End.X process for receiving packets when the active segment represents access node to the mobile node. When the segment left of receiving packets is zero, and IPv4 is indicated as the effective next header (ENH), the endpoint does End.DX4 process for the packets. When the ENH indicates layer-2 type, the endpoint does End.DX2 process for it. 5.2. Layer-2 Anchor Segment Layer-2 anchor segment provides SRv6 endpoint the role to be anchor point while mobile node move around within a serving area which could be assumed as a layer-2 network. Serving Gateway (SGW) could be referenced as an entity implementing the layer-2 anchor in 3GPP term. The applicable SRv6 functions for the layer-2 anchor are following: UL: End, or End.B6 DL: Same as UL In uplink, an endpoint of a L2 anchor segment does End process for the packets when the active segment represents the L2 anchor. When the segment is bound to another policy of data-path, the endpoint does End.B6 process for the packets to be inserted a SRH which consists of segment list along with the policy. The last segment of the inserted SRH must be the edge endpoint of the SRv6 domain of mobile network. In downlink, there's no difference between the uplink behavior. 5.3. Layer-3 Anchor Segment Layer-3 anchor segment provides SRv6 endpoint the role to be anchor point across a mobile network consists of multiple serving areas. Packet data network gateway (PGW) could be referenced as an entity implementing the layer-3 anchor. The applicable SRv6 functions for the layer-3 anchor are following: UL: End.T, End.DT4, or End.DX2 DL: T.Insert, or T.Encaps Matsushima & Filsfils Expires January 18, 2018 [Page 6] Internet-Draft SRv6-mobile-uplane July 2017 In uplink, an endpoint of a L3 anchor segment does End.T process for the packets when the active segment represents the L3 anchor and specific IPv6 routing table is bound to it. Those routing tables may be accommodated in the endpoint for networks which require individual routing policies. When the segment left of receiving packet is zero and IPv4 is indicated as the effective next header (ENH), the endpoint does End.DT4 process for the packets with specific IPv4 routing table bound to the segment. When the ENH indicates layer-2 type, the endpoint does End.DX2 process for it. In downlink, an endpoint of a L3 anchor segment does T.Insert process for the packets when the IPv6 flow of packets matched to the policy bound to the segment. When the matched flow is IPv4, or other types, the endpoint does T.Encap process for the packets. The segment list represents policy of data-path for the flows. 5.4. Stateless Interworking Segment Interworking segment provides SRv6 endpoint the role to be interworking point between existing mobile user-plane and SRv6 mobile user-plane. It is expected that the endpoint of interworking segment could be unaware from the control-plane of the mobility management. While there are combinations of interworking either existing or SRv6 network in which user-plane functions accommodate, interworking segment should cover all combinations without mobility state. To fulfill the above requirements, SID for interworking segment is encoding identifiers of corresponding tunnel in existing network as argument of the SID. Tunnel encoding format in SID is following: +----------------------+------+-------+-------+ |Locater of interwork | DA | SA | Tun-ID| +----------------------+------+-------+-------+ 128-a-b-c a b c Figure 3: Stateless Interworking SID Encoding In SRv6 to existing network direction, an endpoint of an interworking segment allocate a node local SID prefix to interworking segments. When the endpoint receives packet and the active segment of the packet indicates the SID, the endpoint pop the SRH of the SID, and then the endpoint encaps the payload with the encoded information in the SID which are tunnel identifier of tunnel header, source and destination IPv4 address of IPv4 header described in Figure 3. Then the endpoint send out the packet to the existing network along with its routing policy. Matsushima & Filsfils Expires January 18, 2018 [Page 7] Internet-Draft SRv6-mobile-uplane July 2017 In existing network to SRv6 network direction, existing network allocates IPv4 address spaces routed to interworking SRv6 network. SRv6 network allocates a domain-wise SID prefix for interworking segments. When a SRv6 endpoint connects to existing network receives packet destined to the allocated IPv4 address, the endpoint decaps outer IPv4 and tunnel header. And then the endpoint does T.Insert process with the SID which consists of the allocated domain-wise SID prefix, source and destination addresses, and tunnel identifier as described in Figure 3. Then the endpoint send out the packet to the SRv6 network along with its routing policy. In case of IPv4 flow packet over the user-plane, the endpoint does IPv6 header encaps and decaps instead of SRH insert and pop process. The IPv6 header includes interworking segment SID in the SRH. Noted that to make sure stateless interworking, entities of control- plane in mobile management should cooperate with SRv6 user-plane settings. Further control-plane consideration is discussed in Section 7. 5.5. Rate Limit Segment Mobile user-plane requires rate-limit feature. SID is able to encode limiting rate as an argument in SID. Multiple flows of packets should have same group identifier in SID when those flows are in an same AMBR group. This helps to keep user-plane stateless. That enables SRv6 endpoint nodes which are unaware from the mobile control-plane information. Encoding format of rate limit segment SID is following: +----------------------+----------+-----------+ | Locater of rate-limit| group-id | limit-rate| +----------------------+----------+-----------+ 128-i-j i j Figure 4: Stateless Interworking SID Encoding 6. Network Slicing Considerations Mobile network may be required to create a network slicing that represent a set of network resources and isolate those resource from other slices. User-plane functions represented as SRv6 segments would be part of a slice. To represent a set of user-plane function segments for a slice, sharing same prefix through those SIDs within the slice could be a Matsushima & Filsfils Expires January 18, 2018 [Page 8] Internet-Draft SRv6-mobile-uplane July 2017 straightforward way. SIDs in a network slice may include other type of functions in addition to the mobile user-plane functions described in this document, and underlay integration to meet SLA and quality requirements. While network slicing has been discussed in the IETF and other standardization bodies, what functionalities are required for network slicing in mobile user-plane is further study item and to be discussed. 7. Control Plane Considerations Mobile control-plane entities must allocate SIDs to user-plane function segments in case of those entities are distributed to accommodate in the SRv6 endpoints, or those are separated from the endpoint but each of them corresponds to each SRv6 endpoint. In latter case, control-plane entity must advertise allocated SID to the endpoint through some means. When a centralized controller interfaces to mobile control-planes is capable to allocate SIDs to the controlling SRv6 endpoints, the mobile control-planes just need to indicate the endpoint nodes and their user-plane roles to the controller. In this case, the controller must allocate appropriate SIDs for the user-plane roles to the indicated SRv6 endpoints. The controller must advertise allocated SIDs to the endpoints. To indicate endpoints and their user-plane functions from mobile control-plane to user-plane, the endpoint or the controller could take advantage of [I-D.ietf-dmm-fpc-cpdp]. It provides interface to the control-plane to manage the user-plane of mobile networks. In case of stateless interworking, SID allocating entity needs to be aware SID prefix which interworking SRv6 endpoint and SRv6 domain allocate discussed in Section 5.4. The mobile control-plane also need to allocate tunnel endpoint IPv4 address to which corresponding interworking segment destined from existing user-plane that is also discussed in Section 5.4. 8. Security Considerations TBD 9. IANA Considerations This document has no actions for IANA. Matsushima & Filsfils Expires January 18, 2018 [Page 9] Internet-Draft SRv6-mobile-uplane July 2017 10. References 10.1. Normative References [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network Programming", draft-filsfils- spring-srv6-network-programming-01 (work in progress), June 2017. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-12 (work in progress), June 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.ietf-dmm-fpc-cpdp] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and C. Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-07 (work in progress), March 2017. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [TS.29281] 3GPP, , "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011. Authors' Addresses Matsushima & Filsfils Expires January 18, 2018 [Page 10] Internet-Draft SRv6-mobile-uplane July 2017 Satoru Matsushima SoftBank Tokyo Japan Email: satoru.matsushima@g.softbank.co.jp Clarence Filsfils Cisco Systems, Inc. Belgium Email: cf@cisco.com Matsushima & Filsfils Expires January 18, 2018 [Page 11]