Design Updates. (a) Each quarter during the Term, Wintegra and TI will discuss all subsystem improvements and modifications intended for the MP DSLAM Cooperative Reference Design and market conditions for the MP DSLAM Cooperative Reference Design, subject to the Parties’ respective confidentiality obligations to third parties.
Design Updates. Seller will have the right to change the manufacture and/or design of its Products if, in the judgment of Seller, such change does not alter the general function of the Products.
Design Updates. Novel considerations related to the integration of the Trust Management Framework with other 5GZORRO components (workflows) have emerged since the release of the related design in deliverable D4.1 (Jan. 2021). Therefore, a new internal workflow has been designed to better describe the interaction of the Trust Management Framework with other key modules and the triggered actions. As it can be observed in Figure 2-1, the Smart Resource and Service Discovery (SRSD) application module is the one in charge of launching the trust computation process for an initial list of offers pre-classified by the SRSD employing mechanisms such as intent-based priorities, imperative constraints and considerations provided by the consumer. Once the Trust Management Framework receives a set of offers to be evaluated, the framework will start the data collection process for each stakeholder associated with it. Hence, the following steps will be carried as many times as offers need to be assessed. The Trust Management Framework in each domain should possess a previously generated key pair (intra- domain keys), as well as a Decentralised Identifiers (DID). Each 5GZORRO Platform Participant of a particular domain must use the public key of its Trust Management Framework to share trust data into the Data Lake. Additionally, the Trust Management Framework should possess another global key pair (inter-domain keys) that could be used by other 5GZORRO Platform Participants (from other domains) in order to provide domain recommendations. These recommendations may subsequently be used by other participants who do not have previous information about a specific service or resource. Both key pairs (intra- and inter-domain) should be created by the Identity and Permission Manager before the 5GZORRO Platform Participant interacts with the Trust Management Framework. The impact of these changes is reflected in the workflow described in Figure 2-1. Figure 2-1: Trust Management Framework integration with SRSD and Data Lake The Trust Management Framework will launch the startDataCollection method (see sec. 2.1 of deliverable
Design Updates. No design update has occurred with respect to the deliverable D4.1. In fact, the main focus of the prototype for this intermediate 5GZORRO release has been on testing the SCONE framework capabilities.
Design Updates. Currently there are no design updates as the software modules described in the previous version of the deliverable seem to work well. Well-defined and standardized software platforms are currently deployed and in use.
Design Updates. From Deliverable D4.1, the main design change is related to the deployment in the module. Previously, each client of a domain had to be configured as a client of the domain to which the secure connection was to be generated. Now, the inter-domain security module is designed to be deployed in the network gateways of each domain, so that they act as an intermediary between the end entities and the external domain. This reduces the complexity of configuring each network entity acting as a VPN client to the external domain. It also reduces the number of credentials required for the authentication and secure connection generation process. According to this design change, it has been necessary to add new interfaces (see Table 2-5) that are required to generate the connection between gateways. In this way, the connection can be generated directly by calling functions of the gateway acting as a client. In this sense, these interfaces should have strong authentication requirements, allowing only to trigger its functionality to trusted entities from external domains. These new interfaces are: Table 2-5: Definition of new Inter-domain Security Establishment service interfaces Operation name: add_client Description This method adds a new client to the gateway acting as VPN server. The client is identified using its public key. Input Parameters Type Description client_public_key String Public key of the client to be added, in Curve25519 format. Output Parameters Type Description assigned_ip String Assigned IP to the new client. vpn_port Integer Port where the vpn server is running. server_public_key String Public key of the vpn server. Notes Operation name: remove_client Description This method adds a new client to the gateway acting as VPN server. The client is identified using its public key. Input Parameters Type Description ip_address_server String Public key of the client to be removed, in Curve25519 format. Output Parameters Type Description result Integer It indicates if the client public key has been removed successfully or not. Notes
Design Updates. There are no significant changes in the ISSM-WFM design since deliverable D4.1. In deliverable D2.3 [18], updated orchestration workflows have been presented which better capture the intended behaviours in scenarios such as cross-domain slice establishment, scale-out and optimization. Moreover, always in D2.3 updates have been provided about how ISSM-WFM integrates with the rest of the functional 5GZORRO architecture.
Design Updates. Main design updates originated on top of the design baseline provided in deliverable D4.1 are as follows: • The ISSM-O scope of operation has been split into two parts: (a) intra-domain and (b) inter-domain. The reason for this functional split is that ISSM-O does not have a centralized visibility into the MNOs’ NFVIs and inventories. Therefore, the inter-domain component performs optimization at the Marketplace level determining candidate domains for resource instantiation while the intra-domain component optimizes resource allocation within MNO domains. The intra-domain component of ISSM-O can be regarded as optional in the sense that each domain can use its own optimization tools to allocate resources within a domain. However, this task is far from trivial. Building on our previous work, we proposed an intra-domain approach as follows. • The ISSM-O intra-domain component is responsible for optimizing MNO's resource allocation. Unlike the ISSM-O inter-domain component that does not have any information about the resources, topology, and infrastructure inside the domains, ISSM-O intra-domain performs resource optimization with complete knowledge about the whole resources that are under the control of that specific MNO. The optimization in the domain mainly happens intending to minimize resource utilization and provisioning cost. The intra-domain ISSM-O is designed considering different types of computing, transport, and radio resources available to be allocated to the requests. Three objective functions have been identified to optimize various aspects of the network based on the MNO's desired goal: • The first objective function aims to minimize resource utilization for the MNO by dynamically allocating resources to the requests upon the need. Employing this approach enables the MNO to re-schedule the resource allocation in order to avoid resource under/over utilization. • The second objective function tries to avoid excessive usage of the transport links, and instead, it prefers to consolidate the workload of requests in close proximity of each other. • Finally, the third objective function performs a cost optimization trade-off inside the domain. Inside each domain, resources can have different usage costs for the MNO; therefore, achieving a cost- optimized resource allocation inside the domain can lead to many economic advantages.
Design Updates. The VRM is designed to be a multi-container application, with the aim to provide the high level of flexibility required to immediately tackle any changes/updates in both resource composition and in the underlying 5G virtualised infrastructure. Due to this and in part to the fact that some features are still under definition or design, the final composition of such set of containers may vary during the following design and implementation phases, up to the final version of the prototype.
Design Updates. The design and implementation of the NSSO has been evolved with a more mature definition and implementation of the interfaces between the different components, illustrated in Figure 4-5. In particular, the interface exposed to the ISSM has been defined based on the initial interface available from the software components and updated to allow passing IDs related to the 5G Offer transaction, which are passed to other modules to map resource allocations, and service instances to the smart contracts associated with the offer. The initial interfaces towards the Monitoring Data Aggregation (MDA) and the e-Licensing Manager modules have been established. Work is still ongoing to define the interface between the NSSO and the Network Service Mesh Manager (NSMM), to provision the connectivity between the different components of the end- to-end service, and between NSSOs in other domains to provision slices on top of 3rd party resources.
