Multi-level Distributed Discovery and Dissemination …...11/9/2014 The Multi-level Distributed...

Services Working Group

Multi-level Distributed Discovery and Dissemination

Capability Pattern

Approved for Public Release

SERVICES WORKING GROUP

Multi-level Distributed Discovery and Dissemination Capability Pattern

Version 1.0 11/9/2014

The Multi-level Distributed Discovery and Dissemination (MD3) Capability Net-centric Pattern prescribes an approach for reliable data discovery and dissemination for a system, or systems of systems, working within the challenging and dynamic environment of a mobile ad hoc network (MANET). This pattern uses a distributed registry to enable Service Oriented Architecture (SOA) features such as loosely coupled services. It also improves stability and connectivity of the network through associated metadata modeling, processes and platform attributes. The main element of this capability pattern is an approach for both registry and dissemination that does not transmit non-essential information across the network, which can cause system performance degradation. Key to this pattern’s architectural approach is a network overlay that allows network entities the flexibility to adapt and change their roles as platforms and related node types changes within a volatile network.

© 2014 Network Centric Operations Industry Consortium (NCOIC®). All Rights Reserved. NCOIC®, NCAT®, NIF®, SCOPE®, NRRC™, RRI™ and QuadTrangle™ are trademarks of NCOIC.

NCOIC MD3 Pattern v 1.0 Approved for Public Release 9Nov2014 of 39



Capability Pattern

VERSION HISTORY Version # Description Date Author

1.0 Initial Release 11/9/2014 Services WG

Acknowledgements

The following individuals have participated in the creation of this document and are gratefully acknowledged:

Chair

Paula Moss, Raytheon

Primary Authors & Editors

Allen Jones, Boeing

Paul Schoen, Boeing

Rex Brooks, Starbourne Communications

Mark Bowler, Boeing




Capability Pattern

Table of Contents 1 Introduction .............................................................................................................. 5 1.1 Problem Statement ............................................................................................. 6 1.2 Context ............................................................................................................... 6 1.2.1 Service Oriented Architecture ................................................................................. 7 1.2.2 Environment ........................................................................................................... 9 1.2.3 Scenario ............................................................................................................... 11 1.3 Issues Addressed ............................................................................................. 12 1.4 Expected Benefits ............................................................................................ 14 1.5 Definitions ......................................................................................................... 15 2 Recommended Solution ......................................................................................... 17 2.1 Actors ............................................................................................................... 17 2.2 Interfaces .......................................................................................................... 19 2.3 Preconditions .................................................................................................... 19 2.4 Structure ........................................................................................................... 20 2.4.1 Network Overlay Structure ................................................................................... 20 2.4.2 Network Entity Aggregation .................................................................................. 21 2.4.3 Discovery Domains .............................................................................................. 22 2.4.4 Advertisements .................................................................................................... 23 2.5 Capabilities ....................................................................................................... 23 2.5.1 Discovery Service Capability ................................................................................ 23 2.5.2 Dissemination Service Capability ......................................................................... 25 2.5.3 Data Model Mediation Capability .......................................................................... 27 2.5.4 Information Assurance Bridge Capability .............................................................. 27 2.5.5 Quality of Service Capability ................................................................................. 28 2.6 Behavior ........................................................................................................... 29 2.7 Post Conditions ................................................................................................ 32 3 Related Patterns .................................................................................................... 33 4 References ............................................................................................................. 34 4.1 Documents ....................................................................................................... 34 4.2 Standards ......................................................................................................... 34 5 Acronym List .......................................................................................................... 35 6 Appendices ............................................................................................................ 37 6.1 Emergency Response Scenario Details ........................................................... 37 6.1.1 General Assumptions ........................................................................................... 37 6.1.2 Emergency Response Equipment ........................................................................ 37 6.1.3 Proactive Timeline (Emergency Preparedness Timeline) ..................................... 38 6.1.4 Reactive Rapid Response Timeline (T + 96 hours) .............................................. 38 6.1.5 In-country Infrastructure Recovery ....................................................................... 39




Capability Pattern

List of Figures Figure 1-1 Legacy and Net-centric Approach Architectures ............................................ 7

Figure 1-2 Participants and Actors in a Service-orientated Architecture ......................... 8

Figure 1-3 Scenario Communication Cloud ................................................................... 11

Figure 1-4 Unanticipated Partner Problem .................................................................... 13

Figure 2-1 Physical and Overlay Networks ................................................................... 21

Figure 2-2 Discovery Domain Overlay Network ............................................................ 23

Figure 2-3 Discovery System Architecture .................................................................... 25

Figure 2-4 Messaging Services Context Diagram ......................................................... 26

Figure 2-5 Relationships of Dissemination Models ....................................................... 27

Figure 2-6 Example Distributor Layout .......................................................................... 29

Figure 2-7 Steps to Data Dissemination ........................................................................ 31

List of Tables Table 2-1 Example Network Entities and Roles ............................................................ 19

Table 3-1 Related NCOIC Patterns ............................................................................... 34




Capability Pattern

1 Introduction The Network Centric Operations Industry Consortium (NCOIC) develops tools that foster interoperability and net-centricity. NCOIC patterns are architecture “fragments” that solve a stated problem. Patterns may cover one or more net-centric capabilities and interoperability solutions. They represent a partial decomposition of architecture into generic components that may be tailored to support integrated architectures, fostering reuse. NCOIC has three pattern types: operational, capability and technical.

Today’s network environment is characterized by fixed network infrastructures such as enterprise networks and mobile networks with wireless connectivity to fixed communication towers. The fixed network is stable and high bandwidth. Mobile networks are increasingly providing moderate bandwidth, reliable connections when the user is within coverage areas. A third network type is the mobile ad hoc network (MANET) where there are limited, damaged or no fixed towers and the network must be constructed from available node-to-node communication paths. Such networks are typically low bandwidth with frequent connections and disconnections. This pattern addresses the problem of reliably discovering and disseminating data between systems working within the challenging and dynamic environment of a mobile ad hoc network.

A MANET may or may not have a centralized structure. Peer nodes1 on such a network connect, disconnect and reconnect at will. In some cases, peer nodes select a transient centralized point, while in other cases the network remains truly ad hoc. In an ad hoc network that lacks fixed infrastructure, there is no persistent network backbone on which service discovery and communications can rely for constant connectivity between nodes. This lack of structure becomes an aspect of the problem domain as opposed to a component of the solution.

This Multi-level Distributed Discovery and Dissemination (MD3) Capability Pattern addresses computer network capabilities for interoperability in a MANET environment. Implementation of systems conformant with this pattern allows networks that may or may not have a centralized control point to consume and provide services,2 gaining benefits inherent in utilizing a SOA. This capability, as described here, is provided as an overlay3 to existing or proposed systems that contain multiple networks having

1 See section 1.4 for definition of the terms “node,” “platform” and “entity.”

2 The term “service” is used in the context of a Service Oriented Architecture (SOA), and is defined in the NCOIC Net-centric Services Framework (NCSF) as well as in OASIS and The Open Group documents.

3 An overlay network is a computer network built on top of another network. Nodes in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links in the underlying network. (Text taken from http://en.wikipedia.org/wiki/Overlay_network.)


http://en.wikipedia.org/wiki/Overlay_network



Capability Pattern

central providers and multiple sets of consumers. Adopting this pattern will improve stability and connectivity of the network.

The growth of Service Oriented Architecture (SOA) has resulted in diverse, valuable applications being made available as services. The capability described by this overlay pattern, when incorporated in Software as a Service, can enhance the user’s ability to get the needed information anywhere and anytime – the key to net-centricity. Systems with such capability frequently interoperate with a variety of external systems, ranging from existing legacy products to products that may not yet exist. Therefore, a sustainable system must allow for technology changes and insertions.

This document outlines net-centric capabilities that address multiple environments, including present and future physical equipment. It discusses the benefits of this capability pattern from both a technical perspective (software, architecture and implementation) and a programmatic perspective, including benefits to the operational user and service developer.

This document is organized as follows: Section 1 introduces the problem; Section 2 describes the “to be” state of the architecture after application of the pattern requirements contained in that section; Section 3 describes lessons learned and expert advice; Section 4 identifies document references; Section 5 contains a list of acronyms used in the document; and Section 6 contains appendix material describing an emergency response scenario and how this pattern can help address the challenges presented by the scenario.

1.1 Problem Statement The problem addressed by this pattern is the reliable discovery and dissemination of data within the challenging and dynamic environment of a mobile ad hoc network (MANET), in which network connections may be dynamically changing, intermittent and with limited bandwidth. The prescribed solution must work within a net-centric service-orientated architecture environment.

1.2 Context At a high level, this pattern applies to situations in which software services need to be used over a network infrastructure, whose structure and capacity is in constant change, and the availability of services is intermittent or rapidly evolving. A typical reactive scenario could be disaster areas in which the network infrastructure has been destroyed or never existed, but the required response time precludes waiting for fixed structures to be installed or all network services to be available before operations start. There are proactive scenarios as well, in which the value of not relying on a network infrastructure eases the development and integration of new capabilities.

The graphic on the left in Figure 1-1 shows the conventional point-to-point architecture employed by organizations such as local fire-fighting organizations. In this common legacy architecture approach, each participant comes with its own messaging and transport mechanisms requiring interfaces be developed by each system to exchange




Capability Pattern

information in a trustable manner to any other system in the network. To be time effective, the partners need to be preplanned so that these interfaces or proxies can be developed and tested prior to any deployment. It also requires the duplication of data in multiple messages so that each system can communicate natively. The graphic on the right side of Figure 1-1 shows a net-centric architecture approach that is possible through application of this capability pattern.

Figure 1-1 Legacy and Net-centric Approach Architectures

1.2.1 Service Oriented Architecture This document will use the term “producer/consumer” with respect to the application service model to avoid confusion with the provider/consumer models used for healthcare, web applications and publish-subscribe architectures. In these models, providers can be any entity such as a human, company or software that creates or provides information or services for use by consumers. In the enterprise software realm, this transfer is often completed through web services or a publish-subscribe communication mechanism. The producer/consumer model4 is a software-specific approach to SOA for tactical domain systems (versus enterprise domain systems). The term “provider,” as described in the OASIS Reference Model for Service Oriented Architecture and other NCIOC documents, is a superset of the term “producer,” which is used to particularly address software services registered by providers with a discovery

4 The Producer/Consumer Model was established by experts on component software development at the 8th International Symposium on Component-based Software Engineering, and has been adopted by many groups such as the National Instruments Developer Network.




Capability Pattern

server and intelligently made available to consumers via a mediating service (see Section 1.1.1 for more details on mediators).

The producer/consumer pattern is used to decouple software services and processes that produce and consume data at different rates. Specifically with the pattern discussed in this document, by use of discovery, sharing of information across the network can be managed to avoid non-essential information being broadcast on the network, thereby reducing effective throughput.

Within the context of an SOA, there are three main actors: consumers, producers and mediators (shown in Figure 1-2). The producer is a service/data supplier. As the name suggests, the consumer consumes the data (or service) provided by the producer. There may be multiple consumers for a single service. There may be multiple producers that could respond to a consumer’s query for a service. A mediator serves as the linking agent for the establishment of producer/consumer connections, and may also be known as a broker.

Figure 1-2 Participants and Actors in a Service-orientated Architecture

As shown in Figure 1-2, the relationships between these participants are straightforward. Either the producer or consumer can initiate a connection. The producer “advertises” to the mediator that it has a service/data available. The consumer queries the mediator for available producers that meet the consumer’s criteria. The consumer then establishes a connection to an available producer. As such, the consumer and producer are not tightly coupled and either can be first in its action, but no action, such as transmitting of data, is performed until they have been paired. This limits the bandwidth requirements on the constrained MANET network. Each of the actors may be on the same platform or on separate physical platforms (including fixed installations and/or moveable/moving vehicles such as aircraft, trucks, ships, etc.).

In a MANET suitable for the scenarios described in the next section, some or all the platforms on a network need to accommodate more than one of the consumer, producer or mediator functions. In this way, in the case of platform failure, a nearby platform can be substituted for the missing function(s) without the MANET network failing. For example, nodes that are fielded for reporting of data to a central control point in a




Capability Pattern

MANET may change roles and also be used to provide imagery to assist other users of peer systems, or be configured to receive lifesaving imagery data. They may also be provided with limited or substantial capabilities to serve as a local directory to keep track of their peers or remote users. In some cases, this capability may be only partially provided due to the inherent legacy capability and/or authorization of certain nodes within the network.

Platforms within this paper are often referred to by their role or service, such as an edge role, legacy role or client role. Entities may also be referred to by the term “node.” A node type is defined by its own perspective of the network. That is, a node could be a master, child, parent, peer, sub, super peer or boundary node, based on its “view” or position within the network or relationship to other entities. A node can be one or more of these at any time, as its view is from a specific reference point.

Service-orientated architectures are beneficial in net-centric environments in that they provide levels of flexibility and scalability that are difficult to achieve by other approaches. One example of this is the ability of a service consumer to dynamically change service providers.

1.2.2 Environment The following section provides examples of environments in which this capability pattern enables reliable and secure communications across a MANET. These conditions include the following common needs that transcend any particular scenario.

• There is limited or no network infrastructure available prior to systems arriving and engaging in operations using a MANET overlay. Local area networks (LANs), if available, will be connected to the wide area network (WAN) via the MANET.

• The network infrastructure, to a great degree, is “what you bring with you.” • There is limited available bandwidth (due to shared spectrum), and networked

resources are constrained by network access, packet size or timeliness of information.

• The network topology is constantly changing with platforms entering or departing the network randomly and, in some cases, due to connectivity losses.

• There are unanticipated network resources that may have joined later or joined out of necessity due to unanticipated situations.

The environments described in this section are categorized as either reactive or proactive, where reactive indicates an environment in which there is a need to respond to some unplanned event, such as the sudden loss of high bandwidth infrastructure, and where proactive indicates an environment where there is a desire to create and deploy ad hoc systems for activities that require greater mobility and flexibility. This Capability Pattern can be applied to both proactive and reactive environments with only minor differences in the paradigm. In many cases, the expectation will be for systems to




Capability Pattern

seamlessly move from a proactive to a reactive condition, such as when existing government or medical systems move into areas of destruction or conflict.

1.2.2.1 Reactive Environment Societies and their existing network infrastructures are in constant threat of unforeseen damage caused by natural events, such as hurricanes, earthquakes, tornados and volcanic eruptions, as well as by human destruction, such as urban warfare and terrorist activities. The effects of these disasters can quickly overwhelm local resources in emergency situations. Normal communication systems can be rendered inoperable by sheer instantaneous use of the system itself or by destruction of key communication components. In the event of a disaster, this destruction or failure of the communication infrastructure is usually accompanied by an imperative need for a reliable network to enable emergency and government responders to help and coordinate reestablishment of the basic needs of survivors, execute counter attacks and/or coordinate incoming resources and assistance.

In a disaster like the scenario discussed in the next section, special operations and first responders, including emergency care teams and government personnel, arrive in remote and/or compromised areas where the network infrastructure is non-existent, inoperative or limited due to damage caused by the disaster. Responders must rely on their own communication network resources to exchange vital information needed for search-and-rescue operations. This creates high demand for emergency equipment and platforms with the ability to operate distributed networked services on narrow bandwidth and/or unreliable channels, as well as the capability for limited emergency systems and any operational commercial or government systems to interoperate until full communications are restored.

Reactive systems must also adapt to changes to the environment and network, such as expansion of the area of destruction into wider territories and introduction and/or loss of new threats, allies and resources.

Most societies today invest in and rely on emergency equipment and platforms that use enterprise-based communications and operate on a normal power grid with high-bandwidth resources. These approaches often assume that incidents can be controlled from a static location and ignore the need for interoperability with adjacent unanticipated enterprise systems and limitation of bandwidth by the frequency spectrum in use. This pattern provides a paradigm for societies to take a proactive approach to disaster preparedness that includes an emergency communication infrastructure that can operate in severe and ad hoc environments with the ability to adapt to constantly changing resources and partners. However, the proactive condition is not limited to an environment of emergency preparedness; it includes a variety of isolated, volatile and/or flexible communication systems, such as those used by the power industry and other utilities such as water districts, the healthcare industry, and even small exploration missions and event coordination.




Capability Pattern

1.2.2.2 Proactive Environment In a proactive environment, communication systems are established to work with interoperating systems under various levels of bandwidth and connectivity. In most proactive scenarios, communication systems can benefit from high-bandwidth connections for certain actions but must also be able to work disconnected with minimal transition steps. Proactive environments include complex scenarios, such as an adaptable smart energy grid with intelligent connections between sensors, meters and controllers to enable immediate communication of and response to power outages and surges. However, proactive environments can also involve smaller ad hoc networks, such as those used by room-to-room hospital equipment, event coordinators at sporting events, and small governmental or civilian teams deployed in remote disaster-response situations.

1.2.3 Scenario This pattern is applicable to any scenario where a mobile ad hoc network (MANET) is being used to provide network communications. One such scenario is illustrated in Figure 1-3 and discussed in the following sections. Please note that this single pattern is not intended to be an all-inclusive solution to all challenges of the scenario.

In this scenario, a rapid evaluation and corrective action team (REACT) is deployed to an international disaster zone to reestablish critical communication and cloud computing services in a MANET network. The scenario assumptions, proactive and reactive actions, and a readiness timeline for deployment of REACT personnel and equipment are described in the Appendix. The next paragraph outlines the actions taken by the REACT personnel. Please note that this pattern is applicable to a very wide range of possible scenarios and missions.

Figure 1-3 Scenario Communication Cloud

Producers/Consumers

Nodes




Capability Pattern

Upon arrival into the disaster area, REACT personnel deploy the Mobile Command Center and the primary mediator nodes to form the initial MANET network. The team’s aviation assets are transitioned to transport critical supplies and provide medevac airlift services to designated hospitals. The REACT personnel then begin the task of joining the disparate unanticipated user systems as they arrive so they can share information through their respective interoperability services. Unanticipated users may be established as either information producers or consumers, or in some cases both. The REACT personnel and equipment also become more than facilitators and mediators on the network. They join search-and-rescue efforts and become producers of information, providing video, for example, to producers and consumers through their electro-optical camera as the team steers the vehicle throughout the area searching for survivors and assessing damaged infrastructure. As unanticipated users join the network, the information they bring is made available to the growing number of producers and consumers via the mediators.

The scenario described above is assumed to have platforms deployed at random locations and times throughout the disaster area, with the platforms spaced approximately zero to 10 km apart. The distance from a point where long-haul communications are available to a platform designated as an edge node may be up to 40km. Given the possibility of rough terrain, there may be 4 or 5 platforms in the path between the most distant platform and a gateway terminal such as a SATCOM terminal or cell phone tower. Platforms in this scenario may be continuously moving, disconnected, intermittent or otherwise limited such that their availability may vary continuously.

1.3 Issues Addressed The prescribed solution must address the following issues:

1. Service interfaces must be stable and sufficiently de-coupled so that the consumer of the service can continue to operate even if the provider or the provider’s interface changes.

2. The network should accommodate nodes having varying roles and capabilities. 3. The nodes should provide the most efficient use of bandwidth between nodes. 4. The network must allow an unanticipated partner or user to join without a

previously developed plan and initialization of the system.

This last issue is referred to as the unanticipated partner problem, discussed below. It is of particular importance because many of the scenarios to which this pattern applies may include the unexpected, unanticipated or unplanned addition of new participants (data or service consumers and/or providers) to the network after its initial deployment.




Capability Pattern

Figure 1-4 Unanticipated Partner Problem

Figure 1-4 depicts the unanticipated partner problem as a 2x2 matrix. If both the platform and data/processes for a particular node are known (the bottom left quadrant), then all interactions can be defined and planned and message-based communication can be applied. Note that the addition of a discovery and dissemination (D-D) pattern, even in this case, has the advantage of eliminating the need for pre-knowledge or pre-planning and allows ad hoc connections within the known or defined network. Discovery and dissemination, however, become more important where some of the platforms and data or processes are unknown prior to the network being established.

If the platform is known but the data/process are unknown (upper left quadrant), a D-D pattern will allow the system to determine what the data or service is, whether it is trustable and how to exploit it without changes to the existing services. This is important over time, as it allows the system to be upgraded with incremental methodology when software upgrades, new capabilities and new features become available, rather than a block upgrade (where multiple changes are synchronized) being required.

If the services are decomposed sufficiently and an orchestration engine is use, then most, if not all, operational concept changes can be accomplished outside of software changes. Similarly, when known services/data show up on the network from a previously unknown platform, new consumers/providers can join the system without




Capability Pattern

having to push new configurations or registries to every platform (lower right quadrant). This becomes important as the activity in question becomes an international support activity. New participants can join the activity without previous knowledge of their existence and the resultant team is truly a logical “one team.”

The unknown-unknown situation (upper right quadrant) will further stress the technology to determine trust and usability of the completely ad hoc formation and resultant network, but this topic is not addressed in this version of the pattern.

1.4 Expected Benefits This pattern provides:

• Technical Benefits o Continuous connectivity over available physical networks o No system performance degradation because of unnecessary information

exchange o Discovery and dissemination services that allow for technical changes and

insertions as well as unanticipated users without preplanning or initialization o Most efficient use of available bandwidth o Ability for an unanticipated partner to join the network with minimal

information for peer communication • Programmatic Benefits

o Ability of providers to achieve familiarity with recommended patterns incorporated into system procurements (although procurements may be open to industry, a provider familiar with the pattern has a lower learning curve)

o Decomposition of the problem space (or software service) with the resultant implementation being distributable across the network

o Reduction in bandwidth requirements of the network, as the only data being consumed is transmitted from the producer

o Ability for rapid changes to be realized by the REACT personnel, including changes to individual components and/or changes to the business logic used for orchestration of the component services

o Reduction or elimination of system capability integration activities • Operational Benefits

o Improved situational awareness (SA) when used to exchange SA-relevant information in challenging, mobile ad hoc networks

o Improved interagency interoperability and communication




Capability Pattern

1.5 Definitions The following are definitions of key terms used in Section 2 of this document.

Primary Definitions Actor An agent or entity performing some function or action within the

network. May be a software application (such as a software service) running on a host computer or a human operator requesting or performing some mission function. Actors have one or more roles within the network and perform one or more functions.

Network Entity An entity connected to the network, interacting or exchanging information with other network entities, and performing some role or function.

Node A logical representation of some physical or abstracted entity residing on (connected to) the network, performing a function and/or exchanging, transmitting or storing information and data. Within the context of this pattern, nodes represent processing or communication points within the overlay network.

Nodes are connected to other nodes and have designated characteristics and roles. There are different types of nodes, based on their role, such as boundary nodes, edge nodes, peer nodes, and super peer nodes. Nodes may be a part of a hierarchy, with parent and child nodes within a tree structure.

Platform A device or physical entity within the physical network that hosts hardware and software performing one or more mission roles or functions. They may be air, sea, ground or space vehicles hosting or performing mission functions, and may be represented by one or more nodes within the overlay network.

Role An attribute assigned to an entity, actor or node indicating the function of that entity. A role may be specific to the particular mission (such as command and control, search and rescue, surveillance, sensors, etc.), or may be more general in that it is a common function found in many networks (such as edge role, bridge role, client role, etc.).

Service A software application that performs a designated and advertised function within a service-orientated architecture.

Secondary Definitions Boundary Node A network entity located on the boundary of the overlay network. Super Peer Node A node that acts on behalf of an aggregated set of peer nodes

sharing similar characteristics such as geo-location, type of data traffic or network capacity. Within a discovery domain, a super-peer node is responsible for distributing contents of advertisements and queries on behalf of client roles.

Consumer A service/data receiver within a service-orientated architecture




Capability Pattern

Mediator The linking agent for the establishment of a provider/consumer connection within a service-orientated architecture. May be referred to as a “broker” in other contexts.

Producer A software service registered by a provider with a discovery server that is intelligently made available to consumers via a mediating service.

Discovery Services

A service that provides applications the ability to register and look up advertisements.

Dissemination Services

A service that transfers messages between two or more network entities, typically based on registered information subscriptions.

Bridge Role A network entity that creates a “bridge” between transient, low-bandwidth SOA networks and stable, high-bandwidth SOA networks.

Client Role A member of a discovery domain that depends upon representation by a super-peer.

Edge Role A network entity capable of providing the technical abilities necessary to translate between discovery implementations and exchange data securely across two or more heterogeneous network segments. (See “bridge role” and “legacy role.”)

Network Role An entity that enables network transport within the SOA. Legacy Role A specialized edge role that, rather than translating parameters

between heterogeneous SOA networks, presents a facade that allows a capability from a non-SOA, messaged-based network to be discovered and invoked.




Capability Pattern

2 Recommended Solution The recommended solution prescribed in the following sections implements an architecture as illustrated in the right side of Figure 1-1. This proposed architecture uses discovery and dissemination paradigms to allow a “single data bus architecture” in which services (producers and consumers) can discover end points for information exchange. This discovery method also allows for services to analyze message content to determine what data is available without duplication of information on the “data bus” as well as the ability to form ad hoc partnerships between platforms and/or users.

2.1 Actors The actors in this pattern include those entities (including software services) connected to the network and performing some function or role, such as information collection and dissemination. Since this capability pattern can be applied to a wide variety of missions, the actual actors and their roles will vary from one implementation to another. In addition to these mission-specific network entities and actors, this pattern requires implementation of a discovery service and a dissemination service to provide the required capabilities described in Section 2.5.

Since this pattern requires a service-orientated architecture, there will be actors classified as producers, consumers and mediators. These actors operate within the changing environment, as described in the introduction, and the number of mediators, implementations and locations may change as a result of the reformation of the network to provide continuity. One or more producers may also change due to business reasons or availability. However, the producer’s functional capability does not change, only its number, location and instantiation change in a given scenario. All of the actor functions may be contained in a given platform, taking one or more roles as dictated by the scenario. The thrust of these actors is to maintain the network when formed for an adequate time to transfer needed information. In addition, each actor may have different capabilities. For example, the software version in each platform may differ or the radio in each platform in which the actor executes may have different frequency, channel spacing, modulation or power capabilities.

It is important to understand the relationship between the software services or actors, the platform in which these services execute, and the role these actors perform on a platform or node within the network. The actors include the discoverable services within the network. The node type is determined by what services are loaded on a platform and what role it plays within the larger network. A node may change its role or function at any time based on network connectivity and desired processing required by the users. The dynamic nature of the tactical, bandwidth-constrained (ad hoc) network requires this flexibility be enabled by discovery. This flexibility must be built in by software developers to allow services to dynamically adjust to changing network connectivity and user demands.




Capability Pattern

The MD3 Capability Pattern applies to MANET networks comprised of heterogeneous network entities contained on multiple platforms. These platforms can have one or more resident actors and may perform more than one role within the network. These platforms may contain a variety of network radios and one or more computers, and may dynamically join the network. The role of these platforms may change based on user needs and the platforms dropping in and out of the network. These entities are of varying capabilities with no fixed, predictable network topology structure or guaranteed service availability as typified by a MANET. For the purposes of this document, the boundaries of the network are determined by the physical limitations of the MANET, i.e., the region where ad hoc connectivity is present. Edge nodes typically provide connectivity to established high-bandwidth, enterprise-style networks.

Table 2-1 illustrates the typical roles and services that can be found in common MANET scenarios. The rows identify the network entity and the columns identity potential roles for that entity. An edge role is any interface at the boundary of the SOA network and can be one of the subtypes shown in the table: a bridge role providing connection between high- and low-bandwidth SOA networks; a legacy role connecting the SOA network to a legacy message-based network; or a hardware infrastructure role providing connection between a physical device (such as a camera) and the SOA network. The network role covers the type of network transport, whether it is through terrestrial radios, satellite communications or physical wires. The discovery server role, as described in Section 2.5.1, captures the platform’s role within the shared environment of a discovery domain as either a client or a super-peer node. The dissemination role covers whether or not a particular platform plays the role of distributor (a mediator-type representative for a cluster of nodes that is further described in Section 2.5.5 ) or a non-distributor (simple consumer of the information).

As an example, a command-and-control center consumes data to produce information and other articles to be distributed across deployed units. Therefore, as seen in Table 2-1, a command-and-control center is capable of being a producer and consumer and may also provide mediating services. A command-and-control center will most likely have access to all forms of interfaces as an edge role of the network, including bridges to SOA networks used by partners, legacy connections to enterprise-based systems such as hospital records, and hardware connections to monitors, cameras and/or other physical devices. The network used by a command center, particularly if it is a fixed base, will include a hybrid of radio, satellite and wired connections. Command-and-control centers are typically super-peer nodes but can also play the role of client, particularly when the center is only one piece of a series of hierarchical command-and-control centers. Command-and-control centers are also distributors of data but are not required to perform this function, especially if the command-and-control center is mobile and used for more limited, peer-to-peer communications.




Capability Pattern

Table 2-1 Example Network Entities and Roles

2.2 Interfaces As this is a capability pattern, there are no specific interfaces to recommend or prescribe.

2.3 Preconditions Pre-requisites for a network that uses a Multilevel Distributed Discovery and Dissemination Capability Pattern are as follows:

• Network nodes shall have pair-wise common communication architecture -- format (i.e. IP), frequency, modulation and encryption -- to support secure exchange of information

• There shall be at least one path between consumer and producer available to provide information exchange between consumers and providers (and mediators)

• Each overlay node shall have discovery and dissemination capabilities • There shall exist a metadata definition that allows for proper exchange of

information • Overlay nodes shall be consistent with operation with a MANET network • A service-orientated architecture shall be employed, compliant with the NCOIC

Net-Centric Services Framework (NCSF) available via www.ncoic.org

Bridge Legacy HW I/FTerrestrial

RadioSat Com Wired Client

Super Peer

DistributorNon-

Distributor

HW Sensor(camera) X X X X X

SW Sensor(weather svc) X X X X X

Situational Understanding (SU) X X X X X Y Y X

Situational Awareness (SA) X X X X X X X

Command & Control (SU, SA and Control) X X X X X X X X X Y Y X X

Data Distribution Center X X X X X X X X

This table illustrates likely scenarios. These are not mandated configurations. X: Example Role Y: Role choice is exclusive of other options within that category.

Actor ServicesDissemination

Roles

ExamplePlatforms

Edge Network Discovery Services

Producer Consumer Mediator




Capability Pattern

2.4 Structure The MD3 Capability Pattern applies to MANET networks, which have no fixed, predictable network topology structure or guaranteed service availability.

Services are needed that enable network entities to communicate the right information at the right level of detail at the right time, based on the context of each user, available bandwidth, information assurance constraints, quality of service and current user policies. As described below, a discovery service includes a decentralized proxy and server that provide applications the ability to register and look up advertisements. The dissemination service provides a standard interface that allows applications to transfer messages between two or more network entities. The components of discovery and dissemination depend, at the structural level, on a system of advertisements and queries registered with the discovery server and limited/scoped by use of discovery domains or groups of related services and nodes. There may also be standards for exchanging authentication and authorization data, as well as different architectures on enforcing access control to services.

2.4.1 Network Overlay Structure This pattern prescribes the use of a peer-to-peer (P2P) overlay network, as illustrated in Figure 2-1, using discovery domains (described later) as the method for organizing the overlay network. The overlay shall support a multi-level structure, which is used to locate services across the network as well as to segment those services based on operational applicability, domain purpose and/or frequency of usage. Each domain within the structure may have one or more sub-nodes that are in communication with each other. The sub-nodes may freely modify their discovery participation based on need. At the physical level, the MANET structure is always in flux, resulting in network partition changes and/or degraded connectivity, which would drive the sub-node’s discovery participation. The flexibility of network entities to change their roles within each of these discovery domains allows the overlay structure to heal itself based on current operational conditions.

The physical network connectivity between producer/consumer actors may not necessarily be a “direct connect,” but instead might pass through one or more mediators. The actors do not have any understanding of the physical connections, but do see the logical connections to be direct connects. Thus, only the mediator nodes need to understand5 the physical network and can manipulate both the hardware and software quality of service as well as manage the network responsiveness. As such, the network takes on a peer-peer look.

5 For some services the consumers and producers may need to be made aware of underlying network capacity and latency issues so that they can decide whether to pursue some alternative course of action. The mediator nodes need to be able to provide notification of quality of service issues in these cases.




Capability Pattern

PhysicalNetwork

OverlayNetwork

Fixed NetworksFixed Networks

Overlay Boundary

Physical Platforms E Edge NodeNetwork Node

E

E

MANET

Figure 2-1 Physical and Overlay Networks

By organizing the pattern around discovery domains (as described in Section 2.4.3), in which services can characterize their capabilities, applications have the ability to use the best available services to accomplish the current mission, which best may be defined by a combination of capability, availability and bandwidth utilization. As services are added or removed, for whatever reason, the applications are free to select the most appropriate service to fulfill the current mission.

The constraints and behavior of a MANET network essentially drive developers to have a consistent infrastructure and metadata model that are used to create the applications in the network -- in essence driving to a deployment approach similar to that provided by Google or Apple, where they provide a downloadable toolkit to build application services that insure interoperability within the platform and on the network.

2.4.2 Network Entity Aggregation Network entities (nodes) shall be aggregated by common characteristics to form a logical network topology, built from a lower-level network topology. Within such a virtual network, super-peer nodes act on behalf of an aggregated set of peer nodes sharing similar characteristics, such as geo-location, type of data traffic or network capacity. The overlay should route network traffic between peer nodes on the overlay network and their children. Peer nodes should be promoted to super-peer nodes, when




Capability Pattern

existing super nodes are no longer the appropriate parent or super peer either due to failure or change in characteristics.

2.4.3 Discovery Domains This pattern prescribes the use of both a network-wide discovery domain and multiple, lower-tier discovery domains organized around specific operational and organizational information exchange needs. Discovery domains provide a means to scope and limit the distribution of advertisements and queries within the membership of the specified domain. Discovery domains allow many more services to be registered and queries to be issued between the applications that will directly use them, thereby reducing total bandwidth requirements by eliminating unnecessary message distribution. This also increases network scalability. Using multiple, smaller discovery domains also facilitates faster agreement on information metamodels.

Each and every discovery domain has a unique and independent network infrastructure composed of super-peer nodes and client roles. A discovery role, acting also as a client role within a particular domain, will attempt to establish a connection with another discovery role acting as a super-peer node within the same domain. This connected super-peer node is then responsible for distributing contents of advertisements and queries on behalf of the client role. Messages will be distributed within one and only one domain. Each domain should contain at least one entity acting as a super-peer node to facilitate communication between the other domain participants.

Figure 2-2 shows a set of nine discovery entities and an example membership of five discovery domains plus the network-wide discovery domain. A particular discovery server may participate in zero or more discovery domains; however, participation in the network-wide discovery domain is mandatory. Native support of the network-wide discovery by the underlying network infrastructure is recommended to improve performance. A discovery server may also serve different roles simultaneously within each of the discovery domains in which it participates.




Capability Pattern

PlatformA

PlatformH

PlatformE

PlatformD

PlatformF

PlatformG

PlatformI

PlatformC

PlatformB

SP SP

DiscoveryDomain

1

Network-WideDiscovery

Domain

DiscoveryDomain

5

DiscoveryDomain

3

DiscoveryDomain

4

DiscoveryDomain

2

C C SP

CC C SP C C C CC

C SP C C C CSPC

C

SP

Client Role

Super Peer Node

Figure 2-2 Discovery Domain Overlay Network

2.4.4 Advertisements Actors, producers and consumers provide “advertisements” of the data and/or services that they are looking for or providing. These advertisements include metadata used by the mediator to determine what endpoints should be “paired” between these actors. The metadata description (e.g. Object Management Group Topic) is used to determine the best fit.

Advertisements include metadata that can be used to describe any resource in a P2P network (peer nodes, groups, services, etc.) and are provided by dissemination providers to distinguish the service or data they are providing. Dissemination consumers use discovery mediators to locate advertisements for a specific service/data. Mediators share details of the advertisements with one another across the network to facilitate broad-network searches. Mediator interaction can be achieved through distributing advertisement contents, distributing active searches between mediators, or a hybrid approach depending on the operational need. Mediator applications must be capable of parsing the representation of advertisements.

2.5 Capabilities

2.5.1 Discovery Service Capability There will be a multitude of services and applications that need to communicate in the service-based architecture network. The location, properties and availability of these




Capability Pattern

services might change at any time due to the volatility6 of the network. In order to support an application’s need to locate services and resources in the face of uncertain network conditions, a discovery service is necessary to provide location-transparent resolution of services. Applications sending data over the mobile network, or developers of such applications, should be aware of the limitations of the network. The discovery service must attempt to minimize its use of network and system resources while performing registration and lookups of services.

The discovery service shall provide applications the capability to register, update and look up communication services, as discoverable communication entities or offers, in the network. An industry standard query language, such as SQL, can be used. It must also support remote asynchronous (or synchronous) queries of the service repositories through a federation of discovery servers. This enables efficient discovery of services without the additional cost of replicating all service advertisements throughout the network. In addition, the discovery service cannot have a single point of failure if it is to succeed in providing highly available, efficient and reliable discovery throughout the entire network.

A discovery service consists of two major components: a client and a discovery server. Figure 2-3 shows the discovery system architecture. An application thread of execution can utilize the discovery client interface to perform discovery tasks (e.g., look up advertisements). Underneath the discovery client interface, a single-discovery server proxy shall be used to communicate with the discovery server. The discovery proxy shall be configurable to allow applications on platforms that do not have discovery servers running locally to communicate with a remote server. The discovery server is responsible for handling the communication with the discovery proxy as well as interacting with other discovery servers to coordinate producer advertisement availability and consumer query propagation. Smaller, less capable platforms that are not capable of supporting the demands of the discovery server process, may interact with the discovery server through use of the discovery client/proxy interface.

6 Methodologies for managing MANET volatility need to be considered, but are beyond the scope of this document.




Capability Pattern

Figure 2-3 Discovery System Architecture

2.5.2 Dissemination Service Capability The dissemination component provides a standard interface that allows applications to transfer messages between two or more network entities. The P2P messaging capabilities should support two styles of communication approaches: Message Oriented Middleware (MOM) and Remote Method Invocation (RMI) shown in Figure 2-4.

The MOM style of communication is typically used by applications wishing to interface with other applications in terms of message “packets,” whose contents are well understood in terms of the services or information being requested. The communication services provide different types of connectors to support the different MOM-style communication methods. Applications should choose the appropriate methods for the required data flow. The supported methods are as follows:

1. Point-to-Point - for bidirectional communication between two applications 2. Client/Server - for an application that needs point-to-point communication with

multiple, and possibly an unknown number of, applications 3. Publish/Subscribe - for unidirectional one-to-many communication 4. Peer Groups - for many-to-many communication (from any group member to all

other group members) 5. Remote Method Invocation - communication approach that provides a service-

containing method that can be invoked locally or remotely (as opposed to the “send” approach associated with MOM); RMI involves both synchronous and asynchronous invocation of methods over the network




Capability Pattern

Transport Stack

Pluggable Transport Layer UDP RMCast

SharedMem

Dissemination Transport Layer

Fragmentation

Compression

Encryption

Connector

MOM APP

Data Writer Data Reader

Service I/F

Connector

RMI APP

QoS Manager

Optional (configurable)

Generated

Data Store

Figure 2-4 Messaging Services Context Diagram

The following additional paradigms may also prove useful but are not required:

1. Native Connector – for communication with non-P2P applications 2. DBMS Table Replication – a method for replicating tables between platforms;

replica groups are used to define the set of platforms that will receive copies of a table

3. Operating Effectiveness (OE) Dissemination – a standard application program interface (API)

The various dissemination methods are related in that some of the implementations are built on top of other models in order to minimize duplication of related supporting features (i.e., information assurance, discovery and quality of service). This relationship is shown in Figure 2-5 Relationships of Dissemination Models.




Capability Pattern

Figure 2-5 Relationships of Dissemination Models

2.5.3 Data Model Mediation Capability This pattern supports any data model for peer-to-peer communications but has special considerations for the bridge roles that handle communications between two heterogeneous networks, which typically have different data models. A bridge role must perform data mediation between data models.

There is an additional special consideration as it applies to a legacy role that bridges a SOA network segment to a non-SOA-message-based network segment. Not only must the legacy role perform data mediation, but it must also provide a service facade to integrate the legacy role into the discovery and super-peer node architecture.

2.5.4 Information Assurance Bridge Capability This pattern supports any mechanism for providing information assurance for P2P connections but has special considerations as it applies to bridge roles that handle communications between two heterogeneous networks, which may have different standards for exchanging authentication and authorization data as well as different architectures on enforcing access control to services.

A bridge role represents two distinct network segments and must establish distinct connections using appropriate mechanisms and credentials, as defined by the network segment, then perform mediation between the two network connections. It may be necessary to provide some mapping of roles and attributes between the two networks as well.

Dissemination Implementation

User Applications

Pluggable Transport Layer

Dissemination API DDS Pub/Sub

Client/Server

Point-to-Point

RMI

Peer Groups Pub/Sub

Native Connectors

Pub/Sub Implementation Point-to-Point Implementation Peer Groups Implementation

OE Dissemination

Client/Server Implementation




Capability Pattern

2.5.5 Quality of Service Capability The scenario addressed by this pattern presents a unique challenge of building software that must work efficiently over both a wired LAN environment that is fast and reliable and a wireless radio network that offers no guarantees on connectivity or reliability. The communications infrastructure shall provide for the following capabilities: producer/consumer notification for delivered or dropped messages; ability to complete the transactions when a producer or consumer are not on the network simultaneously; and the ability to set the markings on the generated network traffic to allow proper network prioritization, admission and queuing. Applications sending data over the wireless mobile network, or the developers of such applications, should be aware of the limitations of the network, and the dissemination component shall attempt to minimize its use of network and system resources while disseminating data. The following discussion of distributors is an example of such an approach to quality of service (QoS).

Distributors create a data-aggregation overlay network that can be used to allow more efficient handling and an easier separation of intra- and inter-boundary traffic, where a boundary can be defined as a vehicle, dismounted personnel or other such platform. As an example, all data being sent to another vehicle is first sent to the vehicle’s distributor, which sends it to the receiving vehicle’s distributor, which then sends it to the final destination. This prevents data being sent to the same vehicle multiple times, even when multicast is not available.

Distributors may also be used to reduce network traffic by taking advantage of the overlay network topology introduced with the distributors, and using the distributors in a similar way as multicast routers are used. This would allow one-to-many messages sent over a unicast transport to be sent in a multicast manner, reducing bandwidth usage without using another multicast address. The distributor network overlay topology will likely be coarser grained than the underlying network topology. Hence, the savings will likely not be as large as router-handled multicast if the portions of the routes to multiple receiving vehicle distributors are the same, but the savings could be significant if the number of multicast addresses is limited.




Capability Pattern

Figure 2-6 Example Distributor Layout

2.6 Behavior In the MD3 Pattern, service producers must register advertisements for use by consumers within the service producer’s peer node network, which includes a super-peer node for the service domain. The service consumers should then query for services they need from a domain peer network. The super-peer nodes shall form an overlay network, coordinating offers and queries among the super-peers to optimize service query network traffic.

As network entities change, the super-peer nodes should reform their connections and membership to provide access to domain services within their network entity. This pattern supports a variety of optimizations that show how offers should be exposed and queries should be executed for network efficiency.

At a high level, the pattern behavior can be separated into the following four sequences:

1. Build and Maintain the Discovery Infrastructure The discovery infrastructure is built as each platform joins the network, only requiring the mediator to start a discovery server or, if the platform has limited capacity, finding a discovery server to act as a proxy. The mediator’s discovery server shall query for available platforms for each discovery domain of interest and establish a P2P connection with each respective discovery server in a peer group. That peer group shall then resolve which peer node should act as the




Capability Pattern

super-peer node for the discovery domain. If a new super-peer node is elected, that node shall query for all super-peer nodes and establish P2P connections between super-peer node discovery servers. If a super-peer node is replaced by a new platform joining the network, then that super-peer node shall disconnect from super-peers not required for its discovery domains. This behavior does not require a well-known sequence of platform startup or guaranteed availability, but rather establishes and maintains an infrastructure with what is available at any given time.

2. Build and Maintain the Discovery Offers When a service is started on a platform, the service shall register an offer with the mediator’s discovery server. That discovery server shall then forward an advertisement of the offer to the appropriate super-peer node responsible for the service domain. The mediator’s discovery server shall resend an advertisement of the offer if there is a change in the super-peer node.

3. Locate a Domain Service When an application on a platform wants to find a service, it shall query the mediator’s discovery server using appropriate parameters to limit the search scope to the appropriate discovery domain. The discovery server shall forward the query to the appropriate super-peer node for the discovery domain of the request. The super-peer node shall return advertisements that match the search criteria to the mediator’s discovery server. The platform discovery server shall return those advertisements to the application, which should then select the most ideal service based on the application’s current need.

4. Disseminate Messages Between Provider and Consumer As shown in Figure 2-7, once the actors have advertised their presence and a pairing has been determined, the services begin the exchange of information. This dissemination of information should use data writers and readers that leverage information provided by the mediators to isolate the network topology from the actors.




Capability Pattern

Figure 2-7 Steps to Data Dissemination

A discovery server platform operating as a super-peer node is responsible for propagating messages within the discovery infrastructure overlay network and facilitating routing of discovery queries. These goals can be accomplished either through using multicast with a time-to-live (TTL) to limit the propagation, or by using techniques to traverse the network of super-peers through a series of directed messages. When a discovery service starts up or joins a discovery domain, a decision must be made to determine the type of node and role the discovery service will serve in the domain.

Depending on super-peer availability, resource limitations and other potential factors, a discovery service may elect to transition from one node to another. In doing so, a web of super-peer nodes is created to form an ad hoc overlay network. Super-peer nodes locate one another via well-known addresses or through multicast discovery of other super-peer nodes. When a message is traversed through the super-peer network, the message is sent in a directed fashion between the super-peer nodes. Upon reception of a message at a super-peer node, the node determines the extent to which the message should be propagated. This may be delivered to one or more client roles as well as one or more super-peers, depending on the message delivery scope.

Super-peer nodes are also responsible for tracking the location of advertisements in the network. As requests arrive for a particular advertisement, the super-peer node determines where to forward the query based on the operational condition requirements. Super-peer nodes are free to distribute the knowledge of advertisements and requests for resources in the system as needed, without the added cost of pushing all messages to all nodes in the network.




Capability Pattern

2.7 Post Conditions As shown in Figure 1-1, the resulting post conditions of using this pattern is a network in which actors can exchange information free from pre-planning and pre-knowledge of which platforms or users will participate prior to deployment. A network that self-forms and allows for ad hoc changes reduces integration costs, certification costs and provides faster deployment of operational capabilities. The network becomes an “apps store,” allowing for the discovery of application services and the ability to leverage the network as if it were on a single platform. The resulting environment enables new partnerships between countries or organizations, allowing for true “force multipliers” in response to natural disasters, wars and other multi-national contingencies.




Capability Pattern

.

3 Related Patterns Released NCOIC patterns that have relationships to this pattern include those shown in Table 3-1. Pattern relationships may be “related” (should be considered in conjunction with this pattern) or “supported” (this pattern supports implementation of the other pattern). For example, the Design Phase Systems Integration Pattern mentions interfaces between systems in which this pattern should be employed. The relevancy of each pattern is shown in Table 3-1 Related NCOIC Patterns.

Pattern Relevancy Legacy Systems Capability Pattern

This pattern outlines the possible approaches to creating interfaces to leverage legacy capabilities. Supports the MD3 Pattern.

All Hazards Alert and Warning (AHAW) Capability Pattern

This pattern captures functional interfaces that are required for implementing hazards, alerts and warning capability. The MD3 Pattern may be used to support implementations of the AHAW Pattern.

Disconnected, Intermittent and Limited (DIL) Communications Technical Pattern

The major static interface is between the communications mesh element (CME) and the policy manager (PM). Section 4.1 of this document describes the requirements for interaction across the CME-PM interface. This supports the MD3 Pattern.

Space, Air, Ground, and Maritime (SAGM) Mobile Communication and Networking Operational Pattern

This pattern describes operational scenarios for end-to-end multimedia information communication while all source and destination nodes are mobile in heterogeneous wireless networks; in ad hoc, connected and disconnected modes; in different media; and while roaming. MD3 Pattern may be used to support the SAGM Pattern.

Land Force Tracking Gateway Network Centric Capability Pattern

This pattern provides guidance to industry on implementation of a gateway to achieve interoperability among disparate systems from civil or government organizations. Supports the MD3 Pattern.

Net-Centric Services Interface Capability Pattern

This pattern focuses on the interfaces (or the physical connection points between systems) to which the principles of SOA and net-centricity have been applied. Supports the MD3 Capability Pattern.

Core Network Access Technical Pattern

This pattern describes a method for connecting a number of non-fixed access networks to a fixed-core network. This pattern provides a clear differentiation between non-fixed specialized access networks and the core network that provides information transport between the access networks.

Emergency Services Operational Pattern

This document describes the prescriptive operational pattern for a set of discrete but interrelated




Capability Pattern

communications services based on the Emergency Data Exchange Language (EDXL) suite of standards. Recommends the use of the MD3 Pattern.

Table 3-1 Related NCOIC Patterns

4 References

4.1 Documents 1. “Reference Architecture Foundation for Service Oriented Architecture Version

1.0.” 06 July 2011. OASIS Committee Specification Draft 03 / Public Review <http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.html>

2. “Application Design Patterns: Producer/Consumer.” 13 December 2006. National Instruments Developer Zone. <http://zone.ni.com/devzone/cda/tut/p/id/3023>

4.2 Standards This capability pattern has been drawn from multiple standards. The following organizations (standards bodies) have provided one or more standards used in the definition of this capability.

• The Linux Foundation (previously The Embedded Linux Consortium) https://wiki.linuxfoundation.org/en/ELC/ELCPS

• Institute of Electronic and Electrical Engineers http://www.ieee.org/publications_standards/index.html

• Object Management Group http://www.omg.org/technology/documents/spec_catalog.htm

• The Open Grouphttp://www3.opengroup.org/standards • Open Information Security Foundation

http://www.openinfosecfoundation.org/ • Workflow Management Coalition

http://www.wfmc.org/wfmc-standards-framework.html • Network Centric Operations Industry Consortium

https://www.ncoic.org/home/ • BPM Standards Group

http://www.bpmpartners.com/documents/press032504.pdf • Public Key Infrastructure Forum • Security Assertion Markup Language • Multilateral Interoperability Programme

https://mipsite.lsec.dnd.ca/Pages/Default.aspx • OASIS

http://www.oasis-open.org/




Capability Pattern

5 Acronym List

AHAW All Hazards, Alerts and Warnings (Pattern) API Application Programming Interface APP Mobile Application Software BPM Business Process Management C2 Command and Control CME Communications Mesh Element CONOPS Concept of Operations D-D Discovery/Dissemination DDS Data Distribution Service DIL Disconnected, Intermittent and Limited DoDAF Department of Defense Architecture Framework I/F Interface IA Information Assurance IDL Interactive Data Language IP Internet Protocol HW I/F Hardware Infrastructure LAN Local Area Network MANET Mobile Ad Hoc Network MOM Message Oriented Middleware NC Net-centric NCIF Net-centric Information Framework NCOIC Network Centric Operations Industry Consortium NCSF Net-centric Service Framework NIF® NCOIC Interoperability Framework NSD-RM NIF Solution Description Reference Manual OASIS Organization for the Advancement of Structured Information Standards OMG Object Management Group P2P Peer to Peer PKI Public Key Infrastructure PM Policy Manager QoS Quality of Service RMI Remote Method Invocation SA Situational Awareness SATCOM Satellite Communications SOA Service Oriented Architecture SU Situational Understanding SW Software TCP Transmission Control Protocol TTL Time to Live UAV Unmanned Air Vehicle




Capability Pattern

UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol UML Unified Modeling Language US United States W3C World Wide Web Consortium W3SVC World Wide Web Publishing Service WAN Wide Area Network WSDL Web Services Definition Language WS-I Web Services Interfaces




Capability Pattern

6 Appendices

6.1 Emergency Response Scenario Details The following sections provide additional details for the scenario described in Section 1.1.3.

6.1.1 General Assumptions 1. This is an international disaster similar in magnitude to the 2010 Haiti earthquake

or 2011 earthquake and tsunami in Japan. 2. The disaster zone has reports of numerous fatalities and injuries. 3. The disaster zone has no lifeline services (e.g., power, water, sewage). 4. The communication infrastructure is inoperable and heavily damaged with some

limited cell phone coverage that is jammed due to demand usage and is assumed to not be viable for deployed emergency operations.

5. All necessary power, survival gear and supplies are brought with the deployed team and supplies are sufficient to last for several days.

6. Force protection of the deployed personnel will be provided by either accompanying deployed uniformed personnel, local civil personnel, United Nations personnel or other government personnel.

7. The timeline assumes deployment of a minimum of 24 REACT personnel within 96 hours from notification of disaster to evaluate and reestablish critical communication and cloud computing services in disaster area.

8. Additional personnel with their systems arrive randomly from multiple nations and are required to be joined to the MANET network and exchange data in a trustable manner.

9. Deployable personnel include civilian contractor personnel with proper technical and access credentials and clearances, who may be accompanied by uniformed deployed personnel.

10. Initial communications required are secure, confidential voice and data. Increased levels of security are anticipated.

11. MANET network infrastructure is vertically and horizontally extendable to address changes in scope of the network, including use as a backup system while the in-country infrastructure is repaired and comes online.

12. United Nations or similar government agency indemnifies or certifies equipment for international emergency-response use.

6.1.2 Emergency Response Equipment The following type of equipment is required for deployment of REACT personnel and equipment.

1. Aviation assets for transportation of REACT personnel and equipment, including main transport helicopter and/or vertical takeoff and landing vehicle, are able to carry up to 24 personnel and up to 3-4 tons of cargo.

2. Command vehicle for overall network management and task coordination




Capability Pattern

3. All-terrain vehicles to further assist in deployment of the network infrastructure communication towers

4. Unmanned air vehicles (UAVs) for search-and-rescue operations and deployment of airborne terminals due to inaccessibility of disaster zone or hazard

5. Deployable MANET network components

6.1.3 Proactive Timeline (Emergency Preparedness Timeline) 1. United Nations Central Emergency Response Fund (or other funding sources) is

secured and all contracts or agreements are in place. 2. All necessary equipment is acquired for multiple simultaneous deployments,

where each network component is sufficient to create a MANET network that covers an approximately 250-square-kilometer (~100-square-mile) area.

3. All necessary supplier and support contracts are in place, and the REACT contractor should have in place negotiated contracts or other agreements for supply chain assets.

4. Major vehicles including heavy airlift capacity (helicopter/tilt-rotor aircraft), mission command vehicles, MANET network infrastructure components, and all survival gear and supplies are readied by REACT contractor for deployment from staging areas to any disaster zone worldwide.

5. Commercial aviation services will be used to replenish additional supplies to the disaster zone or nearest operational commercial airport.

6. Preparations, testing, training and similar deployment arrangements should be made for at least 24 personnel.

7. Training exercises (equipment and personnel) are conducted annually within United Nations guidelines and with selected international civil or government authorities as needed and all equipment is operationally tested and certified.

6.1.4 Reactive Rapid Response Timeline (T + 96 hours) 1. REACT personnel and equipment are loaded on suitable commercial or

government airlift platform for transportation to disaster zone within 96 hours or less after the deployment notice.

2. REACT personnel evaluate the situation and plan deployment of MANET network component (en route), using live feeds on the disaster area and onboard management and mapping capability as needed to plan the MANET network deployment.

3. REACT personnel embark to a designated basecamp with in-country civil and/or government emergency-responder personnel.

4. REACT personnel deploy the equipment in the disaster area using helicopter, all-terrain ground vehicles and/or UAVs.

5. REACT personnel establish a MANET network for vital communications cloud computing and begin linking in unanticipated users and local services as authorized by United Nations or local civil or government emergency operations personnel.




Capability Pattern

6.1.5 In-country Infrastructure Recovery Deployed MANET network is maintained or transferred to in-country civil or government authorities upon notice from United Nations or in country government authority.


Multi-level Distributed Discovery and Dissemination …...11/9/2014 The Multi-level Distributed...

Documents

Transcript of Multi-level Distributed Discovery and Dissemination …...11/9/2014 The Multi-level Distributed...