Service Routing in Multi-access Edge Computing
draft-du-intarea-service-routing-in-mec-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Zongpeng Du | ||
| Last updated | 2021-12-22 | ||
| Stream | (None) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-du-intarea-service-routing-in-mec-00
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]