Open Source Mano is an ETSI-hosted initiative to develop an Open Source NFV Management and Orchestration (MANO) software stack for production-ready Multi-Cloud Telco Orchestration.
OSM approach takes as starting point the architectural framework of ETSI NFV, including its NFV Orchestrator and VNF Manager functionalities, as well as additional layers, such as service orchestration or infrastructure management, which are also required for operators to enable NFV services. Open Source software can facilitate the implementation of an ETSI aligned NFV architecture, provide practical and essential feedback to the related ETSI Technical Groups and Software Development Groups and increase the likelihood of interoperability among NFV implementations.
ETSI's Open Source Mano (OSM) group is developing an open source Multi-Cloud Telco Orchestration stack using well established open source tools and working procedures. The activity is closely aligned with the evolution of other ETSI Technical Groups, such as ETSI NFV and ETSI SDGs, and will provide a regularly updated implementation of NFV MANO. OSM aims at enabling an eco-system of NFV solution vendors to rapidly and cost-effectively deliver solutions to their users.
ETSI OSM complements the work of ETSI Technical Groups and vice versa. In particular, ETSI OSM provides an opportunity to capitalize on the synergy between standardization and open source approaches by accessing a greater and more diverse set of contributors and developers than would normally be possible.
This approach maximizes innovation, efficiency and time to market and ensures a continuing series of open source implementations.
Participation to ETSI OSM is open to members and non-members of ETSI upon signature of the relevant agreements.
The OSM code is developed according to accepted open source working procedures. Latest information is available on the OSM development platform which is hosted and managed by the ETSI Secretariat.
The Industry Specification Group (ISG) on Non-IP Networking (NIN) has been set up to standardize a digital communications technology fit for the 21st century.
Our vision is a much more efficient system that is far more responsive to its users.
Networking for the age of virtualizationThe TCP/IP suite of network protocols is now over 40 years old and was designed for different requirements than the networking of the 2020s. This raises addressing, mobility, performance, and security issues; and efforts to mitigate them have required significant effort, energy, and cost, and added significant complexity.
With the increasing challenges placed on modern networks to support new use cases (some of which require ultra-low latency) and greater connectivity, Service Providers are looking for candidate technologies that may serve their needs better than the TCP/IP-based networking used in current systems.
ISG NIN is standardizing networking technology which natively meets 21st-century requirements such as mobility, security, privacy, efficient use of spectrum, and ultra-low latency. The title, Non-IP Networking, emphasises that the technology is not dependent on IP packet formats or protocols; however, it supports the TCP/IP suite as well as other systems such as Information Centric Networking. An application wishing to access a service (or some content) identified by a URL, or a virtualized network service, can request it directly instead of first having to find an IP address that identifies a location where the service is provided.
Software-Defined Networking (SDN) can provide a flow control overlay for IP networks. Like SDN, ISG NIN’s Flexilink technology recognizes that most packets are part of a “flow”, and most of the decisions the system has to make are per-flow rather than per-packet. For instance, the “next hop” from a switch towards the destination will be the same for every packet on a flow; and packets carrying a live audio or video stream will arrive at regular intervals and require to be forwarded promptly, whereas packets from other applications with less-stringent latency demands can be queued. Flows can easily be redirected around faults or when a mobile device moves to a different cell.
In the case of SDN, the flow is identified by searching a “flow table” for a match with information that is scattered over different parts of the packet header, which involves significant per-packet processing. Flexilink packets, on the other hand, simply contain a “label” which points directly to the flow table entry.
IP packet formats are the same over the whole network; this is why, 30 years after IPv6 was first proposed, much Internet traffic is still using IPv4. Flexilink packet formats are appropriate to the physical layer technology of each link, for instance a higher-capacity link will support more flows. Introducing a link with a new format does not require any change to the rest of the system, and migration from IP to Flexilink can be done in stages as life-expired equipment is replaced.
Achieving ultra-low latencyRecognizing that networks will carry an increasing amount of time-critical traffic – not only live audio and video but also applications promised for 5G such as industrial automation and remote surgery – and that traditional store-and-forward packet networks struggle to reliably achieve the low-millisecond latencies that some of these applications require, Flexilink supports two kinds of flow. “Basic” flows provide the best-effort service with queues that is traditional for packet networks, while “guaranteed” flows provide a service for time-critical traffic. The two services can be multiplexed together so that all the capacity not occupied by guaranteed service data (including capacity reserved but not used) is available to the basic service.
To provide the lowest latency, the guaranteed service can be implemented in a way that is more like the “routers” that switch point-to-point audio and video. It can also be carried over other technologies such as TSN (Time-Sensitive Networks); the latency (which will be higher in that case) is reported in the control plane messages that set the flow up.
We have identified a number of technical issues with the current (TCP/IP-based) technology which prevent it delivering the required levels of service without excessive complexity or, in some cases, at all.
The new protocols will provide:
virtual elimination of delays in forwarding real-world signals: not only audio and video but also tactile feedback and the position of vehicles or industrial robots multicasting of live content (such as sports events) to an unlimited number of subscribers more efficient use of spectrum and of processing power better security, both privacy and resilience to denial-of-service better performance when accessing remote content such as web pages ways of guaranteeing network service sustainability extensibility: packet formats do not have to be the same throughout the system, and introducing new features such as a new kind of addressing only affects the control plane messages What does this mean for the user?Elimination of delays in packet forwarding equipment will make conversation more natural, especially in conference calls. A performer’s sound can be sent across the network to be mixed with other performers’ and returned to their headphones. Applications such as remote surgery become possible.
More efficient processing extends battery life in handsets.
Privacy is improved: devices do not need to have IP addresses, and a server does not need to know a client’s address or location in order to reply to its request. Before any exchange of data takes place the server can require as much or as little authentication of the client’s identity as is appropriate to the application. It will be much easier to discover where your device is sending data to.
Downloads will be faster, and there will be less “buffering delay” when watching streamed content. New business models can be explored based on improved identification of content and quality auditing.
What does it mean for the operator?The whole system becomes much simpler and therefore cheaper to build and to operate. Many middle-box functions, such as address translation, firewalls, header compression, and transport-layer optimisers, are eliminated or incorporated into the control plane procedures. Mobility is supported natively instead of needing tunnelling layers to be added.
The service for media streams provides multicasting and ultra-low latency (typically less than 10µs per hop) as standard. As well as live broadcasting (such as of sporting events) it can be used to distribute recorded content to local caches and to distribute software updates.
Many of the protocols needed by current systems, such as DNS, ARP, SIP, SDP, and RSVP, are incorporated into the control plane procedures. This, along with a dramatic reduction in packet header sizes, reduces the amount of capacity on the air interface that is taken up by protocol overheads.
The forwarding plane can be implemented entirely in logic (hardware), and thus needs much less power than is needed for per-packet processing by software. Simplified protocols and elimination of the need for header compression reduce processing power requirements further.
How do we get there?The new technology can be carried over IP networks, and IP packets can be carried over the new technology. Thus, the new technology can be introduced incrementally, in the form of “islands” where internal traffic benefits from the new levels of service and there is seamless transition to the legacy technology at the edge. This can be done as part of the normal processes of expanding networks and of replacing end-of-life equipment.
An example would be where a new network is being built to support 5G: core, RAN, and MEC can be implemented with the new technology. When an application connects a socket to a service, the system can check whether that service is available at the edge and if so connect directly using the new technology. This check might need more information than would be provided in the DNS look-up used in legacy systems, e.g. to see whether a cached copy of a particular piece of content is available. Otherwise, the connection goes through the User Plane Function; much of the processing of legacy packet headers is transferred from the UE to the UPF, saving battery in the UE, and the amount of processing required in the UPF is similar to the NAT procedures common in today´s Internet access.
Participation in the Non-IP Networking Industry Specification Group is open to all ETSI members as well as organizations that are not members, subject to signing ISG Agreements. For information on how to participate please contact ISGsupport@etsi.org.
A full list of related specifications in the public domain is accessible via the NIN committee page.
ISG NIN will also act as responsible body for the maintenance of ISG NGP Deliverables if need arises. The specifications published by NGP are accessible via the standards search on our website.
The direct link to refer to this blog is https://www.etsi.org/newsroom/blogs/blog-nin
