[ieee milcom 2005 - 2005 ieee military communications conference - atlantic city, nj, usa (17-20...

5
1 SELF–INITIATED AND SELF-MAINTAINED OVERLAY NETWORKS (SIMONS) FOR ENHANCING MILITARY NETWORK CAPABILITIES M. Elaoud Telcordia Technologies Applied Research Piscataway, New Jersey A. McAuley Telcordia Technologies Applied Research Piscataway, New Jersey G. Kim Telcordia Technologies Applied Research Piscataway, New Jersey J. Chennikara-Varghese Telcordia Technologies Applied Research Piscataway, New Jersey ABSTRACT Future military networks such as FCS and WIN-T will exploit commercial protocols, such as dynamic IP rout- ing (e.g., OSPF, PIM and BGP) and DiffServ for QoS. This raises the question of how to provide additional network features needed for many military applications. For example, how can military networks add functions such as multipath routing, efficient network processing, and late binding IPSec tunnels that are vital to providing enhanced robustness, efficiency, security and QoS? In many cases the best approach to provide these enhanced features is to use overlay networks. Examples include application-layer multicasting, web distribution net- works, resilient overlay networks, IPv6 over IPv4 tun- nels, and HAIPE. One significant challenge with all these overlay net- works is the configuration overhead and resultant man- agement complexity. To address this issue, this paper proposes the use of a new tool that creates Self-Initiated and self-Maintained Overlay Network (SIMON). Using plug-and-play modules, the tool supports not only a par- ticular need or mission, but supports a wide set of en- hanced capabilities. SIMONs are independent of IP ad- dressing and offer the enhanced features without any network intervention. We have designed three main protocols to support the desired capabilities for SIMONs: (a) a Dynamic Overlay Network Configuration Protocol (DONCP), (b) an Over- lay Network Routing Protocol (ONRP) and (c) an Over- lay Network Multipath Routing Protocol (ONMRP). In this paper we describe the main features and basic op- erations of the SIMONs and outline the design and func- tionalities of DONCP. INTRODUCTION Future battlefield networks are likely to exploit commer- cial routing protocols. Standard protocols such as OSPF [1], BGP [2], MOSPF [3], DVMRP [4] and PIM [5,6] can support most basic unicast and multicast communi- cations. There should only be occasional need for com- pletely replacing commercial protocols, such as in small Mobile Ad-hoc Networks (MANETs). This raises the question of how to provide additional capabilities, such as enhanced routing, efficient network processing, and information-centric networking, to increase robustness, efficiency, and QoS, which will be needed for many military applications and networks such as FCS and WIN-T. Enhanced routing, for instance, can provide a higher level of robustness to overcome high and variable wireless bit-error-rates by sending messages over multi- ple disjoint paths without altering the underlying IP rout- ing tables. In addition, one can provide QoS routing based on delay requirements or bandwidth requirements or both. The network processing capability can offer traffic aggregation and redundant FEC for efficient use of network resources and added reliability. For instance computational graphs may be created to aggregate in- formation. Information-centric-networking allows higher layer abstractions, such as connecting to local nodes, which are not tied to an ephemeral underlying IP ad- dressing. All of these capabilities can be added at the network layer. However, implementing these features in the net- work layer has three major drawbacks. First, it de- creases the potential of exploiting commercial off the shelf routing protocols and network elements. Second, it will significantly increase the complexity of the routing protocols, creating scaling problems. Third, it makes the network more vulnerable by overloading network traffic with non-optimized data communications. In this paper we present a novel solution to provide en- hanced capabilities through Self-Initiated and Self- Maintained Overlay Networks (SIMONs). The tools to create SIMONs are plug-and-play, scalable, application- level solution that allow the implementation of enhanced routing and network processing without major support form the network layer. SIMONs are designed to func- tion in dynamic networking environments where station-

Upload: j

Post on 22-Mar-2017

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Self-Initiated

1

SELF–INITIATED AND SELF-MAINTAINED OVERLAY NETWORKS (SIMONS) FOR ENHANCING MILITARY NETWORK CAPABILITIES

M. Elaoud Telcordia Technologies

Applied Research Piscataway, New Jersey

A. McAuley Telcordia Technologies

Applied Research Piscataway, New Jersey

G. Kim Telcordia Technologies

Applied Research Piscataway, New Jersey

J. Chennikara-Varghese Telcordia Technologies

Applied Research Piscataway, New Jersey

ABSTRACT

Future military networks such as FCS and WIN-T will exploit commercial protocols, such as dynamic IP rout-ing (e.g., OSPF, PIM and BGP) and DiffServ for QoS. This raises the question of how to provide additional network features needed for many military applications. For example, how can military networks add functions such as multipath routing, efficient network processing, and late binding IPSec tunnels that are vital to providing enhanced robustness, efficiency, security and QoS? In many cases the best approach to provide these enhanced features is to use overlay networks. Examples include application-layer multicasting, web distribution net-works, resilient overlay networks, IPv6 over IPv4 tun-nels, and HAIPE.

One significant challenge with all these overlay net-works is the configuration overhead and resultant man-agement complexity. To address this issue, this paper proposes the use of a new tool that creates Self-Initiated and self-Maintained Overlay Network (SIMON). Using plug-and-play modules, the tool supports not only a par-ticular need or mission, but supports a wide set of en-hanced capabilities. SIMONs are independent of IP ad-dressing and offer the enhanced features without any network intervention.

We have designed three main protocols to support the desired capabilities for SIMONs: (a) a Dynamic Overlay Network Configuration Protocol (DONCP), (b) an Over-lay Network Routing Protocol (ONRP) and (c) an Over-lay Network Multipath Routing Protocol (ONMRP). In this paper we describe the main features and basic op-erations of the SIMONs and outline the design and func-tionalities of DONCP.

INTRODUCTION

Future battlefield networks are likely to exploit commer-cial routing protocols. Standard protocols such as OSPF [1], BGP [2], MOSPF [3], DVMRP [4] and PIM [5,6]

can support most basic unicast and multicast communi-cations. There should only be occasional need for com-pletely replacing commercial protocols, such as in small Mobile Ad-hoc Networks (MANETs). This raises the question of how to provide additional capabilities, such as enhanced routing, efficient network processing, and information-centric networking, to increase robustness, efficiency, and QoS, which will be needed for many military applications and networks such as FCS and WIN-T. Enhanced routing, for instance, can provide a higher level of robustness to overcome high and variable wireless bit-error-rates by sending messages over multi-ple disjoint paths without altering the underlying IP rout-ing tables. In addition, one can provide QoS routing based on delay requirements or bandwidth requirements or both. The network processing capability can offer traffic aggregation and redundant FEC for efficient use of network resources and added reliability. For instance computational graphs may be created to aggregate in-formation. Information-centric-networking allows higher layer abstractions, such as connecting to local nodes, which are not tied to an ephemeral underlying IP ad-dressing.

All of these capabilities can be added at the network layer. However, implementing these features in the net-work layer has three major drawbacks. First, it de-creases the potential of exploiting commercial off the shelf routing protocols and network elements. Second, it will significantly increase the complexity of the routing protocols, creating scaling problems. Third, it makes the network more vulnerable by overloading network traffic with non-optimized data communications.

In this paper we present a novel solution to provide en-hanced capabilities through Self-Initiated and Self-Maintained Overlay Networks (SIMONs). The tools to create SIMONs are plug-and-play, scalable, application-level solution that allow the implementation of enhanced routing and network processing without major support form the network layer. SIMONs are designed to func-tion in dynamic networking environments where station-

Page 2: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Self-Initiated

2

ary and mobile nodes coexist, without the need for hu-man intervention. In addition to the self-initiating, self-configuring and self-managing protocol, a suite of uni-cast, multicast, and multipath routing protocols have been developed as applications of the SIMON.

The rest of this paper is organized as follows. First, we present the design goals and an overview of the basic concept and main features of the SIMON in Section 2. We discuss the design alternatives in Section 3. We then present the functional components and architecture of SIMON in Section 4. In Section 5, we outline the Dy-namic Overlay Network Configuration Protocol (DONCP), the main vehicle for the SIMON. Finally, we conclude in Section 6 with a summary.

DESIGN GOALS AND SIMON OVERVIEW

A. Design Goals The goal is to create an information-centric overlay net-working environment on top of an existing IP network. The virtual environment enables us to implement effi-cient proprietary networking protocols such as QoS rout-ing, multipath routing, multicast routing, etc, in highly mobile networks. The main design goals are to create overlay networks:

• That are robust, i.e. the loss of nodes should not greatly deteriorate the performance. Moreover, we must avoid the need for manual miss-configuration and adapts to changing topologies.

• Where nodes should automatically discover other nodes in the same overlay and connect to them. As nodes move and change IP addresses, the overlay must adapt and reconfigure the nodes.

• That are scalable to span the whole Internet if need be. • That do not rely on a central node, which may be-

come a hot spot and present a bottleneck for the net-work. The centralized approach could also cause ro-bustness problems. If the central point is lost due to an enemy attack or due to mobility, the whole net-work may experience a large degradation in perform-ance.

• That should exploit and inter-work with common off the shelf (COTS) protocols. Overlay must work over existing routing protocols such as OSPF, MOPSF, BGP, PIM, and MANET.

• That are transparent to IP and should not affect IP routing decision nor change existing IP routing tables.

• Where non-capable (legacy) nodes in the network must not compromise the capabilities.

• That provide flexible routing. For example, use of powerful proprietary routing protocols to reduce bandwidth (e.g., using multicast for efficient distribu-

tion) and/or latency (e.g., using multipath routing for robust real-time applications) by orders of magnitude.

• That can be computation graphs using intermediate node data processing. For instance, aggregate raw in-formation to reduce bandwidth needed by several or-ders of magnitude.

• That can use path prioritization techniques to route its packets (e.g., prioritize high bandwidth links and re-sources to only critical applications).

B. Comparison to VPNs In many aspects our goals resemble IP-based Virtual Private Networks (IP-VPNs) [6]. However, the goals are uniquely distinguished from traditional IP-VPNs by the following characteristics:

• Self-initiated, self-configured and self-maintained networks. Hence eliminating slow and error-prone manual configurations.

• Support an information-centric naming scheme to reflect information rather topology.

• The suite of protocols runs above the IP layer, and does not require any network support.

• Supports proprietary, non-standardized routing proto-cols to support multicast, multipath and unicast rout-ing with no network support.

• Provide intermediate node information processing. For instance, they can provide information aggrega-tion and FEC booster functionalities.

In addition, IP-based VPNs are traditionally designed to work in static networks, where network elements are stationary and thus, network configurations do not change dynamically. Our goals are to develop solutions with a dynamic networking environment in mind, where end-subscribers and routers are highly mobile. One of the main goals is its self-reconfiguration. Automating node and network configuration results in fast and accu-rate adjustment to changing environments and minimizes the need for network management.

SIMON OVERVIEW

Self-Initiated and Self-Maintained Overlay Networks (SIMONs), that meet the goals listed above, are created and maintained using efficient mesh structures. In each network domain, SIMON nodes that belong to a logical group form a virtual mesh. A mesh is built subject to application criteria. For instance, if the application re-quires high connectivity, a dense mesh is built. How-ever, if the application requires a lightly connected to-pology then a sparse mesh is built. A mesh can also be built to maximize throughput between SIMON members, or minimize delays, or both. The meshes are built using a flexible Dynamic Overlay Network Configuration Pro-tocol (DONCP). DONCP is the vehicle that enables us

Page 3: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Self-Initiated

3

to custom-build virtual meshes that suite application and environment requirements.

In order to provide seamless services to its applications, an SIMON must maintain a mesh structure that is con-sistent with current network configuration in the dy-namic environment.

SIMON ARCHITECTURE

SIMON is composed of a set of dynamic SIMON serv-ers and SIMON member nodes. Each node in a SIMON, if capable, can function as an SIMON server. We as-sume that each node is pre-configured with certain capa-bilities such as its processing power, its memory capa-bilities and if it can act as a server. We also assume that some nodes in a SIMON may not have the capability (such as processing power, memory, etc) to act as serv-ers. Hence these nodes rely on the existence of some other nodes capable of performing the duties of servers.

LGS DVNS LGS DVNS

GGS

Figure 1: Functional components and interactions among them in the SIMON architecture

Each network maintains separate SIMON servers, serv-ing SIMON member nodes in each domain. Specifically, in each domain, two SIMON servers exist: a Local Group Server (LGS), and a Domain Virtual Network Service (DVNS) server. In addition, local group servers are connected through a Global Group Server (GGS). A single GGS exists for each SIMON. Similarly, in each domain, a separate LGS exists for each SIMON. How-ever, all SIMON nodes in a domain share the services of a DVNS server. The hierarchy of the SIMON compo-nents along with interactions among them is shown in Figure 1. A brief description on the key functions of each of the SIMON components follows.

C. Domain Virtual Network Service (DVNS) Server Each network domain contains a DVNS server. A DVNS server has a similar functionality to that of a DNS server and may be integrated with a DNS server. More specifically, a DVNS server maintains a database con-

taining information about SIMONs in its domain. Each DVNS maintains a mapping that translates a SIMON name into an IP address of either an LGS or a GGS. When a SIMON node is first turned on, it starts by dis-covering existing nodes that belong to the same SIMON. SIMON nodes use the DVNS server during this discov-ery phase. First the SIMON node sends a discover mes-sage to the DVNS. The message includes the SIMON name. The DVNS responds with the IP address of the LGS if one exists; otherwise, the IP address of the GGS is returned.

D. Local Group Server (LGS) An LGS is a database, local to a domain, which main-tains IP addresses of all the member nodes in its SIMON in the local domain. In addition, the LGS maintains a list of selected SIMON member nodes from other do-mains. This second list provides inter-domain connec-tivity of the SIMON nodes. The LGS provides new member nodes with a list of member nodes in the do-main. In addition, the LGS also provides IP addresses of member nodes in other domains. New member nodes select potential virtual neighbors from these two lists. Once a new node selects potential virtual neighbors from the lists, a set of message exchanges is initiated between the new node and the potential neighbors. Eventually the SIMON mesh is extended.

In addition to providing new member nodes with infor-mation to help them connect to the SIMON, an LGS has another key functionality. Specifically, the LGS guaran-tees the connectivity as well as the integrity of the SIMON mesh. This task is achieved by periodically ini-tiating a hello-wave in its overlay network. Periodically, the LGS sends hello messages to all of its virtual neighbors. When a node receives a hello message, it echoes the message back to the sender. In addition, it forwards the message to all of its virtual neighbors. Therefore, these hello messages propagate from the LGS and reach all SIMON member nodes in the domain.

The hello-wave has two functionalities. First, through the exchange of hellos between neighbors, member nodes learn about the connectivity to their neighbors. Second, when a node receives a hello message, it knows that is part of a mesh that contains an LGS. The lack of reception of hello can be the result of either of two prob-lems. Either the node is disconnected from the mesh, or the LGS has failed. We will further discuss the recovery plan in a later section.

E. Global Group Server (GGS) A global group server (GGS) is a globally unique entity for each SIMON. The GGS for each SIMON resides at the top level of the SIMON servers’ hierarchy. A GGS has several roles the main of which is the coordination

Page 4: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Self-Initiated

4

between local group servers in each domain. In addition to coordination, a GGS provide a line of communication between LGSs and facilitates in determining the where-abouts of certain SIMON member nodes. Furthermore, the GGS maintains a sample list of member nodes in each domain. These lists are periodically swapped be-tween LGSs in different domains.

The meshes maintained in the SIMONs are dynamically updated as the network configuration changes as new members join/leave a group or SIMON nodes move from one domain to the other. The SIMON manages its meshes and member nodes using the Dynamic Virtual Network Configuration Protocol (DONCP) designed to support the SIMON operations. In the following section, we outline the main features of DONCP.

DYNAMIC OVERLAY NETWORK CONFIGURA-TION PROTOCOL (DONCP)

DONCP is the main vehicle for initiating, initializing and maintaining the SIMONs. DONCP performs three key functions: (i) it allows new member node to join an existing SIMON, (ii) it maintains the SIMON mesh, and (iii) it assures the proper update of all databases when connectivity changes due to mobility or server failures. In the rest of this section we outline some of DONCP’s operations. Specifically, we describe the join operation and the recovery from server failure and mesh splits. We omit the detailed definitions of DONCP’s protocol messages due to the space limitations.

A. New Node Joining When a new SIMON node comes into a domain, it must first get configuration parameters including an IP ad-dress. We assume that there is an existing mechanism to perform the IP configuration. For instance this could be done using a DHCP server or IPv6 stateless auto-configuration. During this initial IP configuration, we assume that the node learns about the IP address of the DVNS in its domain through DHCP1. Once the IP ad-dress of the DVNS is known, the node contacts the DVNS server to inquire about a certain SIMON through the use of a discover message. The message includes the name of the SIMON that the node wishes to join. The DVNS server responds with the IP address of either the LGS in its domain or the GGS for the specified SIMON.

The IP address of the GGS is returned only if there is no known LGS in the domain. Once the IP address of either the local or the global server is obtained, the new SIMON node contacts the server. Figure 2 shows the

1 If the DHCP server is not capable of such functionality, a broadcast message could be sent to discover the DVNS.

message flow for a new node to discover and join an existing SIMON. The new node contacts the server (GGS or LGS) using a get_list message. This message requests a list of SIMON members from the server. The server (GGS or LGS) responds with an offer_list mes-sage providing a list of known members of the SIMON. The new node selects a set of potential virtual neighbors from the list and sends join_req messages to the selected members. The number of potential neighbors selected and the method by which they are selected can be deter-mined based on the application requirements. For in-stance, neighbors can be selected based on some quality of service measures such as throughput and/or delay as seen by the node.

DHCP Discover

DHCP Offer

SIMON Discover

SIMON Offer

Join_REQ

Join_Accept

Join_Ack

Get_List

Offer_List

DVNS DHCP New SIMON Node GGS/LGS Existing SIMON Node

Figure 2: DONCP Node discovery message flow A node that receives a join request can decide to accept the request or to reject it. If a request is granted, a join_accept is sent back, otherwise a join_reject is sent. A node may choose to reject a request based on its own capabilities. For instance, a node may not want to ex-ceed a pre-determined maximum number of neighbors. The requesting node must acknowledge a join_accept message for the mesh link to form. This flexibility is included in the protocol to allow new nodes to request to connect to more neighbors than it actually needs. For instance, if many nodes accept, the new node can then pick only those neighbors that can provide it with a cer-tain required quality of service.

In the case where no LGS exists in the domain, the new node, if capable2, can request from the GGS to serve as the LGS for its domain. This can be achieved using a

2 We assume that each node is pre-configured with its capa-bilities. For instance it should have enough processing power and memory to function as a server.

Page 5: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Self-Initiated

5

server_req message. First the GGS checks if an LGS already exists. In the affirmative, the GGS denies the request; otherwise, the GGS accept the first request it receives.

B. LGS Failure and Mesh Split SIMONs are designed to work in dynamic and volatile network environments where nodes are highly mobile and links are unreliable. Therefore, DONCP is designed to detect and recover from faults such as server failures and link failures. SIMON connectivity integrity is achieved through LGS’s periodic initiation of hello waves. In this section we present the procedures to re-cover from an LGS failure as well as a mesh split.

A mesh is considered split, if connectivity is lost be-tween member nodes resulting in two or more uncon-nected meshes. When a SIMON mesh splits into several smaller sub-meshes, only one of the sub-meshes contains the LGS. Hence all nodes in sub-meshes that do not in-clude the LGS do not receive the hello-wave. Hence, member nodes detect the loss of connectivity, or mesh splits, through the lack of reception of hello messages for a predetermined period of time.

In addition to signaling a loss of connection, the lack of hello messages may also be the result of an LGS failure. Since a member node cannot distinguish between a mesh split and an LGS failure, the recovery procedure used to recuperate from both faults is the same.

A SIMON can potentially have tens of thousands of member nodes. The recovery procedure from a SIMON split or an LGS failure must be scalable and should incur minimal overhead. In the following, we present these recovery procedures that deal with both mesh splits as well as LGS failures. When a SIMON member node does not receive a hello message from its virtual neighbors for a predetermined amount of time, it per-forms the following procedure:

(1) Set a timeout timer t. Sleep until the timer expires. The timeout value t is selected from a uniform dis-tribution in the interval [0, max_timeout]. The timer-based activation reduces the likelihood that a large number of SIMON nodes perform the procedure at the same time causing an unnecessary strain on the network.

(2) When the timer expires, if the node is not capable of serving as an LGS, go to step (5). Otherwise, the node declares itself as an LGS and initiates a hello-wave. Any SIMON node that receives the hello message stops its timer and responds to the message by reporting to the new LGS and propagating the hello-wave to its neighbors

(3) Send a serve_req message to notify the GGS that it has volunteered to serve as an LGS for the domain. GGS accepts the request only if there is no reachable LGS in the domain. Otherwise, the GGS responds with a serve_nack that includes the IP address of the existing LGS.

(4) When the node receives a serve_ack message from the GGS (i.e., the node has been selected as a new LGS), it registers itself to the DVNS using a register message. If the node receives a serve_nack how-ever, the node suspends its LGS functionalities and contacts the existing LGS and connects to some new member nodes.

(5) If timer expires and the node is not capable of serv-ing as an LGS, it contacts the DVNS and tries to discover the SIMON and connect to it.

CONCLUSION

A Self-Initiated and self-Maintained Overlay Network (SIMON) is a new idea that brings promising features. Its key feature -- implementing self-configuring virtual network that support enhanced networking applications while minimizing the complexity in the IP layer -- pro-vides great efficiency and flexibility in managing net-work traffic by allowing the use of enhanced networking protocols. The Dynamic Overlay Network Configuration Protocol (DONCP) is the main engine of the SIMON. DONCP is developed with scalability in mind; that is, its performance scales well with size of the network. Fast auto-configuration feature of the SIMON, along with all its merits mentioned above, provide an adequate envi-ronment for mission-critical military communications, where efficient resource utilization and a high level of QoS assurance are required in dynamic and heterogene-ous networks.

REFERENCES [1] J. Moy, “Open Shortest Path First (OSPF) Version 2,”

RFC-1247, July 1991. [2] K. Lougheed and Y. Rekhter, “A Border Gateway Pro-

tocol (BGP),” RFC-1105, Cisco Systems, T.J. Watson Research Center, IBM Corp., June 1989.

[3] J. Moy, “Multicast Extensions to OSPF (MOSPF),” RFC-1585, March 24, 1994.

[4] Deering, D. Estrin, D. Farinacci, V. Jacobson, “Proto-col Independent Multicast (PIM), Dense Mode Proto-col specification,” work in progress, march 1994.

[5] Deering, D. Estrin, D. Farinacci, V. Jacobson, L. Ching-gung, and W. Liming, “Protocol Independent Multicast (PIM), Sparse Mode Protocol specification,” work in progress, march 1994.

[6] B. Gleeson et al., A Framework of IP-Based Virtual Private Networks, IETF, RFC 2764, February 2000.