Open Stack

Hi Srini/Sayeed,

Thanks a lot for the interesting points

If not  UE directly detecting the edge node, I was looking for the solution where the service request from UE will be redirected to the edge.


  1.  Pro-active Advertisement by the Edge Node and its capacity so that Orchestration engines can place those  based on certain criteria.
  2.  Node Discovery Process - Explicit discovery of available capacity from the DC/operations center.

I think these will hold good, if edge is installed/deployed and configured to communicate  to Edge Orchestrator. We can also provision the edge from the Orchestrator itself. In that case, we don't need advertise and discover the Edge node and it will be part of the inventory. But I think the former case is the better option.


  1.  A UE can then do an explicit attach to a service that is being advertised as part of the catalog. The Edge node can service that request. If there are multiple Edge nodes that can serve the request then based on the infra policy the “closest” edge node can service it.. that would be an infra/orchestration rule as to which Edge node serves that request - the policy defined in the orchestration engine can take into account things such as latency, capacity etc etc.
  2.  A UE can sign up for push notifications of services - As the UE enters the proximity of the "Edge zone” (can be defined as a service area for that Edge compute/nodes) the local node can take action to provide the service based on subscription models

For this process, we need changes in the UE I believe. Is there any documentation for more details?

Srini, I was looking for similar solutions in ONAP. The work you mentioned in OOF will be part of Dublin? Are you referring to FGPS?

Best Regards
Bharath T

________________________________
From: Azhar Sayeed <asayeed at redhat.com>
Sent: Wednesday, February 13, 2019 12:36 AM
To: Addepalli, Srinivasa R
Cc: bharath thiruveedula; edge-computing at lists.openstack.org; ramkik at vmware.com
Subject: Re: [Edge-computing] Edge Node locator

The way I have been thinking about this is the following..

You will have to separate infra functions such as the Edge Nodes from service functions such as applications that run on edge nodes and provide a service.

>From an Infra management point of view..


  1.  Pro-active Advertisement by the Edge Node and its capacity so that Orchestration engines can place those work loads based on certain criteria.
  2.  Node Discovery Process - Explicit discovery of available capacity from the DC/operations center.

Both of them can be achieved via a service bus/message bus architecture that uses pub/sub concepts where you publish information and subscribe to topics. Edge nodes need to participate in that service bus model. It makes the discovery process and provisioning of applications to Edge nodes a lot easier and doesn’t require yet another discovery protocol… This is the work best suited for Orchestrators - So perhaps ONAP

>From a UE point of view - A UE should not care where an edge node is located. UE does a normal attach process to the network. The network maps the available services and shows them to UE via a catalog or another mechanism. The UE decides to either attach to that service or sign up for push notifications. So


  1.  A UE can then do an explicit attach to a service that is being advertised as part of the catalog. The Edge node can service that request. If there are multiple Edge nodes that can serve the request then based on the infra policy the “closest” edge node can service it.. that would be an infra/orchestration rule as to which Edge node serves that request - the policy defined in the orchestration engine can take into account things such as latency, capacity etc etc.
  2.  A UE can sign up for push notifications of services - As the UE enters the proximity of the "Edge zone” (can be defined as a service area for that Edge compute/nodes) the local node can take action to provide the service based on subscription models

Bottom line, A UE should not care where the Edge node is.

Regards,
Azhar

On Feb 12, 2019, at 1:10 PM, Addepalli, Srinivasa R <srinivasa.r.addepalli at intel.com<mailto:srinivasa.r.addepalli at intel.com>> wrote:

Hi Bharath,

JFYI
This work is going on in ONAP (OOF project and Edge automation project).

Other possible projects are  MobileEdgeX and LFE EVE projects (These two are not yet open sourced).

ONAP OOF project intention is to figure out the best edge location for a given workload based on following criteria:

-        Latency/Distance with respect to UEs.
-        Availability of right hardware capabilities required for the workload.
-        Cost
-        Affinity and Anti-affinity rules
-        Etc…

Once ONAP OOF chooses the edge location to  place the workload, then ONAP (via Multi-Cloud project) will place the workload by calling Openstack API or K8S API etc…

You may want to check out ONAP project.

Thanks
Srini




Thanks
Srini


From: bharath thiruveedula [mailto:bharath_ves at hotmail.com]
Sent: Tuesday, February 12, 2019 9:52 AM
To: edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>
Subject: [Edge-computing] Edge Node locator

Hi ,

Disclaimer: I am not sure the question following is in the scope of this forum.

I am trying to understand the Edge Architecture from UE point of view. How an app in UE can detect what the nearest edge it has to contact and how does it know whether the app is provisioned in that edge or not?

Can you please share some pointers from this perspective?

Best Regards
Bharath T
_______________________________________________
Edge-computing mailing list
Edge-computing at lists.openstack.org<mailto:Edge-computing at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20190213/b442eb44/attachment-0001.html>