Network Working Group Z. Du Internet-Draft China Mobile Intended status: Informational December 22, 2021 Expires: June 25, 2022 Service Routing in Multi-access Edge Computing draft-du-intarea-service-routing-in-mec-00 Abstract This document introduces a service routing mechanism in the scenario of Multi-access Edge Computing. Requirements Language 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 RFC 2119 [RFC2119]. 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 https://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 June 25, 2022. Copyright Notice Copyright (c) 2021 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 (https://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 to this document. Code Components extracted from this document must Du Expires June 25, 2022 [Page 1] Internet-Draft Service Routing in MEC December 2021 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. Proposed Mechanism Description . . . . . . . . . . . . . . . 2 3. SR IP Address . . . . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative Referenc . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The operators are deploying Multi-access Edge Computing (MEC) to provide services with lower latency to their users. Comparing to accessing service in the cloud, the MECs can provide service much nearer to the users. However, in the current architecture of Internet, we need to send a DNS request to get the IP address of the service firstly, and then access the service [RFC1035]. It is not the optimal solution in the MEC scenarios which are sensitive to the latency of service accessing. In this document, we introduce a mechanism that can access the service directly without the DNS procedure. In the 5G architecture, a UE (User Equipment) need to connect to a UPF (User Plane Function) working as a gateway, and then access service via the destination IP address. In the scenarios of MEC, the service may be accessed within the MEC, meanwhile the MEC also provides a UPF Function for the UEs. Therefore, in fact, the service access takes place in a limited domain [RFC8799]. In this limited domain, we can use a specific IP address to directly access the service. 2. Proposed Mechanism Description In the proposed mechanism, a UE should have a session with the UPF in the MEC. Also, the UE should be aware that it can access the service more quickly within the MEC if the service is available in the MEC. The proposed mechanism is described briefly as below. Du Expires June 25, 2022 [Page 2] Internet-Draft Service Routing in MEC December 2021 Firstly, the UE send a normal DNS request if it wants to access a service, such as "www.local-weather.com". Meanwhile, it can make a destination IP address itself by hashing the URL, and try to establish a TCP connection directly. Secondly, the UE may establish the connection successfully by using the specific IP address, and get access to the service bypassing the DNS procedure. If it fails, the UE can wait for the normal destination IP address received from the DNS procedure. In this mechanism, the IP address can contain some information about the service, so we call it service routing in this document. The specific IP address is called the Service Routing IP address or the SR IP address. 3. SR IP Address There are many options for the Service Routing IP address. In the first option, we can assume that the UE can receive an MEC prefix for the service routing in the procedure of establishing the session between the UE and the UPF in the MEC. For example, an MEC prefix is 64 bits, and the hashed URL is also 64 bits. In the MEC, the server of the service should use the same hash algorithm to generate the SR IP address, and the 128 bits IPv6 address should be routed correctly within the MEC. Hence, the MEC works like a virtual network node containing services, with the MEC prefix as a Location, and the hashed URL as a Function. In the second option, we can use a ULA IP address for the SR IP address [RFC8799]. The procedure is similar to the first option, but the SR IP address becomes the format of . The MEC_ULA_Prefix contains a specific subnet-ID. In the last option, we can use all the 128 bits as the Hashed_URL. In this situation, the UE does not need to receive a specific prefix in advanced, and all the services in different MECs have the same IP address for the same service to support this quick access. 4. IANA Considerations TBD. 5. Security Considerations TBD. Du Expires June 25, 2022 [Page 3] Internet-Draft Service Routing in MEC December 2021 6. Acknowledgements TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . 7.2. Informative Referenc [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Author's Address Zongpeng Du China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: duzongpeng@foxmail.com Du Expires June 25, 2022 [Page 4]