A Taxonomy for Future Internet Functionalities (covering both cloud and network)

posted 18 Oct 2012 07:00 by Costas Kalogiros   [ updated 31 Oct 2012 00:27 ]

SESERV has developed and applied a methodology, called tussle analysis, for analysing and assessing the importance of socio-economic challenged in the Internet and their consequences for the success and adoption of technologies. The first step of the proposed methodology involves the identification of the functionality under investigation.

Applying the tussle analysis methodology to an initial set of EC-funded research projects brought up the need to make those 'functionalities' more concrete. The suggested plan was to use an extensive taxonomy of Internet functionalities, which covers both aspects of how services are being hosted (cloud-related functionalities) and their actual delivery (network-related functionalities).



Not trying to reinvent the wheel, we adopted the network functionalities taxonomy as described in [1]. The reason for selecting this partcular taxonomy is that each functionality was found to be well separated from other complementary ones. While each of these functionalities can be decomposed further into sub-functionalities, they can be also seen as components for composing more complex network services. More specifically:
  • The Transmission functionality was suggested to include sending, receiving, forwarding, routing, switching, storing, and processing of data packets or, in general, PDUs (Protocol Data Units).
  • The Traffic control functionality includes flow and congestion control (for tuning the transmission rate parameters), as well as, error control for dealing with lost and out-of-order PDUs.
  • The QoS (Quality of Service) functionality would cover queuing algorithms, admission control techniques and mechanisms for managing QoS-aware paths (e.g., advertisement of infrastructure availability and current workload, setup of Diff-Serv classes, etc.).
  • The Mobility functionality would include protocols for handover and location management.
  • The Security functionality would cover protocols for authentication, authorization, accounting, monitoring, encryption, redundancy, data integrity, and key distribution.
  • The Naming/Addressing functionality would include naming schemes and name resolution techniques.
Unfortunately, we didn't find a suitable taxonomy for cloud functionalities; thus we proposed a new one. More specifically:
  • Virtualization, which includes image creation, image deactivation, image portability (to different machines), etc. 
  • Execution, which includes low-level tasks such as Task scheduling (at the CPU level), Task execution (at the CPU level), memory allocation and similar aspects related to Operating Systems.
  • QoS, which includes advertisement of site availability, site selection, machine selection, machine reservations, admission control (for performance reasons), cost allocation, etc.
  • Security that includes monitoring, accounting, SLA management, admission control (for security reasons), etc.
It is important to note that each functionality should achieve its initial target, instead of other purposes that were found later (spillover). For example, techniques for DPI (Deep Packet Inspection) should not be part of the QoS functionality, but MPLS signaling for setup of QoS-aware paths perfectly fit into that functionality.

[1]. N. Thi-Mai-Trang, “On The Way To a Theory for Network Architectures”, World Computer Congress, Network of the Future Conference, Brisbane, Australia, September, 2010

Comments