Compliance of northbound API with GENIv3. Every XXXXX soGware module exposing the GENIv3 API must support the mandatory methods and arguments detailed in the GENIv3 interface [4], and shall support some of the optional arguments as long as they provide benefits to the experimenters or are commonly accepted by the third-party tools used by them. In Table 4.1 we present the supported GENIv3 methods with an indication of the arguments and the return values. Method Ingress Output GetVersion • options (not required) • geni_api • geni_api_version • geni_credential_types • geni_ad_rspec_versions • geni_request_rspec_versions ListResources • credentials • options (e.g. version, available, compressed) • advertisement RSpec Describe • URNs • credentials • options • list of slivers (x.x. XXX, alloca- tion/operation status, error) • manifest RSpec Allocate • slice URN • credentials • request RSpec • options • list of slivers • manifest RSpec Renew • URNs • credentials • expiration time • options • list of slivers (with the new expi- ration time) Provision • URNs • credentials • options (e.g. bes-effort, end- time, users) • list of slivers • manifest RSpec Status • URNS • credentials • options • list of slivers
Compliance of northbound API with GENIv3. In order to verify the compliance of the (M)RO northbound interface with the GENIv3 standard, we have used the OMNI client. The OMNI client is used to manually call each method validating the received output. It is worth noting that the tests were conducted having a single RM (or RO) as a remote peer of the (M)RO in order to have a simplest test environment. Moreover, the tests were repeated for every RM (i.e CRM, SDNRM, SERM and TNRM) and for the RO. During the tests, we verified that: • The methods must be concluded with zero errors reported on the screen • The sliver description must have a unique identifier for the resource (URN) • The expiration time must be reported • The status of the resource must be as expected • The manifest RSpec must include the details of the slice reservation
Compliance of northbound API with GENIv3. Having standard northbound interfaces is key for the interoperability between modules. In XXXXX, we deemed convenient to use the GENIv3 API as the northbound interface of every Resource Manager (RM). The wide usage of this API makes it possible for a module exposing this interface to integrate with any existing compliant client or federation network, and requiring little development effort to that. Also, a consistent northbound API was much needed to reduce development efforts on the orchestrator module. This being said, the exposed API must accept the required methods, the different mandatory arguments (credentials, user keys, expiration time), and options (geni_best_effort). The API may also allow optional ones (currently: geni_available, geni_compressed, geni_end_time; in the future: geni_allocate). The implementation, subsequent extensions and bug fixing have been performed taking the GENIv3 AM API documentation [4] as the main reference, whereas the validation has been performed manually through both OMNI and jFed.
Compliance of northbound API with GENIv3. The first item on the feature list attempts to determine whether the developed API complies with the standard. The motivation of these tests is to pinpoint if there is any lack of features or options, specially those that are compulsory. The tests were carried out through an automated testing module (jFed's automated testing), already existing in Fed4FIRE, and which can be manually invoked or consulted through the First-Level Support Fed4FIRE website [5]. Whichever the case, this module performs regular calls to the northbound GENIv3 APIs of SDNRM and checks that the following items work as expected: • Mandatory GENIv3 methods are supported by SDNRM. • Required arguments and options for the aforementioned methods are also supported. • Correctness and authenticity of the connections established with the SDNRM server. The aforementioned items are tested frequently, in an automatic fashion. Specifically, the following tests are checked: • Proper return of basic RM information. – Tested methods: GetVersion • Datapaths and ports available for use in each island. – Tested methods: ListResources • Proper reservation, provisioning, instantiation and description of resources. – Tested methods: Allocate, Provision, PerformOperationalAction, Describe • Appropriate instantiation of the OpenFlow FlowSpace. The validation of the GENIv3 API is performed in a very similar fashion for every XXXXX XX, taking into account natural differences in the internal behaviour and thus the behaviour on a reservation or provisioning procedure. All in all, validation is pretty much the same for all of them and therefore similar sections in the rest of the document will refer to this one for further details. In SDNRM, two additional methods are tested in a slightly different way: Renew (to extend the expiration date of a FlowSpace over time) and Status (retrieve the status for a number of FlowSpaces). The first feature was manually tested by using OMNI and jFed clients and validating that the expiration date was effectively extended (e.g. FlowSpaces would not be automatically un-granted past the original date, but only aGer the extended time). The second feature is internally served through the Describe method, which is included in the automated testing through the FLS portal and tools. The results of these tests are available as a specific section in the FLS Fed4FIRE website. This has been com- monly used by XXXXX developers and infrastructure administrators to ensure proper availability of th...
Compliance of northbound API with GENIv3. As explained previously for the SDNRM validation, exposing standard northbound interfaces is key for the inter- operability between modules. RMs in XXXXX use the GENIv3 API for that matter, which ensures easy integration with other infrastructures and almost direct usage by any client supporting GENIv3 API. The API exposed by CRM must accept the same required methods and arguments and shall accept some of the optional ones; as described in SDNRM's Compliance of northbound API with GENIv3 section. The validation of the interface has been carried out in the same way as well.
Compliance of northbound API with GENIv3. The implementation of this interface and its subsequent extensions and bug fixing was based on the GENIv3 AM API [4] documentation. On the other hand, the validation process must test the support for, at least, the mandatory methods, arguments and options. During validation, we checked that the following items work as expected: • Mandatory GENIv3 methods are supported by CRM. • Required arguments and options for the aforementioned methods are also supported. • Correctness and authenticity of the connections established with the CRM server. The aforementioned items are tested frequently, in an automatic fashion. Specifically, the following tests are checked: • Proper return of basic RM information (GetVersion method) and virtualisation servers available for use in each island (Listresources method). – Tested methods: GetVersion, ListResources. • Proper reservation, provisioning, instantiation and description of resources. – Tested methods: Allocate, Provision, PerformOperationalAction, Describe. • Appropriate instantiation and key contextualisation into the VMs. However, this does not cover the full set of methods of the API. Two methods are missing: Xxxxx (to extend the expiration date of a VM over time) and Status (retrieve the status of one or multiple VMs). The first fea- ture has been manually tested by using OMNI and jFed clients and validating that the expiration date had been effectively extended (e.g. VMs would not be automatically deleted passed the original date, but only aGer the extended time). The second feature is internally served through the Describe method, which is already covered by automated testing through the FLS portal and tools. The results of these tests are available as a specific section in the FLS Fed4FIRE website [5]. Such site is com- monly used by XXXXX developers and infrastructure administrators to ensure proper availability of the resources in their domain.
Compliance of northbound API with GENIv3. As for all the Resource Managers in the XXXXX soGware stack, the SERM must support the mandatory methods and arguments from the GENIv3 interface, as detailed in [4]. The list of GENIv3 methods and arguments that are supported by every RO and RM is detailed in Table 4.1. The GENIv3 API is based on three different type of Resource Specification: the advertisement, the request and the manifest RSpecs. The detailed structure of the XML documents are presented in the D3.3 deliverable. The example schemas can be found in the source code at modules/resource/manager/stitching-entity/test/delegate/geni/v3/rspecs folder of the XXXXX repository. Each incoming RSpec is compared and then validated against XML schemas released by the GENI group. That means that the SERM is fully compliant with the GENI system allowing us to provide a federation with the GENI testbed.
Compliance of northbound API with GENIv3. In order to verify the compliance of the SERM northbound interface with the GENIv3 standard the OMNI client has been used as a tool for invoking the tested methods. The OMNI client is used to manually call each method validating the received output. It is worth noting that the tests were conducted having a single SERM in order to have a simplest test environment. Moreover, the tests were repeated with invoking the methods by the RO The tests verified that: • the methods concluded with zero errors reported on the screen • the sliver description had a unique identifier for the resource (URN) • the expiration time was reported • the status of the resource was as expected • the manifest RSpec included the details of the slice reservation
Compliance of northbound API with GENIv3. The TNRM also utilises the GENIv3 API as northbound API to facilitate the interoperation between XXXXX modules. This exposed API must accept the required methods, the mandatory arguments (credentials, user keys, expiration time), and options (geni_best_effort). The API exposed by TNRM must accept the same required methods and arguments and shall accept some of the optional ones; as described in SDNRM's Compliance of northbound API with GENIv3 section. The validation of the interface has been carried out in the same way as well, being the only difference in validation the use of a centralised instance for TNRM, within AIST premises.
Compliance of northbound API with GENIv3. In order to verify the compliance of the TNRM northbound interface with the GENIv3 standard, we used the OMNI client to manually call each method and validate the received output. We checked that the following items work as expected: • Mandatory GENIv3 methods are supported by the TNRM. • Required arguments and options for the aforementioned methods are also supported. • Correctness of the NSI connections established with the NSI aggregator. Specifically, the following tests are checked: • Proper return of basic RM information – Tested methods: GetVersion • STPs (Service Termination Points) available for inter-island connections over NSI networks. – Tested methods: ListResources • Proper reservation, provisioning, instantiation, description, status, extension of the expiration date and delete of resources. – Tested methods: Allocate, Provision, PerformOperationalAction start/stop, Describe, Status, Renew, Delete. • Appropriate instantiation of the requested NSI connection.
