...

Main Function:  the module is invoked by traffic controller after traffic controller recievesreceives
                          intents from external world, and parses requests from traffic controller and
                          extracts some key information to assemble a new yaml file for creating instances
                          of inbound services and clients based on istio.

Main OpearationsOperations:

1. create/destroy inbound services (API: Add Inbound service)
2. create/destroy client services (API: Add Clients)
3. create/remove security details for client services (API: Add Security details for clients)
4. create/destroy ServiceEntry for inbound services used by clients
5. create/destroy DestinationRules for both inbound and client services
6. create/destroy VirtualService for client services
7. create/destroy AuthorizationPolicy for inbound services used by clients

The key inforamtion information includes but not limited:

...

The interface between SM config and Traffic Controller: maybe via gPRC, and APIs are TBD

Traffic Controller

Main Function:  it acts as main controlling loop/daemon, and receives the request in a form of
                         REST from external modules e.g. orchestrator. Then it parses these requests and
                         figures out the exact purposes which these requests want to express
                         e.g. service creation, DNS update or workload adjust. Afterwards, it invoke corresponding
                         components like SM config, DNS updater, to fulfill these requirements by creating
                         and configuring related uServices based on the various mechanisms of istio.

...

4. Traffic controller may need to notify orchestrator that it, including the plugins,
    is ready to serve (which API provided by orchestrator should be invoked?).

5. At this moment, orchestrator can start to monitor and manage the life-cycle of traffic controller.
    controller. And the way/APIs of monitor and manage need to be clarified.
    (Is HA is required for traffic controller?)

6. The requests from users/admin can be sent to traffic controller from now on.
    usersUsers/admin are allowed to send their request to create uServices or access the running
    uServices directly by REST.

7. Traffic controller may need to manage the lifecycle of uServices (or done by orchestrator?)
    by detecting the heartbeat from various uServices periodically e.g. one check per 10 seconds.

8. Considering the HA, traffic controller should instantiate at least 2 of those plugins, and should be
    able to monitor the health of those instances of plugins. when any of instances is down, traffic controller
    can restart/recreate one for it againvia REST, like the inbound/client services creation. After traffic controller
    convert the intents to service description, the generated yml files which will be used by istio
    to create uSevices should be given to workload scheduler/placement helper to place and
    instantiate these uService on edge cloud clusters. Namely, traffic controller need to inform
    the workload scheduler/placement helper that there are some uServices to be placed and
    instantiated on edge cloud clusters.

7. Traffic controller need to call DNS module to expose the domain names of services to external world, 
    after it is aware of these uServices have been instantiated on edge cloud clusters. (how is traffic controller 
    aware of the accomplishment of of uServices instantiation?)

8. Traffic controller may need to manage the lifecycle of uServices (or done by some modules within orchestrator?)
    by a way e.g. detecting the heartbeat from various uServices periodically e.g. one check per 10 seconds.

9. Considering the HA, traffic controller should instantiate at least 2 of those plugins, and should be
    able to monitor the health of those instances of plugins. when any of instances is down, traffic controller
    can restart/recreate one for it again.

LoadBalancer (aka GSLB/LB controller?)

GSLB(Geo-replicated Services LB/LB controller) is used to balance incoming load across multiple istio-ingress-gateways.
It shall be able to be aware of the run-time load of various working uService instances which are distributed on different
edge clouds or the general load level of each kind of uService in each edge cloud by interacting with actual LB(e.g. metallb,
or other module except metallb) running on one edge cloud. Metallb is responsible for the load balance jobs between instances
of uService within an edge cloud, while GSLB(controller) shall be in charge of guiding the traffic load to multiple edge clouds.
GSLB(LB controller) should be aware of  the public IPs (achieved by using metallb? or SDWAN?) of all edge clouds. 

GSLB(LB controller) get requests from external users, and it evaluates the load level of the uServices that the user want to access
on various edge clouds, and then choose one certain edge cloud on which the targeted(or a set of) uService instance is running, 
next GSLB returns the domain name of the chosen uService instance to users, so users can utilize this new domain name to access
their expected uService. These steps mentioned above imply that those domain names associated with different uServices distributed
on edge clouds should point to the IP address of center cloud on which GSLB is running first, after GSLB figure out to which edge cloud
the users' request should be forwarded, the real domain name of uServices is given back to users by GSLB.

....

Sequence flows

Test cases

...