What’s the UNI, NNI and Network Infrastructure needed for Cloud Computing?


Cloud computing deployments are being announced on an almost daily basis. Cloud computing accelerates application development and deployment without upfront capital costs for servers and storage. For this reason, many enterprises, governments and network/service providers are now considering adopting cloud computing to provide more efficient and cost effective network services. The Cloud Computing market is forecast to be very big by IDC, Gartner Group, andother market research firms.

But there seems to be a lot of confusion regarding the service delivery method and lack of interoperability. More importantly, there are no solid standards for Infrastructure as a Service, Platform as a Service or Applications/Software as a Service, network infrastructure needed for them or the required network interfaces between customer-provider (UNI), or between cloud providers (NNI).  This results in difficulties in exchanging information between cloud service providers and for users that change providers. It may also present a problem when bursting between a private cloud and different public clouds. Interoperability facilitates secure information exchange across platforms. Why isn’t there more talk about these interfaces and network infrastructure (both fixed and mobile) for cloud computing? 

Most cloud pundits assume the UNI will be a broadband IP VPN (over whatever PHY layer access is used).  Will that IP VPN deliver the necessary performance, reliability/availablity and security that’s required- particularly for access to a public cloud?  And how do different cloud network providers communicate, e.g. what’s the NNI?  This is particularly important for Federated and Hybrid (Public-Private) Clouds, yet the topic is not discussed at Cloud Computing Conferences,  Finally, we don’t know of any standards organizations, including ITU-T FG-Cloud and IEEE Cloud Computing Initiative  that are seriously pursuing these very important network aspects of Cloud.  That said, the ITU-T FG-Cloud plans to work on the Cloud network infrastructure requirement and architecture design to fulfill intra-cloud, inter-cloud and the core transport network use cases, and network resource management issues as well.  (See ITU-T FG Cloud section below).  That’s a start, but we think a lot more work will be necessary for true multi-vendor  interoperability.


Cloud Computing represents a unique opportunity for service providers to provide bundled offerings which combine Network and IT resources. We think that service providers can leverage their network assets by providing five nine’s network availability and excellent performance for secure end to end cloud services. Another opportunity for service providers is to evolve network resource allocation and control to be more dynamic, in order to provide on-demand provisioning of cloud services.

But what about the different types of network access, especially the choice between a L2 (Ethernet) and L3 (IP) VPN?  And various scenarios for IP VPN -to-private line communications?  In particular, what does the protocol stack look like for UNI and various types of NNI’s?  Who will decide these critical issues and promulgate the network related standards for cloud computing is anyone’s guess at this time.

ITU-T FG Cloud Work on Network Infrastructure:

The ITU-T FG Cloud has had only three meetings.  Among other things, it is pursuing work on cloud network infrastructure that’s focused on several objectives: the ability to link existing networks services, Internet connectivity,  L2/L3 VPN efficiency to deliver public or private cloud services.  The ability to link a flexible L2 & L3 network management and cloud technology to form an integrated cloud infrastructure would enable various types of cloud services.

Three distinct cloud network types have been defined ny FG-Cloud:

1. Intra-cloud network: this network is to connect local cloud infrastructures, such as data center LAN used to connect servers, storage arrays and L4-L7 services (firewalls, load balancers, application acceleration devices, IDS/IPS…).

2. Core transport network (WAN/MAN): this is the network used by customers to access and consume cloud services deployed within the cloud provider’s data center.

3. Inter-cloud network: this network role is to interconnect cloud infrastructures together. These cloud infrastructures may be owned by the same cloud provider or by different ones.

These three network components are essential for cloud services composition and delivery. In order to provide a real added value in support of cloud services, they must offer their network requirements (to cloud service users) in terms of flexibility, scalability,and on-demand resource provisioning. More importantly, advanced networking functions are necessary to ensure performance, security and availability of the various types of cloud services.

One of the most intriquing work areas of this FG-Cloud are the upper layer (L4-L7) services that may reside within the Cloud Transport Network.  The ITU-FG takes this position:

“In order to transform the core transport network into “smart-pipes” with real added value for cloud services delivery, the core network component should be able to provide on-demand L4-L7 network services required to ensure the performance, security and availability. Some examples of this requirement are:

  1. Security functions: provide on-demand security functions within the core transport network to protect and control customers traffic to cloud services. An example is firewalling functions and intrusion detection and prevention.

  2. Performance: provide on-demand application acceleration and optimization services for cloud services. This is essential to ensure application performance because these application will be accessed remotely (from customers sites to the cloud providers sites) and it is well known that most of business applications were initially designed for LAN environment and are negatively impacted by the delays and packet loss of the core transport network.”

In our opinion, this effort is commendible, but is just scratching the service.  For sure, a lot more work lies ahead.  So it may be years before we see a high level of interoperability amongst the many different types of cloud services and networks that support them.

IEEE Cloud Computing Standards Study Group:

A call for participation for the IEEE Cloud Computing Standards Study Group, sponsored by the IEEE Computer Society Standards Activities Board (SAB), was issued months ago.  We have not seen an announcement on an initial meeting or conference call to get organized.. An IEEE Standards Study Group is the initial step in the process of developing a IEEE standard and is open to all interested individuals.

The mission of the IEEE Cloud Computing Standards Study Group is to determine the feasibility of developing an open standards profile which defines options for portability and interoperability of cloud computing resources. These profiles should address issues such as interfaces to computing, storage, network, and content resources, as well as workload (program and data) interoperability and migration, security, fault-tolerance, agency, legal and regulatory, intra-cloud policy negotiation, and financial relationships. It is expected that there will be multiple architectural approaches from which to choose.

The profiles should also support the Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) service models, and the private cloud, community cloud, hybrid cloud, and public cloud deployment models.

For further information and/or to be added to the IEEE CCSSG mailing list, please contact Steve Diamond, Chair, IEEE Cloud Computing Standards Study Group, at ieee-ccssg-chair [at] intercloud [dot] org