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 <MEC_ULA_Preifx: Hashed_URL>.
   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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

7.2.  Informative Referenc

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

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]