idnits 2.17.1 draft-du-intarea-service-routing-in-mec-00.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 (December 22, 2021) is 856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1035' is mentioned on line 167, but not defined == Unused Reference: 'RFC4291' is defined on line 157, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft China Mobile 4 Intended status: Informational December 22, 2021 5 Expires: June 25, 2022 7 Service Routing in Multi-access Edge Computing 8 draft-du-intarea-service-routing-in-mec-00 10 Abstract 12 This document introduces a service routing mechanism in the scenario 13 of Multi-access Edge Computing. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 25, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Proposed Mechanism Description . . . . . . . . . . . . . . . 2 57 3. SR IP Address . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative Referenc . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 The operators are deploying Multi-access Edge Computing (MEC) to 69 provide services with lower latency to their users. Comparing to 70 accessing service in the cloud, the MECs can provide service much 71 nearer to the users. 73 However, in the current architecture of Internet, we need to send a 74 DNS request to get the IP address of the service firstly, and then 75 access the service [RFC1035]. It is not the optimal solution in the 76 MEC scenarios which are sensitive to the latency of service 77 accessing. In this document, we introduce a mechanism that can 78 access the service directly without the DNS procedure. 80 In the 5G architecture, a UE (User Equipment) need to connect to a 81 UPF (User Plane Function) working as a gateway, and then access 82 service via the destination IP address. 84 In the scenarios of MEC, the service may be accessed within the MEC, 85 meanwhile the MEC also provides a UPF Function for the UEs. 86 Therefore, in fact, the service access takes place in a limited 87 domain [RFC8799]. In this limited domain, we can use a specific IP 88 address to directly access the service. 90 2. Proposed Mechanism Description 92 In the proposed mechanism, a UE should have a session with the UPF in 93 the MEC. Also, the UE should be aware that it can access the service 94 more quickly within the MEC if the service is available in the MEC. 95 The proposed mechanism is described briefly as below. 97 Firstly, the UE send a normal DNS request if it wants to access a 98 service, such as "www.local-weather.com". Meanwhile, it can make a 99 destination IP address itself by hashing the URL, and try to 100 establish a TCP connection directly. 102 Secondly, the UE may establish the connection successfully by using 103 the specific IP address, and get access to the service bypassing the 104 DNS procedure. If it fails, the UE can wait for the normal 105 destination IP address received from the DNS procedure. 107 In this mechanism, the IP address can contain some information about 108 the service, so we call it service routing in this document. The 109 specific IP address is called the Service Routing IP address or the 110 SR IP address. 112 3. SR IP Address 114 There are many options for the Service Routing IP address. 116 In the first option, we can assume that the UE can receive an MEC 117 prefix for the service routing in the procedure of establishing the 118 session between the UE and the UPF in the MEC. For example, an MEC 119 prefix is 64 bits, and the hashed URL is also 64 bits. In the MEC, 120 the server of the service should use the same hash algorithm to 121 generate the SR IP address, and the 128 bits IPv6 address should be 122 routed correctly within the MEC. Hence, the MEC works like a virtual 123 network node containing services, with the MEC prefix as a Location, 124 and the hashed URL as a Function. 126 In the second option, we can use a ULA IP address for the SR IP 127 address [RFC8799]. The procedure is similar to the first option, but 128 the SR IP address becomes the format of . 129 The MEC_ULA_Prefix contains a specific subnet-ID. 131 In the last option, we can use all the 128 bits as the Hashed_URL. 132 In this situation, the UE does not need to receive a specific prefix 133 in advanced, and all the services in different MECs have the same IP 134 address for the same service to support this quick access. 136 4. IANA Considerations 138 TBD. 140 5. Security Considerations 142 TBD. 144 6. Acknowledgements 146 TBD. 148 7. References 150 7.1. Normative References 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, 154 DOI 10.17487/RFC2119, March 1997, 155 . 157 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 158 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 159 2006, . 161 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 162 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 163 . 165 7.2. Informative Referenc 167 [RFC1035] Mockapetris, P., "Domain names - implementation and 168 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 169 November 1987, . 171 Author's Address 173 Zongpeng Du 174 China Mobile 175 No.32 XuanWuMen West Street 176 Beijing 100053 177 China 179 Email: duzongpeng@foxmail.com