Feature Design¶

MEP-Auth Module Related Features¶

MEP-auth provides APP authentication¶

The MEP-auth provides an authentication function for APP, provides a token application interface, and the APP may provide the correct signature to MEP-auth based on the AK/SK signature algorithm, obtain the token, and access the MEP-server related interface via the token.

The application of the APP through the MEP-auth request token is shown in the following figure:

Application uses Service Authentication Interface for token.
MEP-auth signs and issues token for ak/sk.
MEP-auth returns token.
The application carrying token is used for calling the service interface. You can call Application Service Management Related Interface, Available Event Subscription Related Interface, Termination Event Subscription Related Interface.
MEP-based-based jwt plugin checks token and route related requests to MEP-server.

For the token request interface, see the section “MEP features”.

MEP-auth provides configuration capabilities for API gateways¶

The MEP-auth module initializes the API gateway (kong):

Add a consumer in kong.
Configuring service and route for MEP-auth itself.
Configuring servcie and route for MEP-server.
Configure and enable the kong plugin for MEP-auth and MEP-server.

The plugins that MEP-auth opened in the initialization kong process include:

JWT plugin Provides token verification capability for the corresponding interface.
Appid-header plugin Insert X-AppinstanceID header in interface request for MEP-server check. Check request token’s client ip is consistent with client ip of calling interface.
Rate Limiting Plugin Provides flow control capability for MEP-auth and MEP-server interfaces.
IP Restriction Plugin Provides client IP white list function support for MEP-auth.
response-transformer plugin Provides the server header capability in clear response.
Pre-function plugin providing modified interface request x_forwarded_for capability.

MEP Sever Feature¶

MEP Service Governance Functions¶

Definition

The service management function refers to the ability of the MEP to register, update, delete, and query services.

Design principles

MEP provides service registration, updates, deletion, query related API interfaces. The application is able to register, update, delete, query through the LDVS-MEP service.

service registration, deleting

Application service status subscription/notification function¶

Definition

The application service status subscription/notification function is the ability to subscribe, update, delete, notify the LDVS for service status.

Design principles

MEP manages the status of application services, and applications register for services through MEP. When service consumers expect to use the services of the service provider, they need to subscribe to the service status of the service provider through MEP. Through the subscription interface, MEP can identify the service that the service consumer pays attention to, and when the service status changes, it can notify the service consumer of the related service status.

Applications can subscribe, update, delete, and query service status through LDVS-MEP.

MEP Service hearbeat¶

Each MEC service instance that has previously registered in MEC platform and is configured for heartbeat shall send heartbeat message to the MEC platform periodically in order to show that the MEC service instance is still operational. When the MEC platform has not received the heartbeat for a configurable amount of time, the MEC platform considers that the service instance can no longer be discovered and The service state will change to SUSPEND if it was ACTIVE before.

How to configure hearbeat for a service¶

Service register message will carry the livenessinterval field in it. It is an option field. If it is configured that indicate this service want to send heartbeat message. MEP platform support livenessinterval value is 60s. It will overwrite any value set by the service. Note: For details of service register message please check the interface doc.

How to send heartbeat message¶

Services which already has set livenessinterval in its register message should send hearbeat message to MEP. When service registers, its response message will carry the URL (liveness), using which service should send the heartbeat to MEP. Note: For details of hearbeat message please check the interface document.

EG-LDVS application integrated plugin mep-agent¶

Definition

LDVS MEP-Agent, as a rapid integration application adapter, realizes the functions of service configuration import and service registration.

Design principles

LDVS MEP manages the service of the application. The application needs to register its service in the MEP. The MEP-Agent acts as an adapter to import service information (including the application instance ID) to the application, and at the same time provides a configuration method to register the application’s service in the MEP.

MEP-Agent Get token API¶

MEP-Agent will run as sidecar along with application. If Apllication need to obtain token from mep for communication with services, it can query mep-agent api.

GET /mep-agent/v1/token

{
  "header": [
    {
      "key": "Content-Type",
      "value": "application/json"
    }
  ]
}

Return example

HTTP/1.1 200 OK
{
	"access_token":"xxxx",
	"token_type":"Bearer",
	"expires_in":"3600"
}

Capabilities(Service) query support¶

Definition

Once capabilities(services) registered to the mep, other applications can consume it. MEP support the listing of these capabilities(services) over Mm5 interface.

Design principles

The capability query interface is exposed over Mm5 interface to MECM module and it can be queried together or independently. Each capability consists of a list of the present consumers to it.

Query flow

DNS server features¶

The MEP platform provides the domain name resolution services to the applications deployed in the EdgeGallery MEC, which can be utilized by the device applications in UE. MEC platform receives the DNS configurations from the MEC management, which includes the FQDN(Fully Qualified Domain Name), IP address and related entries. MEC applications can later query or modify the state of these configurations.

The three major operations for DNS are:

DNS management operations.
Query configuration and Activation/Deactivation by the MEC applications.
DNS query by the device applications.

We will see each of these features in the below section.

DNS management operations¶

DNS configurations are created either by MECM modules during start-up or from the OSS directly. DNS management supports both create, update, query and delete operations.

Rule creation at start-up

DNS configurations are embedded in the application descriptor and MEO(Multi-access Edge Orchestrator) will get these information during the start-up of the application. Once MEO receives the application descriptor, it searches for the DNS related configurations and pass this information to the MEPM(MEC Platform Manager) module in the edge along with the start-up request on Mm3 interface.

Upon receiving the DNS configurations from MEO, MEPM send this request to the MEP server on Mm5 interface after deploying the MEC application.

Rule creation from OSS

DNS configurations can be updated from OSS directly over Mm2 interface through MEPM.

DNS configurations from MEC applications¶

MEC applications can query the DNS configurations created for it and can activate or deactivate the same. Activation or deactivation can be performed by modifying the state of the DNS configuration.

DNS query¶

Device application in the UE can query the DNS server for the domain name resolution. By default the DNS server will listen on the 53 port.

How to configure the DNS server?¶

The dns server in MEP runs inside a container and can be configured using few command line parameters.

Command

dnsserver [OPTION]...

Detailed list of the optional parameters are stated below.

Parameter	Type	Range/Length	Default	Description
-db	string	1~256	dbEgDns	Backend store db name
-port	number	1~65535	53	DNS server listening port
-managementPort	number	1~65535	8080	Management interface listening port
-connectionTimeout	number	2~50	2	Connection timeout
-ipAdd	string	Ipv4/Ipv6	0.0.0.0	DNS listening ip address
-managementIpAdd	string	Ipv4/Ipv6	0.0.0.0	Management interface listening ip address
-forwarder	string	Ipv4/Ipv6		DNS proxy server IP
-loadBalance	bool	true/false	false	For domain names with multiple ip address, enabling this option will perform loadbalancing by shuffling the response IP list

Example

$ dnsserver -port=8053 -managementPort=8080 -loadBalance -forwarder <some-dns-server>

HealthCheck¶

Source of demand¶

*EdgeGallery version planning

Requirement Description¶

*Support mec-m check its edge healthy condition

Usecase¶

MECM calls the center-side service HealthCheck-M to start the overall health check service
HealthCheck-M on the center side checks the edge nodes under its jurisdiction based on the mec list in the body when the MECM is called
Each edge node HealthCheck receives the check information from HealthCheck-M on the center side, and first self-checks the health of the internal mep/lcm. When the mep/lcm on the edge side is healthy, the edge node considers the edge node to be healthy
After the self-check is completed, the mutual check mechanism is started between the edge nodes, and the visited nodes mep/lcm are all healthy, the node is considered healthy
Each edge node feeds back the results of the mutual check after communication to HealthCheck-M, and HealthCheck-M starts the voting mechanism
The HealthCheck-M vote on the center side is that when a node receives more than half of the total number of mec lists, the center side considers this node to be healthy.
HealthCheck-M feeds back the voting results to MECM or the caller

Involving modules&&EPIC&&Story¶

*MECM

<200b> *The caller starts HealthCheck-M, and HealthCheck-M accesses MECM-inventory to obtain mec list

*MEP

<200b> *The edge side health checks the MEP condition of the node, and the node is considered healthy only when both MEP and LCM are healthy

*LCM

<200b> *The edge side health checks the MEP condition of the node, and the node is considered healthy only when both MEP and LCM are healthy

Business Process¶

Interface definition¶

	Method	URL	Body
center	GET	/health-check/v1/center/action/start
center	GET	/health-check/v1/center/health	{["checked ip" : string, "condition" : bool]}
edge	POST	/health-check/v1/edge/action/start	{"checker ip" : string, "edgeCheckInfo" : ["checked ip" : string, "condition" : bool]}
edge	GET	/health-check/v1/edge/health