This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2008 proceedings.
Towards a Federated Network Architecture Hoda M. Hassan
Mohamed Eltoweissy
Moustafa Youssef
Bradley Department of Electrical and Computer Engineering, Virginia Tech Cairo, Egypt
[email protected]
Bradley Department of Electrical and Computer Engineering Virginia Tech Virginia, USA
[email protected]
Wireless Intelligent Networks Center Nile University Smart Village, Egypt
[email protected]
Abstract— The layered architecture that guided the design of the Internet is deemed inadequate as a reference model for engineering protocols for NGN. Layered protocol suites impose a strict sequential order on protocol execution conflicting with the efficient engineering of end systems, as well as failing to express vertical functional integration, the separation of control and data planes, and the distributed nature of network functions. Furthermore, protocols developed according to the layered architecture are implemented as monolithic blocks with undefined or implicit dependencies lacking flexibility to adapt to changing application requirements. We claim that NGN architecture design should be dual faceted along a vertical and a horizontal dimension. The vertical dimension addresses complexity at a network node by abstracting the communication functionality into several components and defining component interactions, while the horizontal dimension addresses the distributed nature of the network, abstracting network links into communication paths, and defining procedures for creating, maintaining, as well as exchanging data between different network components along these paths. We propose a preliminary network architecture based on component federation. We focus on the vertical decomposition of the communication functions and their interactions considering the distributed consequences of these interactions along the horizontal dimension of the network. Keywords-Network Architecture, Federated Architecture, Micro Protocol Composition.
Network
I. INTRODUCTION The layered architecture that guided the design of the Internet is deemed inadequate as a reference model for engineering protocols for Next Generation Networks (NGN). Layered protocol suites impose a strict sequential order on protocol execution, which may conflict with the efficient engineering of end systems, as well as fail to express vertical functional integration, the separation of control and data planes, and the distributed nature of network functions. Furthermore, protocols developed according to the layered architecture are implemented as monolithic blocks with undefined or implicit dependencies thus lacking flexibility to adapt to changing application requirements. Various modifications for the Internet architecture have been proposed; while some aim for incremental adjustments; most prominent example of which is cross-layer designs (CLDs) as those presented in [1] and [2], other proposals provide radical “clean-slate” architectural designs that abandon layering adopting different schema to express
communication functionalities, their associations and interactions. Examples of the latter are protocol environments and modules as in [4]. CLDs defy the strict ordering imposed by the layered architecture and allow protocols at nonadjacent layers to communicate. CLDs have the advantage of preserving the layered architecture so they could be designed to interface with present implementations. Yet, integrating several CLDs with the Internet protocol suite may work at cross purposes leading to unintended side effects and eventually overall performance deterioration. As for protocol environments and modules, they have the advantage of providing complete freedom in structuring the sequence of the communication process. Yet, they do not offer guidance as how protocol entities will interact; leading possibly to erroneous implementation decisions. We claim that NGN architecture design should be dual faceted along a vertical and a horizontal dimension. The vertical dimension addresses complexity at a network node by abstracting the communication functionality into several components and defining component interactions, while the horizontal dimension addresses the distributed nature of the network, abstracting network links into communication paths, and defining procedures for creating, maintaining, as well as exchanging data between different network components along these paths. In this research work we aim to develop an architectural view for network design that focuses on the vertical decomposition of the communication functions and their interactions. We also consider the distributed consequences of these interactions and how they can affect or get affected by the operation along the horizontal dimension of the network. II. RELATED WORK For space limitation, this section highlights a small subset of previous work that we believe have greatly contributed to the realization of the proposed architecture. Cross Layer network architecture, as those presented in [1], and [2], allow vertical protocol interaction. A cross-layer frame work for the layered architecture is presented in [1], where a central entity manages the interactions among different layers along four planes; Security, QoS, mobility, and link adaptation. ÉCLAIR [2], an asynchronous cross layer feedback architecture, splits the cross layer system into two subsystems; Tuning Layers (TL) and Optimizing
978-1-4244-2219-7/08/$25.00 ©2008 IEEE.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2008 proceedings.
Subsystem (OSS). A TL is an extension appended to each layer of the protocol stack and is aware of the data structures used to store the control information of each protocol within a given layer. OSS is composed of several Protocol Optimizers (POs), where each PO contains the algorithm for a particular cross layer optimization The concept of flexible service and protocol composition has been addressed in different contexts. Reference [5] introduces a novel approach for service composition on active and programmable routers, which enables flexible programmability of a router’s data path through dynamically loadable software components called ‘active components’. Using legacy TCP/IP protocols as components, [6] proposes a component-based Dynamic Protocol Framework (DPF) for multimedia applications. A flexible micro protocol framework that facilitates a customized design process of communication protocols using SDL as the design language was introduced in [7]. Key tenets that greatly impacted our design principles were presented in [8]. These tenets were identified as fundamental principles to be incorporated into any architecture targeting next generation Internet and beyond. III. DESIGN PRINCIPLES Following are the design principles that will guide our proposed architecture A. Edge Modulated End-to-End Principle (e2e) The e2e principle [9] has served the Internet well by keeping the core general enough to support a wide range of applications. However, taken as an absolute rule, we believe that the e2e principle constrained core evolvability rather than fostered its capabilities rendering it biased to those applications that can tolerate its oblivious nature. To retain its generality, the core needs to provide edge applications the choice to use low-level application-specific functions. Hence, in our edge modulated e2e principle, edge running applications can request the level of core involvement to support the application flows administered into the core by performing low level application oriented functions. B. Differentiated Delivery for Aggregated Flows A limitation attributed to the Internet architecture is being incognizant to packet flows or their aggregates [8]. This is because flows in Internet implementations are realized only at the application layer for UDP traffic, or at the application and transport layers for TCP traffic. Layers further down the stack do not recognize the concept of flows or flow aggregates. Accordingly, the network core was developed to be oblivious to flows and their aggregates. We recognize a flow as a unit of exchange between communication functions thus enabling flow-oriented networking. C. Global Connectivity Endorsing Realms Independently managed network realms are a reality in the present Internet setting. Accordingly, our architecture will endorse coexistence of different network realms
identified by policies, topological boundaries, addressing schemes, specialized protocols, etc. These realms need not abide by our architecture. Therefore global connectivity will be defined in terms of inter-realm communication [10]. D. Identifier Location Separation Our architecture will support Identifier location separation as it is a widely approved concept in the network research community [3]. From our perspective, an identity is a routing identifier representing session endpoints. It is not to be mistaken with application level identifiers. Routing identities (RI) are topology agnostic, located using topology related addresses. To address mobility issues in our design, we argue that session endpoints RIs need to be revealed to routing functions within the core. E. State Monitoring Plane (SMP) SMP is a distributed self-contained system composed of local monitoring functions operating in parallel to the communication subsystem. By monitoring node operations, the SMP aids the communication subsystem in managing vertical functional integration and controlling interfunctional dependencies, hence avoiding any potential unforeseen interactions. Moreover, the SMP assists the communication subsystem in predicting network states by collaborating with neighboring SMPs to gather and evaluate the performance perceived by surrounding nodes. F. Network Knowledge Plane (NKP) When dealing with complex systems, where computer network failure is a rule rather than an exception, network nodes need to be aware of their conditions and infer operational patterns so as to reason about failures and enhance performance. To achieve this goal our architecture needs to augment the networking logic with functions that can realize operational context, reason about perceived states, and learn form previous experience. G. Design for Change So far our design principles expressed functional requirements, i.e. the operational behavior required for the different parts that define the communication system, but it did not address how these different parts need to be structured or how will they interact. Fearing to fall into the same pitfalls that doomed the layered architecture and rendered it non-evolvable, we define design for change as an important principle. This compels us to build a sustainable architecture in which the basic building blocks are strongly cohesive and loosely coupled, where assumptions are well encapsulated and the costs of changing system aspects are minimal [11]. IV. FEDERATED NETWORK ARCHITECTURE (FEDNET) Addressing the concept of design for change, D. Clark et al in [3] note that cutting a system into small parts may freeze it, because all the resulting interfaces become fixed points of the design. Yet, a system composed of few big parts may offer the implementer less guidance, but may be
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2008 proceedings.
easier to upgrade. Adopting Design for Change as a principle persuaded us to architect the communication system using “big” building blocks while providing clear guidance as how these building blocks need to be defined and interoperated. Accordingly our FedNet architecture partitions the communication system into self contained building components, where functions contained within FedNet components are functionally cohesive [12] sharing the same responsibilities and assuming the same high-level role with respect to the communication task. Furthermore, components within the FedNet architecture are allowed to interact and collaborate within a defined federation framework that modulates inter-component coupling. Internally, FedNet components can be flexibly composed by integrating several micro protocols (or µprotocol). A µprotocol is a standalone entity responsible of performing a specific elementary function, close to the definition of roles in Role-Based Architecture [3]. A µprotocol is also defined in [7] as “a communication protocol with a single (distributed) functionality and the required protocol collaboration”. Micro protocols are offered through µprotocol libraries and integrated according to a predefined framework. FedNet architecture defines the communication functions in terms of five components and modulates their interaction and collaboration through the Federated Component Manager (FCM). FCM spans the FedNet architecture vertically and horizontally, interfacing with all of its components, tuning individual component operation, as well as regulating intercomponent collaboration. We present FedNet components as follows; •
•
•
Application Oriented Component (AOC): AOC is self contained component that serves an end application. So we can have an email oriented component, a web oriented component, a video streaming oriented component etc. Protocols residing at the AOC are dedicated to serve the end running applications considering an end-to-end perspective. Newly arising applications can be supported by populating the µprotocol library with the required micro protocols and defining the corresponding framework composition of the AOC to support the new application. AOCs generate/consume data flows whose characteristics can be deduced from the µprotocol that compose the AOCs respectively. Device Oriented Component (DOC): DOC is technology dependent controlling access to the physical media and managing the actual transmission of end application data to the next hop. DOC is considered the most rigid component in FedNet as it deals with physical aspects of interfaces and links, where configuration options are limited by both device interface and physical media capabilities. Although DOC role is defined on per hop basis, yet it contributes to the global communication task by managing individual links that make up communication routes. Network Oriented Component (NOC): the NOC is a self contained component that performs network
related functions, i.e. functions that are concerned with path discovery, composition, and maintenance. In addition, NOC manages interoperability among heterogeneous network realms by defining translation functions that run on gateways at realm boundary, to tunnel FedNet traffic through FedNetunaware realms. Although defined as a separate component, the NOC represents the horizontal axis along which the FCM spans the network substrate to determine optimal operational points complying with end application semantics defined by AOC flow characteristics, device/link capabilities identified by the DOC, and perceived network conditions observed by NOCs communicating along created paths, thus dynamically tweaking the level of intercomponent coupling and directing the NOCs to discover context aware routes. •
State Monitoring Component (SMC): A self contained, possibly distributed, component responsible for passive state monitoring of AOC, NOC, and DOC components. Monitoring requests are administered to the SMC by the FCM or possibly by the NKC. The SMC has its own repository structure where recorded states are stored in soft state and could be retrieved upon demand.
•
Network Knowledge Component (NKC): We envision networks as complex systems characterized by evolving and changing behavior, thus adapting and tuning network operation need to be learned by the continuous recording of network states, operational parameters and the subsequent emergent behavior. This is the role of NKP. NKP is composed of global state repository, where network states and the corresponding perceived performance levels will be recorded, and an inference engine that can evaluate and reason on this recorded information and consequently provide advice to FCMs.
•
Federated Component Manager (FCM): FCM is a cornerstone in FedNet architecture. It is responsible for instantiating components through µprotocol composition and managing all inter-component interactions both vertically as well as horizontally. µprotocol composition can be done according to a generic framework as proposed in [7], where a generic µprotocol framework is a set of general principles and rules for composing a FedNet component represented using event based, hierarchal, or protocol graph configuration techniques. FCM manages inter-component collaboration by controlling the level of federation that can exist between any two or more, similar or different components. The following example illustrates one of the scenarios that we envision when operating according to the FedNet architecture 1. 2.
An end user activates a network application identifying the required destination The FCM, according to predefined protocol composition specification, decides on the micro
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2008 proceedings.
protocols that will be instantiated and the characteristics of the flow to be generated 3. The FCM composes the NOC components that are responsible for discovering the destination location according to the destination name that the FCM has obtained form the end application. 4. The NOC Location component will return the location of the destination node on which the peer application instance is running 5. The FCM will instantiate the NOC component responsible to set up the path to the destination according to the flow characteristics decided upon in step 2 and the DOC parameters (e.g. frame size, retransmission strategy, etc.) 6. The NOC Path Setup component communicates with peer NOC components along the path to the destination location to try to attain a path with the required characteristics. This might involve other DOC as well as NOC component activation to perform path reservation, core function instantiation, policy negotiation to guarantee a path that will satisfy the end application QoS requirements. The Path Setup NOC will return the attainable path characteristics to the FCM after adapting the DOCs parameters along the path. 7. According to the path characteristics, the FCM will instantiate the most suitable AOCs by choosing among different FEC, ARQ, compression techniques, flow management, congestion control, transport service, and other µprotocol 8. In case of communication setup is required, the AOC transport service might send a communication request to the destination so that a peer AOC is instantiated on the destination node 9. The FCM creates the required flow tags to be attached to the AOC generated flows and the packet classifiers which will be responsible for tagging individual packets according to packet priority within a single flow 10. The FCM attaches the output interface of the AOC to the packet classifier input interface and the packet classifier output interface to the NOC input interface As such we expect the FCM to be composed of several subcomponents, such as packet classifiers, component composer, route evaluator, etc. Figure1 shows the FedNet components superimposed over the legacy TCP/IP architecture V. FUTURE WORK In FedNet, our primary focus will be on the decomposition of legacy protocols into µprotocol as well as devising new µprotocol to fit evolving communication paradigms. Next, we need to develop the different frameworks according to which different FedNet
components can be composed. Several techniques have been proposed in the literature including formal methods and formal design languages. With respect to the DOC, we need to explore the area of software defined radios since it provides valuable guidance as how to adapt the device performance to operating context. In line with previously mentioned tasks, we need to identify the parameters to be extracted from different components and monitored by the SMC as well as those to be monitored and recorded by the NKC As for the FCM, we will start by identifying what core specific functions to be included in the NOC borrowing heavily from the area of active and programmable networks. Last but never least, the internal structure of the FCM will be architected. REFERENCES [1]
G. Carneiro, J. Ruela, and M. Ricardo,“Cross-Layer Design in 4G Wireless Terminals,” IEEE Wireless Commun. Mag.. Vol. 11, Issue 2, Apr. 2004 Page(s):7 – 13 [2] V. Raisinghani, and S. Iyer, "Cross-Layer Feedback Architecture for Mobile Device Protocol Stacks,"IEEE Communications Magazine, Jan. 2006 [3] The NewArch consortium. New Arch: Future Generation Internet Architecture (Final Technical Report), 2003. Available at http://www.isi.edu/newarch/. [4] Jung, M. and Biersack, E. "A Component-Based Architecture for Software Communication Systems," Proc. IEEE ECBS, Edinburgh, Scotland, Apr. 2000. [5] S. Schmid, T. Chart, M. Sifalakis, and A. Scott, "A Highly Flexible Service Composition Framework for Real-life Networks," The Inter. Jr. of Computer and Telecommunications Networking, Vol. 50, Issue 14, Oct. 2006, Pages: 2488 - 2505 [6] L. An, H. Pung, and L. Zhou, "Design and implementation of a dynamic protocol framework," In Proc. of 12th IEEE Inter. Conf. on Networks 2004 [7] I. Fliege, A. Geraldy, R. Gotzhein, and P. Schaible, "A Flexible Micro Protocol Framework," D. Amyot and A.W. Williams (Eds.): SAM 2004, LNCS 3319, pp. 224–236, 2005. Springer-Verlag Berlin Heidelberg 2005 [8] D. Clark, K. Sollins, J. Wroclawski, T.Faber, "Addressing Reality: An Architectural Response to Real-World Demands on the Evolving Internet," ACM SIGCOMM 2003 Workshops, Karlsruhe, Germany. [9] J.H. Saltzer, D.P. Reed and D.D. Clark, “End-to-End Arguments in System Design,” ACM Transactions in Computer Systems 2, 4, November, 1984, pages 277-288 [10] http://www.autonomic-communication.org/Annales/ [11] K. Henney, "What is Software Architecture?," http://www.itarchitect.co.uk/articles/display.asp?id=358 [12] http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
