Service Routing in Multi-access
Edge Computing
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China
duzongpeng@foxmail.com
Internet Area
Network Working Group
MEC, Service Routing
This document introduces a service routing mechanism in the scenario
of Multi-access Edge Computing.
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.
The operators are deploying Multi-access Edge Computing (MEC) to
provide services with lower latency to their users. Comparing to
accessing service in the clouds, the MECs can provide service much
nearer to the users.
However, in the current architecture of Internet, we need to send a
DNS query to get the IP address of the service firstly, and then access
the service . 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 by using a tunnel, 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 . In this limited domain, we can use a specific IP
address to directly access the service.
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.
Firstly, the UE send a normal DNS query 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 domain name, 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 specific 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.
There are several 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, the length
of an MEC prefix is 64 bits, and the length of the hashed domain name is
also 64 bits. In the MEC, the server of the service should use the same
hash algorithm to generate the Service Routing 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 domain name as a Function.
In the second option, we can use a ULA IP address (Unique Local
Address) for the Service Routing IP address .
The procedure is similar to the first option, but the Service Routing IP
address becomes the format of <MEC_ULA_Preifx:
Hashed_Domain_Name>. The MEC_ULA_Prefix contains a specific
subnet-ID.
In the last option, we can use all the 128 bits as the
Hashed_Domain_Name. 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.
In the MEC, the network should support forwarding the Service Routing
IP. In the client and server, they should support the binding of the
Service Routing IP and the traditional DA IP. The value of the Service
Routing IP exists mainly in the period of establishing the connection.
After the connection is established, we can use the normal DA IP
instead.
At the beginning of the adoption of the mechanism, we do not think
there would be too many essential services requiring this ultimate user
experience, so that we assume that there would be no Hash conflict
between the services. If the mechanism is adopted widely, and conflict
exists between hashed domain names in the MEC, we can enable the
mechanism only on the most essential service. Another option is to
change the HASH algorithm that is running on the clients and the severs
to make a better Hash result.
MEC can also support accessing via fixed clients. In this situation,
the BNG (Broadband Network Gateway) as the gateway of the client can
work similarly to the UPF. A tunnel between the BNG and the MEC may be
needed, and the MEC prefix can be obtained in the procedure of
authentication. In the authentication of a fixed client, a more static
session can be established because the client will not move.