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.
(b) If either Party intends to disclose to a customer details with respect to such Party’s: (i) development of a component to be added to the MP DSLAM Cooperative Reference Design, or (ii) change to any component already included in the MP DSLAM Cooperative Reference Design; such Party shall disclose such details to the other Party in writing at least as soon as disclosing such details to the customer; provided, however, that the foregoing obligations shall not apply with respect to changes that do not have a material impact on the other Party’s Component Products (as implemented in the MP DSLAM Cooperative Reference Design) or the MP DSLAM Cooperative Reference Design as a whole.
(c) If Wintegra discovers any material discrepancy between the published specifications for its Component Product and actual performance of such Component Product in connection with the MP DSLAM Cooperative Reference Design, such that it may affect the interface between the TI Components and the Wintegra Components or the operation of the Wintegra Components, it will immediately alert TI as to the nature of this discrepancy and what steps, if any, will be taken to correct such discrepancy. If TI discovers any material discrepancy between the published specifications for its Component Product and actual performance of such Components Products such that if may affect the interface between the TI Components and the Wintegra Components or the operation of the Wintegra Components, TI will immediately alert Wintegra as to the nature of this discrepancy and what steps, if any, will be taken to correct such discrepancy.
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. The Trust Management Framework will launch the startDataCollection method (see sec. 2.1 of deliverable
4.1 for details). Such capability will create new Data Lake pipeline that will retrieve trust information for each 5GZORRO Platform Participant using the two templates defined in sec. 5.1 of deliverable 4.1 (ref. step 5 in Figure 2-1). As an outcome of this step, the Data Lake platform will generate a new input and output Xxxxx topics which will be forwarded to the Trust Management Framework. It should be outlined that Data Lake ought to gather infor...
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: 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. 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.
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.
1. In this section we describe the updates to such set of features and also the initial software design of the components that were not ready to be reported in D4.1. Figure 4-1 shows to two main elements building the VRM and their relationship with the other components of the 5GZORRO platform. The Resource Manager contains the logic to manage the resource DB and interact with the Resource and Service Offer Catalogue (RSOC), which is the target of the resource definition translation process. The Resource Manager also offers an interface the MDA exploits for retrieving information used to reach the different components of the 5G Virtualisation platform, namely NFVO, VIM, Radio and Network Controller. Same interface is exploited by the e-Licensing modules to retrieve the coordinates to access the NFVO. Focusing into the Resource Manager module, it consists of several modules in charge to implement the functionality of resource storage (descriptors and, where required, packages), model translation, and 5G virtualisation infrastructure DB, as depicted in Figure 4-2. The Infrastructure GW provides the interface and the logic to access the underlying 5G Virtualised infrastructure, avoiding the need for components like MDA and e-Licensing modules to directly access the provider internal infrastructure. The Resource DB contains the resource definitions expressed in terms of descriptors and, when required, in terms of references to certain resource packages (e.g., the DB contains a VNF descriptor and a reference to the corresponding VNF package). The resource DB is managed by the Resource Manager Catalogue Handler (RMCH) that offers the interface and the logic to access to the resource information. The connection between the RM Catalogue Handler and the 5G Virtualised Infrastructure represents the capability of the Resource Manager to access the internal catalogues of the different elements to add (onboard), update, and remove resources. Finally, the Resource Definition Translator pro...
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.
