Page 215 - ITU-T Focus Group IMT-2020 Deliverables
P. 215
ITU-T Focus Group IMT-2020 Deliverables 3
II.2 SDK Tools
• Function Name: VNF SLA Monitor: IMT-2020 must provide an interface to monitor VNFs SLAs and
resource usage. It must highlight VNFs with high and low usage that may need scaling or other kind
of manual intervention. The system shall expose service and VNF metrics to the network application.
• Function Name: VNF Resource Report: IMT-2020 must provide an interface to list all resources
allocated to a specific service. This service allows the developer or administrator to get an overview
of how the service is evolving and what datacenter resources are committed to each service.
• Function Name: Authorization: IMT-2020 service must limit operations based on access levels and
provide means to create and manage access profiles. This will be used to define the different access
levels each user will have to the system, as an example, a VNF developer should be able to deploy a
VNF on the catalogue, but should not have the permission to trigger its deployment to a production
network.
• Function Name: VNF Deployment: IMT-2020 must support placement instructions that express
proximity to other entities, e.g, (i) set where the service gateways will be placed on the operator
network, (ii) deploy a VNF as near as possible to a specific location, (iii) select were the VNF will be
deployed .
• Function Name: VNF Status Monitor: IMT-2020 should provide a high level state for each VNF, e.g.,
(i) deployment, (ii) operating, (iii) error.
• Function Name: IoT traffic simulator: Given that there is not yet the amount of IoT traffic this use
case is designed to address, there must be a way to simulate IoT sensor traffic with functions like
increase or decrease traffic levels per sensor and number of sensors in order to simulate a real IoT
sensor environment.
• Function Name: VNF integration with service: IMT-2020 must allow new VNFs to be integrated in
existing services. It must allow network flow reconfiguration in order to integrate a newly deployed
VNF in an existing service graph with minimum or no downtime at all.
• Function Name: SDK VNF customization: The SDK must allow the development of custom VNFs with
specific algorithms to manipulate IoT traffic, like processing and batching.
• Function Name: Multiple IoT sensor vendors: Framework must support traffic from different IoT
sensor vendors. Traffic from each sensor should be routed through the appropriate gateway.
• Function Name: Multiple IoT tenants: Framework must support multi tenancy, i.e., The
infrastructure must support multiple IoT services operating in parallel without any data meant to
one operator being routed to another operator’s service.
• Function Name: Support for Service Templates: The programming model must support service
templates. In other words, it must support the inclusion of types of nodes, or at least the notion of
cardinalities in inter-node relationships, e.g. in order to define an unspecified number of nodes.
Support for corresponding annotations (or primitives) in the service programming model/language.
• Function Name: Inter-VNF QoS constraints: The programming model must support end-to-end QoS
properties for inter-VNF communication, such as delay, jitter, reliability (which could be mapped to
multi-path transmission by the orchestrator, the developer does not care necessarily),
oversubscription.
• Function Name: Placement constraints for VNFs: The programming model must support to specify
placement constraints for VNFs, e.g. disjoint placement of active and standby VNF on physically
separate machines, pinning a VNF to a specific node or node type (e.g., turbine control must run on
a turbine node), hosting nodes must offer certain real-time capabilities or security isolation features,
satisfaction of rules of compliance, etc.
209