18-04-2011, 10:50 AM
[attachment=12276]
1. ABSTRACT
The deployment of new network architectures, services, and protocols is often manual, ad hoc, and time-consuming. Spawning networks are a new class of programmable networks that automate the life cycle process for the creation, deployment, and management of network architectures. These networks are capable of spawning distinct “child” virtual networks with their own transport, control, and management systems.
A child network operates on a subset of its “parent’s” network resources and in isolation from other spawned networks. Spawned child networks represent programmable virtual networks and support the controlled access to communities of users with specific connectivity, security, and quality of service requirements.
Spawning networks have the capability to spawn not processes but complex network architectures. It supports the deployment of programmable virtual networks.
2. INTRODUCTION
The process of automating the creation and deployment of new network architectures is defined as spawning. The term spawning finds a parallel with an operating system spawning a child process. Spawning networks are a new class of programmable networks that automate the life cycle process for the creation, deployment, and management of network architectures. These networks are capable of spawning distinct “child” virtual networks with their own transport, control, and management systems.
By spawning a process the operating system creates a copy of the calling process. The calling process is known as the parent process and the new process as the child process. Notably, the child process inherits its parent's attributes, typically executing on the same hardware (i.e., the same processor). A child network operates on a subset of its “parent’s” network resources and in isolation from other spawned networks. Spawned child networks represent programmable virtual networks and support the controlled access to communities of users with specific connectivity, security, and quality of service requirements
3. SPAWNING NETWORKS
Spawning networks support the deployment of programmable virtual networks. We call a virtual network installed on top of a set of network resources a parent virtual network. We propose the realization of parent virtual networks with the capability of creating child virtual networks operating on a subset of network resources and topology. This is a departure from the operating system analogy. The two architectures (i.e., parent and child) would be deployed in response to possibly different user needs and requirements. We describe a framework for spawning networks based on the design of the Genesis Kernel, a virtual network operating system capable of automating a virtual network life cycle process; that is, profiling, spawning, architecting, and managing programmable network architectures on demand.
In Figure.1, two child networks are spawned by the parent network. The first child network is a Cellular IP virtual network that supports wireless extensions to the parent network. The other child network (illustrated in Figure. 1) supports a differentiated services architecture operating over the same network infrastructure. An additional level of nesting is shown where the Cellular IP network spawns a child network. Child networks operate on a subset of the topology of their parents and are restricted by the capabilities of their parents’ underlying hardware and resource partitioning model. While parent and child networks share resources, they do not necessarily use the same software for controlling those resources. Typically, spawned network architectures would support alternative signaling protocols, communications services, QoS control, and network management to those of the parent architecture.
A number of research groups are actively designing and developing programmable network prototypes. The Open Signaling (Opensig) community argues that by modeling communication hardware using a set of open programmable network interfaces, open access to switches, routers, and base stations can be provided, thereby enabling third-party software providers to enter the market for telecommunications software. The Opensig community argues that by opening up the network devices in this manner, the development of new and distinct architectures and services can be more easily realized. Open Signaling, as the name suggests, takes a telecommunications approach to the problem of making the network programmable. Here there is a clear distinction between transport, control, and management that underpin programmable networks, and an emphasis on service creation with QoS.
The Active Network community advocates the dynamic deployment of new services at runtime mainly within the confines of existing IP networks. The level of dynamic runtime support for new services goes beyond that proposed by the Opensig community, especially when one considers the dispatch, execution, and forwarding of packets based on the notion of active packets. In one extreme case of active networking, capsules comprise executable programs, consisting of code (e.g., Java code) and data. Active networks allow the customization of network services at packet transport granularity, rather than through a programmable control plane (which is the goal of Opensig). Active networks offer maximum flexibility in support of service creation but at the cost of adding more complexity to the programming model. The Active Network approach is, however, an order of magnitude more dynamic than Opensig’s quasi-static network programming interfaces.
A common set of characteristics govern the construction of programmable networks:
• Networking technology implicitly limits the programmability that can be delivered to higher levels. For example, some technologies are more QoS programmable (e.g., ATM), scalable (e.g., Internet), or bandwidth-limited (e.g., mobile networks).
• Level of programmability indicates the method, granularity, and timescale over which new services can be introduced into the network infrastructure. This in turn is strongly related to language support, programming methodology, and middleware adopted. For example, distributed object technology can be based on RPC or mobile code methodologies, resulting in quasistatic or dynamically composed network programming interfaces, respectively.
• Programmable communications abstractions indicate the level of virtualization and programmability of networking infrastructure requiring different middleware and, potentially, network node support (e.g., switch/router, base station). For example, programmable communications abstractions include virtual switches, switchlets, active nodes, virtual base stations, and virtual active networks.
• Architectural domain indicates the targeted architectural or application domain (e.g., transport, signaling, management). This potentially dictates certain design choices and impacts the construction of architectures and services offered, calling for a wide range of middleware support.
We believe that the introduction of new network architectures on demand represents a difficult and complex problem. The complexity stems from the fact that it is difficult to predict all interactions between independently placed architectural components inside the network. We broadly define a network architecture as having the following generic components and attributes:
• Network services, which the network architecture realizes as a set of distributed network algorithms and offers to the end systems
• Network algorithms, which include transport, signaling/control and management mechanisms
• Multiple time scales, which impact and influence the design of the network algorithms
• Network state management, which includes the state the network algorithms operate on (e.g., switching, routing, QoS state) to support consistent services
Little work has been reported in the literature on automating the process of realizing distinct network architectures on demand. Spawning networks address this limitation by automating the network life cycle, providing a systematic approach to the design, deployment, and management of distinct internetworking architectures. Spawning networks provide a foundation for composing and deploying virtual network architectures through the availability of open programmable interfaces, resource partitioning, and the virtualization of the networking infrastructure found in
today’s programmable networks.
1. ABSTRACT
The deployment of new network architectures, services, and protocols is often manual, ad hoc, and time-consuming. Spawning networks are a new class of programmable networks that automate the life cycle process for the creation, deployment, and management of network architectures. These networks are capable of spawning distinct “child” virtual networks with their own transport, control, and management systems.
A child network operates on a subset of its “parent’s” network resources and in isolation from other spawned networks. Spawned child networks represent programmable virtual networks and support the controlled access to communities of users with specific connectivity, security, and quality of service requirements.
Spawning networks have the capability to spawn not processes but complex network architectures. It supports the deployment of programmable virtual networks.
2. INTRODUCTION
The process of automating the creation and deployment of new network architectures is defined as spawning. The term spawning finds a parallel with an operating system spawning a child process. Spawning networks are a new class of programmable networks that automate the life cycle process for the creation, deployment, and management of network architectures. These networks are capable of spawning distinct “child” virtual networks with their own transport, control, and management systems.
By spawning a process the operating system creates a copy of the calling process. The calling process is known as the parent process and the new process as the child process. Notably, the child process inherits its parent's attributes, typically executing on the same hardware (i.e., the same processor). A child network operates on a subset of its “parent’s” network resources and in isolation from other spawned networks. Spawned child networks represent programmable virtual networks and support the controlled access to communities of users with specific connectivity, security, and quality of service requirements
3. SPAWNING NETWORKS
Spawning networks support the deployment of programmable virtual networks. We call a virtual network installed on top of a set of network resources a parent virtual network. We propose the realization of parent virtual networks with the capability of creating child virtual networks operating on a subset of network resources and topology. This is a departure from the operating system analogy. The two architectures (i.e., parent and child) would be deployed in response to possibly different user needs and requirements. We describe a framework for spawning networks based on the design of the Genesis Kernel, a virtual network operating system capable of automating a virtual network life cycle process; that is, profiling, spawning, architecting, and managing programmable network architectures on demand.
In Figure.1, two child networks are spawned by the parent network. The first child network is a Cellular IP virtual network that supports wireless extensions to the parent network. The other child network (illustrated in Figure. 1) supports a differentiated services architecture operating over the same network infrastructure. An additional level of nesting is shown where the Cellular IP network spawns a child network. Child networks operate on a subset of the topology of their parents and are restricted by the capabilities of their parents’ underlying hardware and resource partitioning model. While parent and child networks share resources, they do not necessarily use the same software for controlling those resources. Typically, spawned network architectures would support alternative signaling protocols, communications services, QoS control, and network management to those of the parent architecture.
A number of research groups are actively designing and developing programmable network prototypes. The Open Signaling (Opensig) community argues that by modeling communication hardware using a set of open programmable network interfaces, open access to switches, routers, and base stations can be provided, thereby enabling third-party software providers to enter the market for telecommunications software. The Opensig community argues that by opening up the network devices in this manner, the development of new and distinct architectures and services can be more easily realized. Open Signaling, as the name suggests, takes a telecommunications approach to the problem of making the network programmable. Here there is a clear distinction between transport, control, and management that underpin programmable networks, and an emphasis on service creation with QoS.
The Active Network community advocates the dynamic deployment of new services at runtime mainly within the confines of existing IP networks. The level of dynamic runtime support for new services goes beyond that proposed by the Opensig community, especially when one considers the dispatch, execution, and forwarding of packets based on the notion of active packets. In one extreme case of active networking, capsules comprise executable programs, consisting of code (e.g., Java code) and data. Active networks allow the customization of network services at packet transport granularity, rather than through a programmable control plane (which is the goal of Opensig). Active networks offer maximum flexibility in support of service creation but at the cost of adding more complexity to the programming model. The Active Network approach is, however, an order of magnitude more dynamic than Opensig’s quasi-static network programming interfaces.
A common set of characteristics govern the construction of programmable networks:
• Networking technology implicitly limits the programmability that can be delivered to higher levels. For example, some technologies are more QoS programmable (e.g., ATM), scalable (e.g., Internet), or bandwidth-limited (e.g., mobile networks).
• Level of programmability indicates the method, granularity, and timescale over which new services can be introduced into the network infrastructure. This in turn is strongly related to language support, programming methodology, and middleware adopted. For example, distributed object technology can be based on RPC or mobile code methodologies, resulting in quasistatic or dynamically composed network programming interfaces, respectively.
• Programmable communications abstractions indicate the level of virtualization and programmability of networking infrastructure requiring different middleware and, potentially, network node support (e.g., switch/router, base station). For example, programmable communications abstractions include virtual switches, switchlets, active nodes, virtual base stations, and virtual active networks.
• Architectural domain indicates the targeted architectural or application domain (e.g., transport, signaling, management). This potentially dictates certain design choices and impacts the construction of architectures and services offered, calling for a wide range of middleware support.
We believe that the introduction of new network architectures on demand represents a difficult and complex problem. The complexity stems from the fact that it is difficult to predict all interactions between independently placed architectural components inside the network. We broadly define a network architecture as having the following generic components and attributes:
• Network services, which the network architecture realizes as a set of distributed network algorithms and offers to the end systems
• Network algorithms, which include transport, signaling/control and management mechanisms
• Multiple time scales, which impact and influence the design of the network algorithms
• Network state management, which includes the state the network algorithms operate on (e.g., switching, routing, QoS state) to support consistent services
Little work has been reported in the literature on automating the process of realizing distinct network architectures on demand. Spawning networks address this limitation by automating the network life cycle, providing a systematic approach to the design, deployment, and management of distinct internetworking architectures. Spawning networks provide a foundation for composing and deploying virtual network architectures through the availability of open programmable interfaces, resource partitioning, and the virtualization of the networking infrastructure found in
today’s programmable networks.
