Airborne Network Architecture - Phoenix Aerospace
AIRBORNE NETWORK ARCHITECTURE
System Communications Description
&
Technical Architecture Profile
Version 1.1
7 October 2004
This document contains a description of the USAF Airborne Network Architecture. It is expected that this architecture will continue to be developed in terms of both the level of detail in which it is expressed and in the evolution of its fundamental concepts. Please contact the Chair of the Airborne Network Special Interest Group to determine the most recent version of this document.
Prepared by HQ ESC/NI1 for the
USAF Airborne Network Special Interest Group
Table of Contents
1. Introduction 1
1.1 Definition of Airborne Network 1
1.2 Purpose of Document 1
1.3 Relationship to Other Documents 1
1.4 Contents 2
1.5 Intended Use 3
2. Operational Context 4
2.1 Operational Concept Description for the Airborne Network (OV-1) 4
2.2 Objective Airborne Network Communications Capabilities 4
3. Airborne Network Tenets 7
4. Airborne Network Description (SV-1) 9
4.1 Overview 9
4.2 Network Functions 9
4.2.1 Inter-node Connectivity 9
4.2.2 Information Assurance (IA) 11
4.2.3 Network Management 12
4.2.4 Link Management 13
4.2.5 Network Services 14
4.3 Network Topologies (Nodes and Links) 14
4.3.1 Node Types 15
4.3.2 Link Types 25
4.3.2.1 Backbone 25
4.3.2.2 Subnet 26
4.3.2.3 Network Access 26
4.3.2.4 Legacy 26
4.3.3 Typical Topologies 26
4.3.3.1 Space, Air, Ground Tether 26
4.3.3.2 Flat Ad-Hoc 27
4.3.3.3 Tiered Ad-Hoc 28
4.3.3.4 Persistent Backbone 28
5. Airborne Network System Functions (SV-4) 30
5.1 On-Board Infrastructure 30
5.1.1 Intra Platform Distribution 30
5.1.1.1 Serial Data Buses 30
5.1.1.2 Local Area Networks 30
5.1.2 Platform Information Assurance 30
5.1.3 Platform Network Management 31
5.1.4 Gateways/Proxies 31
5.1.4.1 Legacy Infrastructure Gateways 31
5.1.4.2 Legacy Transmission System Data Link Gateways 32
5.1.4.3 TDL Gateways 32
5.1.4.4 Performance Enhancing Proxies 32
5.2 AN Equipment 33
5.2.1 Inter-node Connectivity 33
5.2.1.1 Routing/Switching 33
5.2.1.2 Quality of Service (QoS)/Class of Service (CoS) 35
5.2.1.2.1 QoS-Aware Application Interfaces 37
5.2.1.2.2 QoS/CoS Mechanisms 37
5.2.1.2.3 QoS-Based Routing/Switching 38
5.2.1.2.4 QoS Manager 38
5.2.2 Information Assurance 39
5.2.2.1 GIG IA Architecture 40
5.2.2.2 Supporting Infrastructures 43
5.2.2.2.1 Security Management Infrastructure (SMI) 43
5.2.2.2.2 DoD Key Management Infrastructure (KMI) 44
5.2.2.2.3 Public Key Infrastructure (PKI) 45
5.2.2.3 AN Information Flows 46
5.2.2.3.1 Least Privilege 47
5.2.2.3.2 User Traffic 48
5.2.2.3.3 Policy Dissemination 48
5.2.2.3.4 Network Management 48
5.2.2.3.5 Network Control 49
5.2.2.4 AN IA Boundary 49
5.2.2.5 Dynamic Policy Based Security Management (PBSM) 50
5.2.2.5.1 PBSM Framework 51
5.2.2.5.2 Policy Protection 53
5.2.2.5.3 Security Management System 53
5.2.2.6 Data Protection 53
5.2.2.6.1 Application Layer Protection 54
5.2.2.6.2 Network Layer Protection 54
5.2.2.6.3 Link Layer Protection 55
5.2.2.7 Key Management 56
5.2.2.8 Authentication System 58
5.2.2.9 ASWR 58
5.2.2.9.1 Network Intrusion Detection System 59
5.2.2.9.2 Virus Detection, Prevention, and Removal 60
5.2.2.9.3 Vulnerability Assessment System (VAS) 60
5.2.2.10 Protocol Security 60
5.2.2.11 Other Security Functions 61
5.2.2.11.1 Firewalls 61
5.2.2.11.2 Guards – Cross Domain Solutions 61
5.2.2.11.3 Covert channels 61
5.2.2.12 Security Modeling and Simulation 61
5.2.3 Network Management 61
5.2.3.1 Cluster-Based Management Architecture 62
5.2.3.1.1 Network Manager 62
5.2.3.1.2 Cluster Managers 63
5.2.3.1.3 Intelligent NM Agents 64
5.2.3.2 Policy Based Management Framework 64
5.2.3.3 Network Management System Components 66
5.2.4 Link Management 69
5.2.4.1 Link Management Architecture 69
5.2.4.2 Link Management System Components 70
5.2.5 Network Services 71
5.2.5.1 Overview 71
5.2.5.2 Name Resolution Service 73
5.2.5.2.1 Naming Service Features 73
5.2.5.2.2 Naming Service Architecture 75
5.2.5.3 Dynamic Network Configuration Management 75
5.2.5.4 Network Time Service 75
5.3 Off-Board Transmission Systems 76
6. GIG Integration and Interoperability 78
6.1 GIG Operational Mission Concepts 78
6.1.1 Provide Common Services 79
6.1.2 Provide Worldwide Access 79
6.1.3 Provide Dynamic Resource Allocation 79
6.1.4 Provide Dynamic Group Formation 80
6.1.5 Provide Computer Network Defense (CND) 80
6.1.6 Provide Management and Control of GIG Network and Resources 80
6.2 GIG Enterprise Services 81
6.2.1 Enterprise Service Management/Network Operations 81
6.2.2 Information Assurance/Security 81
6.3 GIG Transport Convergence 83
6.4 GIG Routing Architecture 83
6.5 GIG Quality of Service Architecture 83
6.6 Interface Definition 85
8. Node and Link Configurations for Candidate Platform Types (SV-5) 94
8.1 Approach 94
8.2 Fighter Platform 94
8.2.1 Operational Profile 94
8.2.2 AN Capabilities, Links, and Topologies 95
8.2.3 AN System Configuration 96
8.2.4 Airborne Fighter Platform AN Issues and Risks 97
8.3 Airborne C4ISR Platform 97
8.3.1 Operational Profile 97
8.3.2 AN Capabilities, Links, and Topologies 98
8.3.3 AN System Configuration 99
8.3.4 C4ISR Platform AN Issues and Risks 100
8.4 Airborne Communications Relay Platform 100
8.4.1 Operational Profile 100
8.4.2 AN Capabilities, Links, and Topologies 101
8.4.3 AN System Configuration 102
8.4.4 Airborne Communications Relay Platform AN Issues and Risks 103
9. Recommended Network Standards 104
9.1 Current Standards (TV-1) 104
9.2 Emerging Standards (TV-2) 113
9.3 Areas for Further Development 120
10. AN Architecture Issues 129
11. List of Acronyms 136
12. References 140
• 1. Introduction
This document represents the work performed by the USAF Airborne Network Special Interest Group to define an Objective Airborne Network Architecture. Additional efforts are planned to further define this architecture. TBDs (to be determined) inserted in the text indicate areas still being worked.
1.1 Definition of Airborne Network
The Airborne Network is defined to be an infrastructure that provides communication transport services through at least one node that is on a platform capable of flight. This can best be visualized in the context of the operating domains served by the Global Information Grid (GIG). The Transformational Communications Satellite System (TSAT) network will provide space connectivity and the GIG-Bandwidth Expansion (GIG-BE) network together with networks such as those provided under the Combat Information Transport System and Theater Deployable Communications will provide surface connectivity. Airborne connectivity within the GIG will be provided by the Airborne Network. The Airborne Network will connect to both the space and surface networks, making it an integral part of the communications fabric of the GIG.
1.2 Purpose of Document
In general, a network architecture defines a set of high-level design principles that guides the technical design of a network. Its role is to ensure that the resulting technical design will be consistent and coherent – the pieces fit together smoothly – and that the design will satisfy the requirements on network function associated with the architecture. The architecture is more general than a particular conformant technical design, and is expected to be relatively long-lived – applicable to more than one generation of technology. Finally, the architecture should guide technology development in a consistent direction, preventing the implementation of inconsistent point solutions throughout the network that could lead to the loss of functionality and interoperability. [Source: Developing a Next-Generation Internet Architecture, July 2000]
The Airborne Network Architecture defines the structure of Airborne Network components, their relationships, and the principles and guidelines governing their design and evolution over time. It consists of the design tenets, technical standards, architectural views (system and technical) and a description of the operational capabilities achieved. The architecture is documented following the guidance of the DoD Architecture Framework. This document defines a “To-Be” or objective set of airborne network capabilities, functions and system components to be used to assist planning activities associated with the acquisition or implementation of a particular network capability. It should not be used on its own as an all-encompassing design for the Airborne Network.
1.3 Relationship to Other Documents
The following documents also provide acquisition or implementation planning details for the Airborne Network, and are related to this document as indicated:
• Airborne Network Architecture Progress Summary Version 1.0 – Provides the scope, purpose, and intended uses of the Airborne Network Architecture, describes the process used to develop the architecture, and summarizes the major results and conclusions.
• Airborne Network Architecture Roadmap (Draft) – Provides a time phased approach for implementing the Airborne Network capabilities and network functions.
• Airborne Network Technical Requirements Document (Draft) – Provides detailed technical requirements for system components needed to implement the Airborne Network.
• ConstellationNet Addendum to C2 Constellation CONOPS – Provides the required operational capabilities of the ConstellationNet of which the Airborne Network is a component.
• USAF ConstellationNet Sub-Enterprise Architecture (formerly known as the AF Infostructure Architecture) – Provides context and overall guidance for domain level architectures for implementing a net-centric infostructure. Includes operational, system, and technical views of the Air Force information infrastructure (to include the Airborne Network) at the Enterprise level.
• Command and Control Enterprise Reference Architecture (C2ERA) – Provides the technical direction for designing, acquiring and integrating the computing and communications capabilities of the Air Force C2 Enterprise.
• Net-Centric Enterprise Solutions for Interoperability (NESI) – Provides a technical architecture and implementation guidance to facilitate the design, development, maintenance, evolution, and usage of information systems that support the Network-Centric Warfare (NCW) environment.
1.4 Contents
The Airborne Network Architecture is documented in terms of the following perspectives:
• Operational Context – Objective communications capabilities that the Airborne Network must provide to the warfighter to support future network-centric operations are described in Section 2.
• Tenets – Network principles applicable to any Airborne Network design that provide high level guidance for decision making are contained in Section 3.
• Systems Architecture Views – Guidelines for where and when to implement different system functions or technologies are contained in Sections 4 through 7. Section 4 describes the objective Airborne Network functions and topologies; Section 5 identifies the systems components needed to provide those functions; Section 6 discusses implications of integrating the Airborne Network into the future Global Information Grid (GIG); Section 7 contains several model diagrams for the network and platforms; and Section 8 presents notional system configurations for several candidate platform types.
• Technical Standards – Technical standards for major Airborne Network components and interfaces, both existing and emerging, are listed in Section 9.
• Issues – Architectural and technical issues identified during the development of the architecture that require further research are presented in Section 10.
1.5 Intended Use
The Airborne Network Architecture is intended to guide the acquisition of network capability for airborne platforms by defining investment opportunities, system requirements, technical standards, implementation guidelines, and GIG interoperability directives.
• Investment Decisions – The Airborne Network Architecture identifies functional areas requiring further investigation and development to define technical solutions and/or standards.
• Requirements Definition – The Airborne Network Architecture provides a common framework to identify required network, platform, and communications component functionality to enable a desired set of network capabilities needed to support future Air Force mission operations.
• Standards Definition – The Airborne Network Architecture provides a list of key technical standards for use in near-term and interim airborne network implementations.
• Implementation Guidance – The Airborne Network Architecture provides a list of tenets and system configuration diagrams that should be used to guide the development of lower level system architectures and system designs.
• GIG Interoperability Direction – The Airborne Network Architecture identifies GIG interoperability directives and architectural guidance relevant to the airborne network
2. Operational Context
2.1 Operational Concept Description for the Airborne Network (OV-1)
Network-centric operations and network-centric warfare (NCW) refers to an information superiority-enabled concept of operations that generates increased combat power and air mobility by networking sensors, decision makers, and shooters to achieve shared awareness, increased speed of command, higher tempo of operations, greater lethality, increased survivability, and a degree of self synchronization. In essence, NCW translates information superiority into combat power by effectively linking knowledgeable entities in the battlespace. [Source: Network Centric Warfare, Alberts, Gartska and Stein, 1999]
The Department of Defense (DoD) Joint Vision (JV) 2020 projects to a future period of United States dominance across the full spectrum of military operations. The military capabilities necessary to realize this vision depend upon achieving Information and Decision Superiority through the implementation of an internet-like, assured Global Information Grid (GIG). Within the AF, achieving Information and Decision Superiority depends upon extending the capabilities of the GIG into the airborne and space environments. When fully realized, this AF vision will enable interoperable network-centric operations between Joint Service, Allied, and Coalition forces. [Source: Airborne Network Prioritization Plan]
To realize the AF vision, the extension of the GIG in the airborne domain – the Airborne Network, must be easy to use, configure, and maintain and must provide:
• Ubiquitous and assured network access to all Air Force platforms
• GIG core services whose integrity is assured
• Quality appropriate to the commander’s intent and rules of engagement (ROE)
• Rapid response to mission growth, emerging events and changing mission priorities
• End-to-end interoperation with joint services, coalition, and non-DoD partners and legacy systems in all physical network domains (sub-surface, surface, airborne and space)
[Source: Operating Concept for C2 Constellation ControlNet Network Centric Infostructure]
2.2 Objective Airborne Network Communications Capabilities
The Objective Airborne Network that can provide the capabilities listed in section 2.1 will be a communications utility that provides an adaptable set of communications capabilities that can be matched to the particular mission, platforms, and communications transport needs. Communications capabilities can be expressed in terms of the connectivity that can be established, the services that can be supported over the network connections, and the operations that are required for the user to establish, maintain, and access the network connections. Table 2-1 identifies an objective set of communications capabilities for the Airborne Network. All of these capabilities would not necessarily be needed for every instantiation of the Airborne Network, but will be necessary to support all missions, operations, and platforms.
Table 2-1. Summary of Airborne Network Objective Capabilities
|Network Capability & Attributes |Airborne Network Objective Capabilities |
|Connectivity | |
|Coverage |Beyond Line of Sight (BLOS) extending Globally (enabling access |
|Geographic span of links directly interfacing to a subject |to anywhere from anywhere) |
|node | |
|Diversity of links |Number of links (system and media) matched to the mission matched|
|Total number and types of links that can be used to |to the environment (to enable guaranteed access) |
|“connect” to the subject node |Type of links extend across the spectrum of radio frequencies |
| |including infrared and optical |
|Throughput |Throughput matched to the mission and automatically adaptable to |
|Total average throughput of all links directly interfacing |accommodate unplanned or transient conditions |
|to the subject node |Dynamically reconfigurable to optimize performance, cost, and |
| |mission effectiveness |
|Type of connection |Flexible connections able to forward Globally |
|Nature of connections that can be established between the | |
|subject nodes and directly connected nodes | |
|Network interface |Interface to AN subnet and backbone links, as well as, legacy |
|Networks that can be directly interfaced from the subject |(i.e., TDL or CDL), coalition and GIG component networks |
|node (e.g., DISN (NIPRNET, SIPRNET, JWICS), Transformational|operating any version network protocol (i.e., IPv6 or IPv4), as |
|Communications, TDL Networks, CDL Networks) |needed |
|Services | |
|Real-time data |Multiple simultaneous multilevel precedence and preemption (MLPP)|
|Any data flows that must be sent in real time (i.e., low |real-time data links or nets, as needed |
|latency) with assured delivery (e.g., AMTI or GMTI tracks, | |
|munition terminal stage updates, RPV control, TCT&ISR | |
|tipoffs, NBC alert) | |
|Continuous interactive voice |Multiple simultaneous MLPP voice links or nets, as needed |
|(e.g., Voice over IP telephone and radio nets) | |
|Continuous interactive video |Multiple simultaneous MLPP video links, as needed |
|(e.g., Video over IP, Video Teleconferencing) | |
|Streaming multimedia & multicast |Multiple simultaneous MLPP multimedia links, as needed |
|(e.g., Video imagery) | |
|Block transfer & transactional data |Multiple simultaneous MLPP block & transactional links, as needed|
|Short blocks of interactive data (e.g., Telnet, HTTP, | |
|client/server, chat) | |
|Batch transfer data |Multiple simultaneous MLPP batch data links, as needed |
|Long blocks of bulk data (e.g., Email, FTP) | |
|Operations | |
|Managing |Simplified network planning to include the allocation and |
| |configuration of network resources, including legacy networks, |
|All aspects related to managing the links and the network |when needed |
|including: |Automated analyses of network performance to diagnose faults, |
|Planning -- frequency allocation, transmission, routing, |determine suboptimal conditions, and identify needed |
|network services and traffic. |configuration changes |
|Monitoring -- performance and use, fault, and security |Monitoring and controlling of AN link and network resources and |
|aspects of a link, network, or network component. |interfaces with legacy networks |
|Analyzing -- performance optimization and diagnostics. |Maintenance of network situational awareness (SA) and |
|Controlling -- add, remove, initialize, and configure links,|distribution of Network SA to peer networks |
|networks, or network components |Match use of network resources to commander’s operational |
| |objectives |
|Forming and Adapting |Automated provisioning, initialization and restoration of all AN |
| |link resources |
|To include: | |
|Provisioning -- obtaining the needed link and network | |
|resources. | |
|Initialization and Restoration -- establishing or restoring | |
|a link or network service. | |
|Accessing |Link and subnet protection matched to the threat, with automated |
|All aspects related to obtaining or denying access to a link|detection and reaction |
|or network, to include: |User data and AN management and control data protection matched |
|Protection – communications security as well as |to the threat |
|authentication, authorization, accounting | |
|Detection | |
|Reaction | |
3. Airborne Network Tenets
The following statements are proposed as tenets of the Airborne Network (AN) Architecture. These reflect the underlying principles of any AN design that claims to be conformant with the AN architecture.
1. Standards Based: AN system components comply with applicable DoD and AF standards lists.
• Leverage commercial investment in COTS-based networks and their evolution wherever feasible
• Relax standards only for unique must-have DoD features
• Evolve standards to accommodate DoD features
• Migrate towards use of open standards
2. Layered: AN system components are functionally layered.
• Follows successful COTS Internet model
• Minimizes description of inter-layer interfaces
• Allows technology evolution of layers for maximum cost benefit
3. Modular: AN is inherently modular in nature, capable of being extended and expanded to meet the changing communications service requirements of the platforms needed to support any particular mission.
• Components can be continuously added and removed as needed during the time frame of the mission (hours, days), such that the network can be adjusted to fit the mission, during the mission
• User capabilities that need to be supported determine the technical capabilities of the network components selected
• New network components that provide new operational capabilities can be integrated as needed.
4. Internetworked: AN is capable of internetworking using all available commercial and military transmission media (i.e., line-of-sight (LOS) radio communications paths, satellite communications (SATCOM) paths, and laser communications (Lasercom) paths).
5. Interoperable: AN is capable of interoperating with other peer networks (e.g., space, terrestrial, and warfighter networks) and legacy networks (as needed for coalition interoperability and transition operations).
6. Implemented as a Utility: AN integrates separate transmission mechanisms with a single common, standards-based network layer (e.g., IPv4, IPv6) for delivery of common user (i.e., mission-independent) network services.
7. Adaptable: AN is capable of adapting to accommodate changes in user mission, operating environment, and threat environment.
8. Efficient: AN efficiently utilizes available communication resources.
9. Autonomous: AN can operate autonomously or as part of a larger inter-network.
• Platform network can operate without connectivity to external nodes
• AN can operate without connectivity to ground nodes
10. Secure: AN supports user and system security.
• Multiple independent levels of security
• User, operations, management, and configuration data integrity and confidentiality
• Identification and authentication.
11. Managed: AN is capable of integrating into broader AF and joint network management infrastructures.
12. Policy Based: AN is capable of integrating into policy-based management and security infrastructures.
4. Airborne Network Description (SV-1)
4.1 Overview
The Target Airborne Network must be capable of supporting the diverse AF missions, platforms, and communications transport needs of the future. The network will vary from a single aircraft connected to a ground station to support voice or low speed data, to a constellation of hundreds of aircraft transporting high speed imagery and real-time collaborative voice and video. The target network must be capable of forming a topology that is matched to the particular mission, platforms, and communications transport needs, and doing so in a way that minimizes the amount of pre-planning and operator involvement.
The Airborne Network will be described in terms of the network functions it must perform and the network topologies (i.e., physical or logical configuration of functional nodes and links) needed to enable the network. The network functional nodes will be defined in terms of the system components or modules needed to achieve the desired functionality.
4.2 Network Functions
The Airborne Network functions will be described from five perspectives, as follows:
• Inter-node connectivity – How AN nodes (i.e., platforms) interconnect to each other.
• Information Assurance – What security functions are needed and where do they go.
• Link Management – How the network controls and makes use of AN communications links.
• Network Management – How the network controls its configuration and maintains its integrity.
• Network Services – What network services are needed and how are they used.
4.2.1 Inter-node Connectivity
AN nodes are capable of establishing connections with one or more other AN nodes, whether airborne, in space, or on the surface, as needed. The transmission paths used to establish the physical connections, may be asymmetric with respect to bandwidth, and may be bidirectional or unidirectional (including receive only). Also, the forward and reverse network connections relative to any node could take different physical paths through the network. The AN connections may be point-to-point, broadcast, or multipoint/multcast.
AN nodes are capable of establishing connections to relay (receive and transmit with the same data formats and on the same media/frequency), translate (receive and transmit with the same data formats but on different media or frequencies), or gateway (receive and transmit with different data formats and on different media/frequencies) information, as needed.
AN nodes are capable of establishing connectivity to other AN nodes based upon a prearranged network design that prescribes inter-node connectivity (i.e., topology) of the network. Also, AN nodes are capable of establishing link connectivity to other AN nodes autonomously, without prearrangements that identify the specific AN nodes, and dynamically as opportunities and needs arise.
Key inter-node connectivity functions include the following:
• Backbone connectivity – Some AN nodes are capable of establishing stable high bandwidth network connections for interconnecting other networks and AN subnets, as needed to satisfy the information transport requirements of the host platform and network. The backbone connection will consist of persistent or quasi-persistent links between two or more AN nodes that are high-capacity in comparison to the subnet links connected to the nodes, permit use of the common network and transport protocols, and provide access to other subnets and/or global network. Backbones are capable of carrying both local and transit traffic. Backbone system components consist primarily of routers/switches and trunks.
• Subnet connectivity – AN nodes are capable of establishing and internetworking with prearranged, static, and ad-hoc subnets with specific sets of nodes, as needed, for instance to support a particular mission, transmission media or location. AN nodes are capable of leaving a subnet and rejoining it or another subnet at any time with minimal prearrangements.
• Network access connectivity – AN nodes are capable of establishing legacy and/or IP network connections using any available media; some AN nodes are capable of providing access to any space or terrestrial IP network as opportunities and needs arise.
• Routing/switching – AN nodes are capable of routing or switching IP packets to/from any local LAN, subnet, backbone, or space or terrestrial IP network (i.e., end system, intra-area, inter-area, and inter-domain ( or autonomous system (AS)) routing) as opportunities and needs arise. AN nodes are capable of routing and switching both platform and transit traffic as needed. Routing decisions will be made on an expanded set of metrics to optimize performance for the AN, such as on hops, bandwidth, delay, reliability, load, media preference, BER or packet loss rate, stability, availability, geographic position, speed and heading. AN nodes are capable of handing off routing capabilities to another AN node (such as when a platform goes off station and is replaced by another platform).
• Quality of Service (QoS)/Class of Service (CoS) – The AN is capable of establishing and changing connections and forwarding IP-packets on routes and in a sequence that satisfies the indicated delivery performance requirements associated with the information flow. The AN will implement standards-based QoS/CoS mechanisms that are compatible with those implemented in interconnected GIG networks enabling timely information exchanges across diverse networks, systems and communities of interest (COIs). The QoS/CoS mechanisms must support all communications services (e.g., voice, data, video), provide preferential treatment based on priority (with preemption), enable policy-based assignment of service classes and priorities, rapidly respond to changes in assignments, and work end-to-end on all host and network devices, as needed.
4.2.2 Information Assurance (IA)
AN IA services include identification, authentication, integrity, confidentiality, availability, non-repudiation, security policy management, and key management. AN IA components will enable or extend access to GIG based security or may organically provide the security services. IA services will be enabled regardless if the AN is connected to other networks that comprise the overall GIG and during periods of connectivity interruption. IA services will be designed to function under constraints such as low-bandwidth, high-latency connections, unidirectional links, or with nodes operating in LPI/LPD modes to include receive-only.
Key Information Assurance functions include the following:
• Policy Based Security Management (PBSM) – PBSM provisions and supports the specification and enforcement of access control policies, logging, monitoring, and auditing. Policy based security management enables:
o Specification of authorization policies for access control
o Specification of obligation policies for logging, monitoring, and auditing
o Analyses of policies
• Data Protection – AN security services will protect user data and AN administrative data, provide cover to transmitted data, and provide the mechanisms to support Multiple Independent Levels of Security and Multi-Level Security.
o User Data – The AN will employ modern, high-assurance NSA Type 1 encryption and algorithms to secure user packet and circuit data. The AN will provide data security over operational environments ranging from US military only to those that will incorporate operations with U.S. military and national assets and U.S. allies and coalition partners.
o AN Administrative Data – (configuration, management, operations, etc.) – The AN will employ public key technologies and protocols, such as SSL, TLS, IPSec to ensure the integrity and confidentiality of AN administrative data. Administrative data includes that used to monitor the health and status of AN components and to configure and operate those components, as well as, that needed for actual network operations, such as routing updates.
o AN Transmitted Data – Transmission Security algorithms and keys, or TRANSEC, will provide transmitted signals covertness or cover to avoid detection, identification and exploitation (such as traffic analyses.)
o Multiple Independent Levels of Security (MILS) Support – The AN will provide for simultaneous operations in multiple independent security domains each secured by their own encryption device. Once secured the resultant data will be transported by a common black transport network.
o Multi-level Security (MLS) Support – The AN will provide for simultaneous operations in multiple security domains on one red network. The red network data will be secured using encryption devices and then transported through a common black transport network.
• Key Management – The AN will use DoD Key Management Infrastructure (KMI) and Electronic Key Management System (EKMS) processes as its core key management capability. The AN may provide user interfaces and/or a pass-through capability that enable platform LAN and user access to the services provided by these systems.
• Authentication, Identification, Integrity, and Access Control. – The AN will provide services to enable user and device authentication, identification, and access control, with or without interface to GIG security services.
• Attack Sensing, Warning, and Response (ASWR) – The AN will provide for host and network based Intrustion Detection Systems, Intrustion Prevention Systems, and Virus Detection, Prevention, and Removal applications.
o Intrusion Detection System (IDS) – The AN IDS will defend system components against threat actions carried by network data traffic by detecting and responding to inappropriate, incorrect or anomalous network activity. The two basic categories of IDS are host-based and network-based. The AN will use a combination of host based and network based IDS processes.
o Intrustion Prevention System (IPS) – The IPS detects and prevents known attacks.
o Virus Detection, Prevention, and Removal – The AN will check for the presence of malicious executable code (e.g., viruses, worms, Trojan horses, etc.) and remove or “repair” the suspect files or alert the operator.
• Protocol Security – The routing, transport, management, and other protocols used to enable the AN must be secured. Dependent on the sensitivity of the protocol’s data, that security may require identification and authentication between endpoints, applying a digital signature to the transmitted data to provide origin and integrity validation, or encryption to provide confidentiality.
4.2.3 Network Management
AN Network Management enables operators to plan network resources and equipment configurations, analyze and predict network performance, monitor and display current network status, isolate and resolve faults, and configure network components.
Key Network Management functions include the following:
• Fault, Configuration, Accounting, Performance, Security (FCAPS) Management
o Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults
o Provide configuration of AN system parameters, detect configuration changes
o Perform accounting of resource utilization to verify that resources are being utilized in accordance with commanders’ operational objectives
o Collect network performance statistics, status, and event notification data, analyze and resolve performance faults and reconfigure network resources as warranted
o Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration.
• Network Situation Awareness
o Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data (including legacy network status) in near real-time to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps center.
o Display system and network resources, showing their operational status and linkages to other resources.
o Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN, its peer networks, and other GIG component networks.
• Network Resource Planning
o Develop and maintain a network resource plan (to include a frequency management plan) for the allocation and configuration of network elements through range of operations
o Interoperate with legacy/coalition network planning tools to ensure an integrated plan
o Formulate policies in accordance with network resource plan
o Store policies in policy repository
• Policy Based Network Management (PBNM)
o Construct, store, and distribute network policies, including for IA and QoS
o Dynamically update network policies
o Perform policy accounting, including SLA management and negotiation
o Provide network access control
• Network Modeling, Analysis, and Simulation
o Provide tools for examining network functional and performance characteristics; use results to refine resource planning and policy formulation
o Provide integrated full network simulation to include the AN, legacy, and coalition links
4.2.4 Link Management
AN Link Management enables real-time autonomous management of the resources and services provided by the RF and optical links that interconnect the AN nodes. This includes finding/locating nodes/links, provisioning link bandwidth, admission control, and managing radio and network configurations.
• Advertising and Discovery – Each AN node will be capable of advertising its identity and location to enable it to be discovered by other AN nodes. The AN Link Management will identify, authenticate, locate and determine the network capabilities of all advertising AN nodes.
• Establishing and Restoring – The AN will form links among advertising AN nodes to satisfy mission operational requirements and prescribed network configurations in accordance with current policies. The AN Link Management will be capable of setting and adjusting AN network component and link parameters to modify the performance of any link. As an example the AN will determine the protocols and data rate to be used over each link, and will be capable of adjusting data rate for a given link.
• Monitoring and Evaluation – The AN Link Management will monitor and evaluate the current operational state of all advertising AN nodes network components and links. The AN Link Management will determine the network performance being achieved by each active AN node and link. In addition, the AN Link Management will determine the network performance being achieved by the overall network to determine whether or not the current topology needs to be altered to satisfy current mission operational requirements.
• Topology Management – The AN Link Management will determine how the AN nodes will be interconnected in order to establish an AN topology that satisfies current mission operational requirements. This includes determining each AN node network component and link parameters, performing admission control for each node requesting connection to the AN, provisioning of link resources, and managing the handoff of links to ensure seamless connectivity.
4.2.5 Network Services
• Name Resolution System – The AN contains a Name Resolution System to resolve hostnames, domains and IP addresses for the AN. The Name Resolution System will include master and replica servers geographically separate with automated failover capability. The AN Name Resolution System will be fully integrated into the GIG Organization, Service and Root DNS architecture.
• Dynamic Network Configuration Management – The AN includes the capabilities to dynamically assign and distribute IP addresses, manage network servers, IP networks and subnets. The AN network configuration management system also provides a view of the IP network, subnet, domain, name resolution server, network time server, etc.
• Network Time Service – The AN includes Network Time Servers (NTS) synchronized with Coordinated Universal Time (UTC) to provide synchronized time distribution within an AN node. The AN NTS will be fully integrated into the GIG UTC, Intermediate, and Client Node Network Time Service architecture. The AN also provides network time services that are fully functional in a GPS denied environment, or when the network is disconnected from the GIG infrastructure.
4.3 Network Topologies (Nodes and Links)
The Airborne Network must be capable of supporting diverse AF airborne platforms. These platforms will vary in their communications capability needs, flight patterns, and size, weight and power (SWAP) constraints. The network must be capable of interconnecting all platforms, supporting all needed services, and providing access to all needed GIG services. Some of the platforms will be high performance aircraft capable of operating at high speeds, needing to rapidly join and exit networks while having SWAP for very limited communications resources (which may be legacy systems). The network must also be capable of guaranteeing certain levels of performance to support bandwidth, latency or loss sensitive applications. Figure 4-1 depicts a Notional Airborne Network Topology showing the different types of network nodes and links that address these needs. To optimize network performance, operations, fault-resilience and ensure the efficient use of resources, the use of relatively stable connections should be maximized especially in the Airborne Backbone (when such a configuration is needed), while the highly mobile platforms and dynamic network connections are isolated to the Tactical Subnets. The Airborne Network should be capable of forming whatever topology is best matched to the mission, platforms, and communications transport needs as discussed in section 4.3.3.
[pic]
Figure 4-1. Notional Airborne Network Topology
4.3.1 Node Types
The node types depicted in Figure 4-1 indicate the minimum network functionality that must be performed at each node to realize the target AN capabilities. A brief description of each node type follows:
• Legacy – Airborne platforms that are equipped with legacy communications systems capable of supporting voice, tactical data link (TDL), and possibly some point-to-point IP network connections for very limited services (e.g., email only).
• Relay/Gateway – Airborne platforms that are equipped with legacy communications systems as described for a legacy node, but also include equipment that enable them to access multiple TDLs and to relay data Beyond Line of Sight (BLOS), or transfer data formats from one link to another.
• Network Access – Airborne platforms equipped with IP network-capable communications systems, which provides an IP network connection to an AN or GIG network node. These nodes are tethered to the network, and do not provide any AN service to other nodes on the network.
• Network Capable – Airborne platforms equipped with IP network-capable communications systems, which can join an IP data network (Tactical Subnet) and provide limited AN service (e.g., transit routing) to other nodes on that local network.
• Internetwork – Airborne platforms equipped with IP network-capable communications systems, which can access and interconnect multiple IP data networks. These nodes are equipped with gateway and network services functionality that enable them to provide GIG services to other airborne nodes when interconnected to the GIG through a Network Service Provider node.
• Network Service Provider – Airborne platforms, fixed or deployed ground facilities, or space-based packages equipped with IP network capable communications systems, which can access multiple IP data networks. These nodes are equipped with gateway and network services functionality that enable them to interconnect with a GIG network (e.g., DISN, JTF Service Component Network, etc.) service delivery node (SDN) and to provide GIG services to other airborne nodes.
Table 4-1 and 4-2 summarizes the network capabilities and functionalities for each node type, respectively.
Table 4-1. Summary of Node Types and Typical Network Capabilities
|Node Type |Network Capability |
| |Connectivity |Service |Operation |
|Legacy |Coverage: Mostly LOS, some BLOS |Typically a subset of communications|Managing: Manual planning, |
| |Diversity: Single or few legacy |transport services, including: |analyzing, monitoring, and |
| |links and link types |Real-time data |controlling of node resources |
| |Throughput: Typically low speed |Voice |locally. Limited automated |
| |connections |Interactive data |management and monitoring for some |
| |Type of connection: Pt-Pt, | |legacy links. |
| |Pt-MultPt, automatic relay | |Forming and Adapting: Manual |
| |Network interfaces: Legacy links | |provisioning, initialization and |
| |and tactical subnets | |restoration of node link resources. |
| | | |Limited dynamic resource sharing. |
| | | |Accessing: Link and tactical subnet|
| | | |protection, with limited manual |
| | | |detection and reaction. Limited |
| | | |dynamic joining and leaving of |
| | | |subnets. |
|Relay/ Gateway |Coverage: Typically LOS and BLOS |Typically a subset of communications|Managing: Manual planning, |
| |Diversity: Few to several legacy |transport services, including: |analyzing, monitoring, and |
| |links and link types |Real-time data |controlling of node resources |
| |Throughput: Typically low speed |Voice |locally |
| |connections |Interactive data |Forming and Adapting: Manual |
| |Type of connection: Pt-Pt, | |provisioning, initialization and |
| |Pt-MultPt, TDL Forwarding | |restoration of node link resources |
| |Network interfaces: Legacy links | |Accessing: Link and tactical subnet|
| |and tactical subnets | |protection, with limited manual |
| | | |detection and reaction |
|Network Access |Coverage: LOS & BLOS |All or most communications transport|Managing: Monitoring and |
| |Diversity: Single IP |services, including: |controlling of node resources |
| |network-capable link |Real-time data |locally and from a remote network |
| |Throughput: Low to high speed |Voice |node, distribute network SA data, |
| |connection |Video |match use of resources to |
| |Type of connection: Pt-to-Pt |Multimedia & multicast |operational objectives |
| |Network interfaces: Tactical |Interactive data |Forming and Adapting: Automated |
| |subnets, AN backbone, GIG networks |Bulk (time insensitive) data |provisioning, initialization and |
| | | |restoration of AN link and network |
| | | |resources |
| | | |Accessing: GIG protection, with |
| | | |automated detection and reaction |
|Network Capable |Coverage: Typically LOS |Typically a subset of communications|Managing: Monitoring and |
| |Diversity: Single IP |transport services, including: |controlling of node resources |
| |network-capable link |Real-time data |locally and from a remote network |
| |Throughput: Low to high speed |Voice |node, distribute network SA data, |
| |connection |Interactive data |match use of resources to |
| |Type of connection: Pt-Pt, | |operational objectives |
| |Pt-MultPt, Forwarding | |Forming and Adapting: Automated |
| |Network interfaces: Tactical | |provisioning, initialization and |
| |subnets | |restoration of AN link and network |
| | | |resources |
| | | |Accessing: Tactical subnet |
| | | |protection, with automated detection|
| | | |and reaction |
|Internetwork |Coverage: LOS & BLOS |All or most communications transport|Managing: Automated analyses of |
| |Diversity: Multiple links and link |services, including: |network performance, monitoring and |
| |types |Real-time data |controlling of node resources |
| |Throughput: Low to high speed |Voice |locally and from a remote network |
| |connections, high speed connections |Video |node and of connected AN resources, |
| |to AN backbone |Multimedia & multicast |maintain and distribute network SA, |
| |Type of connection: Pt-Pt, |Interactive data |match use of resources to |
| |Pt-MultPt, Forwarding |Bulk (time insensitive) data |operational objectives |
| |Network interfaces: Tactical | |Forming and Adapting: Automated |
| |subnets, AN backbone | |provisioning, initialization and |
| | | |restoration of AN link and network |
| | | |resources |
| | | |Accessing: Tactical subnet and AN |
| | | |backbone protection, with automated |
| | | |detection and reaction |
|Network Service |Coverage: LOS & BLOS |All communications transport |Managing: Simplified network |
|Provider |Diversity: Many links and link |services, including MLPP: |planning, automated analyses of |
| |types |Real-time data |network performance, monitoring and |
| |Throughput: Low to high speed |Voice |controlling of node resources and of|
| |connections, high speed connections |Video |connected AN resources, maintain and|
| |to AN backbone and GIG |Multimedia & multicast |distribute network SA, match use of |
| |Type of connection: Pt-Pt, |Interactive data |resources to operational objectives |
| |Pt-MultPt, Forwarding |Bulk (time insensitive) data |Forming and Adapting: Automated |
| |Network interfaces: Tactical | |provisioning, initialization and |
| |subnets, AN backbone, and GIG | |restoration of AN link and network |
| |networks | |resources |
| | | |Accessing: AN and GIG protection, |
| | | |with automated detection and |
| | | |reaction |
Table 4-2. Summary of Node Types and Network Functionality
|Node Type |Network Functions |
|Legacy |Connectivity |
| |Subnet Access (through gateway) |
| | |
| |Information Assurance |
| |User data and orderwire communications bulk encrypted |
| |Limited TRANSEC capabilities |
| |Manual key management; some OTAR |
| | |
| |Link Management |
| |None |
| | |
| |Network Management |
| |None, other than management approach applied by the legacy system; Relay/Gateway provides proxy function for |
| |management of legacy systems by the AN management framework |
| | |
| |Network Services |
| |None |
|Relay/ Gateway|Connectivity |
| |Legacy Link Access |
| |Subnet Access (through gateway) |
| | |
| |Information Assurance |
| |User data and orderwire communications bulk encrypted |
| |Limited TRANSEC capabilities |
| |Manual key management; some OTAR |
| | |
| |Link Management |
| |None |
| | |
| |Network Management |
| |Conduct proxy function between AN management and legacy management |
| | |
| |Network Services |
| |None |
|Network Access|Connectivity |
| |GIG Access |
| |QoS |
| | |
| |Information Assurance |
| |Policy Based Security Management |
| |User data protection through use of Inline Network Encryptor (e.g., HAIPE) |
| |Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data |
| |TRANSEC |
| |I&A, data integrity validation, etc. |
| |Automated Key Management – management of node’s keys; access to replacement keys |
| |Attack Sensing, Warning, and Response |
| |Virus Protection |
| |Protocol Security |
| | |
| |Link Management |
| |Advertising and Discovery |
| |Advertises node’s identity and location |
| |Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available |
| |network capabilities |
| |Establishing and Restoring |
| |Requests network service needed to satisfy mission operational requirements from designated AN link manager node |
| |Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by|
| |the designated AN link manager node |
| |Monitoring and Evaluation |
| |Monitors and evaluates node’s network and link performance |
| |Reports status to designated AN link manager node |
| | |
| |Network Management |
| |Fault, Configuration, Accounting, Performance, Security Management |
| |Collect network performance statistics, status, and event notification data from local network elements, analyze and|
| |resolve faults and configure local network resources, autonomously if needed |
| |Report network performance statistics, status, and event notification data to a designated AN manager node and |
| |receive and respond to configuration requests from the AN manager node |
| |Network Situation Awareness |
| |Report network events to a designated AN manager node |
| |Policy Based Network Management |
| |Request, receive, and respond to policy updates |
| |Provide network access control |
| | |
| |Network Services |
| |Name Resolution System |
| |Dynamic Network Configuration Management |
| |Network Time |
|Network |Connectivity |
|Capable |Subnet |
| |Subnet Access |
| |Routing/ Switching (Intra-Area Router) |
| |QoS |
| | |
| |Information Assurance |
| |Policy Based Security Management |
| |User data protection through use of Inline Network Encryptor (e.g., HAIPE) |
| |Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data |
| |TRANSEC |
| |I&A, data integrity validation, etc. |
| |Automated Key Management – management of node’s keys; access to replacement keys |
| |Attack Sensing, Warning, and Response |
| |Virus Protection |
| |Protocol Security |
| | |
| |Link Management |
| |Advertising and Discovery |
| |Advertises node’s identity and location |
| |Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available |
| |network capabilities |
| |Establishing and Restoring |
| |Requests network service needed to satisfy mission operational requirements from designated AN link manager node |
| |Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by|
| |the designated AN link manager node |
| |Monitoring and Evaluation |
| |Monitors and evaluates node’s network and link performance |
| |Collects/processes/analyzes status reports from assigned subnet nodes |
| |Reports status to designated AN link manager node |
| |Topology Management |
| |Determines needed subnet connectivity for assigned nodes to establish a topology that satisfies current mission |
| |operational requirements |
| |Performs admission control for each node requesting connection |
| |Provisions subnet resources, determines network and link parameters for assigned nodes, and directs adjustments to |
| |network component and link parameters for assigned nodes that request network service |
| |Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to |
| |accommodate changes in service requests, participating nodes or equipment status (based on status reports) |
| |Manages the handoff of links within its subnet to ensure seamless connectivity |
| |Reconfigures subnet topology as directed by the designated AN link manager node |
| | |
| |Network Management |
| |Fault, Configuration, Accounting, Performance, Security (FCAPS) Management |
| |Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults |
| |Provide configuration of AN system parameters, detect configuration changes |
| |Perform accounting of resource utilization to verify that resources are being utilized in accordance with |
| |commanders’ operational objectives |
| |Collect network performance statistics, status, and event notification data, analyze and resolve performance faults |
| |and reconfigure network resources as warranted |
| |Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. |
| |Network Situation Awareness |
| |Collect (or receive), analyze, and fuse local AN composition, status, performance, and information assurance data in|
| |near real-time |
| |Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN |
| |Policy Based Network Management |
| |Provision and dynamically update local network policies, including for IA and QoS |
| |Perform policy accounting, including SLA management and negotiation |
| |Provide network access control |
| | |
| |Network Services |
| |Name Resolution System |
| |Dynamic Network Configuration Management |
| |Network Time |
|Internet-work |Connectivity |
| |Backbone |
| |Subnet |
| |Subnet and Backbone Access |
| |Routing/ Switching (Intra-Area Router, Area Border Router) |
| |QoS |
| | |
| |Information Assurance |
| |Policy Based Security Management |
| |User data protection through use of Inline Network Encryptor (e.g., HAIPE) |
| |Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data |
| |TRANSEC |
| |I&A, data integrity validation, etc. |
| |Automated Key Management – management of node’s keys; access to replacement keys |
| |Attack Sensing, Warning, and Response |
| |Virus Protection |
| |Protocol Security |
| | |
| |Link Management |
| |Advertising and Discovery |
| |Advertises node’s identity and location |
| |Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available |
| |network capabilities |
| |Establishing and Restoring |
| |Requests network service needed to satisfy mission operational requirements from designated AN link manager node |
| |Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by|
| |the designated AN link manager node |
| |Monitoring and Evaluation |
| |Monitors and evaluates node’s network and link performance |
| |Collects/processes/analyzes status reports from assigned subnet and/or backbone nodes |
| |Reports status to designated AN link manager node |
| |Topology Management |
| |Determines needed subnet and/or backbone connectivity for assigned nodes to establish a topology that satisfies |
| |current mission operational requirements |
| |Performs admission control for each node requesting connection |
| |Provisions subnet and/or backbone resources, determines network and link parameters for assigned nodes, and directs |
| |adjustments to network component and link parameters for assigned nodes that request network service |
| |Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to |
| |accommodate changes in service requests, participating nodes or equipment status (based on status reports) |
| |Manages the handoff of links within its subnet and/or backbone to ensure seamless connectivity |
| |Reconfigures subnet and/or backbone topology as directed by the designated AN link manager node |
| | |
| |Network Management |
| |Fault, Configuration, Accounting, Performance, Security (FCAPS) Management |
| |Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults |
| |Provide configuration of AN system parameters, detect configuration changes |
| |Perform accounting of resource utilization to verify that resources are being utilized in accordance with |
| |commanders’ operational objectives |
| |Collect network performance statistics, status, and event notification data, analyze and resolve performance faults |
| |and reconfigure network resources as warranted |
| |Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. |
| |Network Situation Awareness |
| |Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data in near |
| |real-time to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps |
| |center |
| |Display system and network resources, showing their operational status and linkages to other resources |
| |Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN |
| |Policy Based Network Management |
| |Provision and dynamically update local network policies, including for IA and QoS |
| |Perform policy accounting, including SLA management and negotiation |
| |Provide network access control |
| | |
| |Network Services |
| |Name Resolution System |
| |Dynamic Network Configuration Management |
| |Network Time |
|Network |Connectivity |
|Service |Backbone |
|Provider |Subnet |
| |Subnet, Backbone, GIG Access |
| |Routing/ Switching (Intra-Area Router, Area Border Router, AS Border Gateway Router) |
| |QoS |
| | |
| |Information Assurance |
| |Policy Based Security Management |
| |User data protection through use of Inline Network Encryptor (e.g., HAIPE) |
| |Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data |
| |TRANSEC |
| |I&A, data integrity validation, etc. |
| |Automated Key Management – management of node’s keys; access to replacement keys |
| |Attack Sensing, Warning, and Response |
| |Virus Protection |
| |Protocol Security |
| | |
| |Link Management |
| |Advertising and Discovery |
| |Advertises node’s identity and location |
| |Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available |
| |network capabilities |
| |Establishing and Restoring |
| |Requests network service needed to satisfy mission operational requirements from designated AN link manager node |
| |Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by|
| |the designated AN link manager node |
| |Monitoring and Evaluation |
| |Monitors and evaluates node’s network and link performance |
| |Collects/processes/analyzes status reports from assigned AN nodes |
| |Reports status to designated AN link manager node |
| |Topology Management |
| |Determines needed access, subnet and/or backbone connectivity for assigned nodes to establish a topology that |
| |satisfies current mission operational requirements |
| |Performs admission control for each node requesting connection |
| |Provisions access, subnet and/or backbone resources, determines network and link parameters for assigned nodes, and |
| |directs adjustments to network component and link parameters for assigned nodes that request network service |
| |Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to |
| |accommodate changes in service requests, participating nodes or equipment status (based on status reports) |
| |Manages the handoff of links within its subnet and/or backbone to ensure seamless connectivity |
| |Reconfigures access, subnet and/or backbone topology as directed by the designated AN link manager node |
| | |
| |Network Management |
| |Fault, Configuration, Accounting, Performance, Security (FCAPS) Management |
| |Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults |
| |Provide configuration of AN system parameters, detect configuration changes |
| |Perform accounting of resource utilization to verify that resources are being utilized in accordance with |
| |commanders’ operational objectives |
| |Collect network performance statistics, status, and event notification data, analyze and resolve performance faults |
| |and reconfigure network resources as warranted |
| |Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. |
| |Network Situation Awareness |
| |Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data in near |
| |real-time to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps |
| |center. |
| |Display system and network resources, showing their operational status and linkages to other resources. |
| |Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN and its peer |
| |networks. |
| |Network Resource Planning (likely performed at a single AF Network Operations facility or ground NSP) |
| |Develop and maintain a network resource plan for the allocation and configuration of network elements through range |
| |of operations |
| |Formulate policies in accordance with network resource plan |
| |Store policies in policy repository |
| |Policy Based Network Management |
| |Provision and dynamically update network policies, including for IA and QoS |
| |Perform policy accounting, including SLA management and negotiation |
| |Provide network access control |
| |Network Modeling, Analysis, and Simulation (likely performed at a single AF Network Operations facility or ground |
| |NSP) |
| |Provide tools for examining network functional and performance characteristics; use results to refine resource |
| |planning and policy formulation |
| | |
| |Network Services |
| |Name Resolution System |
| |Dynamic Network Configuration Management |
| |Network Time |
4.3.2 Link Types
4.3.2.1 Backbone
The AN quasi-persistent core backbone will provide a high-performance and fault-resilient routed structure that can be characterized by a defined network capacity, latency and loss rate. The backbone should be composed of relatively stable high bandwidth links between a defined set of platforms. Ideally, the backbone links should be symmetric and point-to-point with as equal bandwidth, latency, and loss characteristics as is possible. It should be implemented to enable alternative path routing and fast routing convergence, consistent steady-state traffic engineering and latency performance, and consistent failure mode behavior. This backbone should also be implemented to enable optimized paths between interconnections, dynamic load-sharing across the core structure where appropriate, and efficient and controlled use of bandwidth. [Source: Understanding Enterprise Network Design Principles]
The AN backbone will provide the following advantages to the overall network performance:
• Reduce overall network complexity: Even if it is based upon and formed using mobile ad-hoc networking technology, the backbone can be considered a part of the routing infrastructure that does not change nearly as frequently as other subnets attached to it. It therefore enables use of a much simpler and efficient routing protocol among backbone routers, essentially the same protocol as is used on terrestrial networks.
• Increases overall network stability: The fact that there are platforms whose locations and flight characteristics are relatively stable gives them the inherent ability to form relatively stable interconnections between them, whether they form these connections in an ad-hoc fashion or not. These stable links can be used in network paths between users having needs for stable and persistent connectivity.
• Facilitates reliable performance: Including relatively stable links in the network paths enables resources to be reserved, where needed, for traffic having high reliability requirements.
• Provides location for common services: Many of the nodes comprising the backbone can be used to host common network services, such as directories and gateways, so that smaller, more constrained platforms do not need to do so.
• Provides aggregation points for SATCOM and ground interconnects: Nodes on the backbone can serve as airborne concentration points for interconnection to the SATCOM backbone networks and terrestrial networks.
4.3.2.2 Subnet
AN subnets will be formed to satisfy the specific communications transport needs of a set of platforms. The subnet links maybe point-to-point or broadcast, high or low bandwidth, LOS or SATCOM as needed to satisfy the mission needs. Subnet connections can be prearranged quasi-static connections, ad hoc quasi-static connections, ad hoc dynamic connections (connections of opportunity) consisting of any communications media capable of supporting IP traffic.
4.3.2.3 Network Access
AN network access links will provide connectivity to AN and/or GIG services. The network access links may be high or low bandwidth, LOS or SATCOM and function as a circuit or trunk. These links must enable AN and GIG security, addressing, network management, QoS, admission control, and network services.
4.3.2.4 Legacy
AN legacy links refer to any connectivity established using non-IP communications systems typically capable of supporting voice, tactical data link (TDL), and possibly some point-to-point IP network connections for very limited services (e.g., email only).
4.3.3 Typical Topologies
The Airborne Network will be capable of forming many different topologies, each matched to a particular mission, set of platforms, and communications transport needs. This flexibility will enable the AN to meet performance objectives while minimizing the infrastructure required or the use of scarce resources.
4.3.3.1 Space, Air, Ground Tether
Tethering aircraft consists of establishing a direct connection to another aircraft or ground node, via a point-to-point link for nodes within line of sight (LOS) or via a SATCOM link for nodes that are beyond line of sight (BLOS). As in the case of the VIP/SAM aircraft that have been recently equipped with the Senior Level Communications System (SLCS) or a B-2 with reachback communications, a SATCOM link provides connectivity to a network ground entry point as shown at the left in Figure 4-2. Strike aircraft that accompany C2 aircraft such as an AWACS are tethered via point-to-point links as shown in the center of the figure. Finally, C2 or ISR aircraft may connect via a LOS link directly to a network ground entry point as shown at the right in the figure. Each of these tethered alternatives requires the presence of a tethering point that has been pre-positioned.
[pic]
Figure 4-2. Airborne Network Tethered Topologies
4.3.3.2 Flat Ad-Hoc
A flat ad-hoc topology, as shown in Figure 4-3, refers to establishing nonpersistent network connections as needed among the AN nodes that are present. With this network the AN nodes dynamically “discover” other nodes to which they can interconnect and form the network. The specific interconnections between the nodes are not planned in advance, but rather are made as opportunities arise. The nodes join and leave the network at will continually changing connections to neighbor nodes based upon their location and mobility characteristics. This type of network topology would best serve missions involving a relatively small number of aircraft that are very dynamic and have modest communications transport needs.
[pic]
Figure 4-3. Airborne Network Flat Ad-Hoc Topology
4.3.3.3 Tiered Ad-Hoc
Ad-hoc networks can be flat in the sense that all AN nodes are peers of each other in a single network, as discussed above, or they can dynamically organize themselves into hierarchical tiers such that higher tiers are used to move data between more localized subnets. Figure 4-4 depicts such a tiered ad-hoc topology. This network topology would be beneficial as the number of aircraft increases, or their mobility patterns become more stable, or the communications transport needs increase.
[pic]
Figure 4-4. Airborne Network Tiered Ad-Hoc Topology
4.3.3.4 Persistent Backbone
A network topology characterized by a persistent backbone in shown in Figure 4-5. The backbone is established using relatively persistent wideband connections among high-value platforms flying relatively stable orbits. The backbone provides the connectivity between the tactical subnets which are considered edge networks relative to the backbone. The backbone provides concentration points for connectivity to the space backbone as well as to terrestrial networks. This type of network topology would be needed to support a C2 Constellation consisting of several C2 and ISR aircraft exchanging high volumes of high priority, latency-sensitive sensor and command data among themselves and with strike aircraft.
[pic]
Figure 4-5. Airborne Network Persistent Backbone Topology
5. Airborne Network System Functions (SV-4)
5.1 On-Board Infrastructure
5.1.1 Intra Platform Distribution
5.1.1.1 Serial Data Buses
Serial data buses will provide highly reliable, fault tolerant, deterministic, serial switched interconnections for on-board mission systems where timing jitter and missed deadlines are intolerable. Serial data buses, such MIL-STD-1553B and newer enhanced rate standards, typically employ dual (and multiple) redundancy to provide the requisite levels of fault tolerance and command/response techniques to provide the guaranteed real-time deterministic performance.
5.1.1.2 Local Area Networks
Avionics-quality data networks based on COTS networking technologies will provide high data throughput while achieving bounded latency, determinism and guaranteed availability for critical applications.
5.1.2 Platform Information Assurance
The platform security system will enable authenticated and authorized operators to monitor ongoing security events and verify the configuration of security components. Within the constraints of security policy, it will allow authenticated and authorized operators the ability to modify system security behavior. Platform security components will integrate with the AN Policy Based Security Management (PBSM) system allowing dissemination, installation and enablement of security policy on platform security components. Through interfaces with the AN network management system, authorized network management systems will be able to query platform security components and platform secured components to determine their configuration, health, and performance. IA capabilities that may be provided by platform LANs include:
• Ability to report configuration, status, and performance of security components (e.g., HAIPE devices) and secured components (e.g., routers).
• Ability to receive, validate, process, and implement security policy distributed by the AN PBSM system.
• Provide for user and AN node data protection. Data protection includes support for data confidentiality, integrity, digital signatures, etc., as appropriate for the data and applications.
• Accomplish I&A.
• Provide for Key Management.
• Support Attack Sensing, Warning, and Response (ASWR.) ASWR includes Intrusion Detection and Prevention and Virus Detection. ASWR will provide the capability to report all instances of detected security threats such as unauthorized attempts to use or penetrate the network or to deny service.
• Provide for protocol security.
5.1.3 Platform Network Management
The platform network management system will enable operators to manage all on-board network elements. The platform network management system will interface and interoperate with the AN network management system to enable operators to manage remote network elements in the airborne network.
The platform network management system will be capable of:
• Monitoring the health and status (to include identifying and locating faults) of managed network elements through both passive receipt and interpretation of status and alert messages and by active probes.
• Reporting the settings of all configurable parameters that can be provided by every network element. The system will enable an authorized and authenticated operator to change the settings of all configurable parameters for every network element.
• Monitoring and reporting the utilization of every network element. The system will be capable of receiving and applying network policy information to effect changes in allocations of network resources to traffic flows.
• Changing the security configuration of network elements. The system will be capable of reporting the initial configuration and all changes to the security configuration of network elements and host systems and all instances of detected security threats such as unauthorized attempts to use or penetrate the network or to deny service.
5.1.4 Gateways/Proxies
Gateways and/or proxies will enable: (1) interconnection of legacy on-board infrastructure (e.g., serial data buses) to the IP-based airborne network, (2) use of legacy off-board transmissions systems to transport IP-based traffic, (3) interconnection of legacy Tactical Data Link (TDL) systems into the airborne network, and (4) the use of standard COTS and AF IP-based user applications over impaired (i.e., limited bandwidth, long delays, high loss rates, and disruptions in network connections) airborne network connections. These systems will facilitate the transition of the legacy on-board infrastructure, transmission systems, TDLs, and user applications to the objective airborne network systems. Therefore, these systems will only be needed during a transition period, and the scope of the needed functionality will vary with specific platforms. (Note, the transition period may extend indefinitely to accommodate interoperability with allied and coalition platforms and systems.)
5.1.4.1 Legacy Infrastructure Gateways
Legacy gateways provide an interface(s) between the on-board legacy infrastructure (such as MIL-STD-1553 data, audio and video) and the on-board IP network to enable legacy host systems (e.g., servers, OWSs, radios, radio access, video distribution and display, etc.) to interoperate with IP-based host systems and to access the airborne network.
5.1.4.2 Legacy Transmission System Data Link Gateways
Legacy transmission system gateways can be used to enable legacy voice and data radio channels to be used to transport IP traffic. These gateways (such as those developed for AFRL’s Information for Global Reach (IFGR) project) overcome the low bandwidth, high loss, long delay, half-duplex environments of legacy radio systems using a variety of techniques. A combination of Forward Error Correction (FEC) and Automatic Request for retransmission (ARQ) can be used to decrease the wireless error rate in the datalink layer along with some of the Performance Enhancing Proxy techniques discussed below.
5.1.4.3 TDL Gateways
TDL gateways (such as the Common Link Interface Processor (CLIP)) perform message processing and formatting, data translation and forwarding, and radio interface and control to enable interconnection of legacy data link systems into the airborne network.
5.1.4.4 Performance Enhancing Proxies
Performance Enhancing Proxies (PEPs) improve the performance of user applications running across the AN by countering wireless network impairments, such as limited bandwidth, long delays, high loss rates, and disruptions in network connections. These systems are functionally implemented between the user application and the network and can be used to improve performance at the application and transport functional layers of the OSI model. Some techniques that can be employed include:
• Compression: Data compression or header compression can be used to minimize the number of bits sent over the network.
• Data bundling: Smaller data packets ca be combined (bundled) into a single large packet for transmission over the network.
• Caching: A local cache can be used to save and provide data objects that are requested multiple times, reducing transmissions over the network (and improving response times).
• Store-and-forward: Message queuing can be used to ensure message delivery to users who become disconnected from the network or are unable to connect to the network for a period of time. Once the platform connects, the stored messages are sent.
• Pipelining: Rather than opening several separate network connections pipelining can be used to share a single network connection for multiple data transfers.
• Protocol streamlining: The number of transmissions to set-up and take down connections and acknowledge receipt of data can be minimized through a combination of caching, spoofing, and batching.
• Translation: A translation can be performed to replace particular protocols or data formats with more efficient versions developed for wireless environments.
• Embedded acknowledgments: Acknowledgements can be embedded in the header of larger information carrying packets to reduce the number of packets traversing the network.
• Intelligent restarts: An intelligent restart mechanism can be used to detect when a transmission has been dropped and reestablished, and then resume the transmission from the break point instead of at the beginning of the transmission.
• Transmission Control Protocol (TCP) replacement or enhancement: A replacement to standard TCP, or an enhanced TCP variant can be used over wireless links with high losses and/or long delays.
• Link Error Awareness (LEA): LEA can be used to distinguish and handle efficiently the two type of network losses -- losses due to congestion, and losses related to link errors.
5.2 AN Equipment
5.2.1 Inter-node Connectivity
5.2.1.1 Routing/Switching
The AN routing/switching function will enable the dynamic exchange of traffic with other platforms and will be capable of both off-board and transit routing. Off-board routing pertains only to the traffic originating on or destined for hosts on the local platform. Transit routing deals with traffic originating on other platforms and destined for hosts on other platforms. AN routers/switches will also enable the exchange of traffic to other GIG fixed, deployed, and mobile networks. AN routers/switches must be capable of performing static, dynamic or ad hoc routing as needed, with flat or hierarchical routing topologies. The AN will enable platforms to dynamically change their points of attachment to the network with no disruption to incoming or outgoing traffic flows and minimal loss of data (i.e., seamless roaming).
The AN routers/switches must direct traffic from the on-board infrastructure to an off-board legacy, subnet, network access or backbone link transmission system. Typical routing/switching functions include:
• Media translation
• Address translation
• Security and firewalls
• Neighbor (network router) discovery
• Exchange of routing information
• Detection and propagation of link status changes
• Initialization and maintenance of routing tables
• Path determination
• Packet marking, classification, conditioning, and servicing (queuing and scheduling)
• Packet forwarding
• Policy enforcement
• Packet filtering
• Load Balancing
• Route flap dampening (i.e., suppressing router update transmissions caused by unstable links changing available paths)
Table 5-1 summarizes the AN routing functional requirements.
Table 5-1. AN Routing Functional Requirements
|Requirement |Description |
|Loop-free |AN routing/switching will produce forwarding paths that do not contain circular routing loops, |
| |i.e., traffic passes through an AN router/switch only once on its path from source to destination.|
|Directionality |AN routing/switching will be possible with the use of bidirectional, unidirectional, or asymmetric|
| |paths. |
|Routing Topologies |AN routing/switching will support both flat network topologies and hierarchical network |
| |topologies. When in a hierarchical network topology, the AN will be capable of end system, |
| |intra-area, inter-area, and inter-domain (or autonomous system (AS)) routing) as opportunities and|
| |needs arise. |
|Transmission Types |AN routing/switching will be capable of routing user information as unicast, broadcast, multicast,|
| |and anycast network transmissions between AN Nodes on any part of the AN or GIG. |
|Time reference |The AN routing/switching will not require a universal time reference at all nodes in network. |
|Routing Metric |As a minimum, the AN will enable routing decisions to be based upon the following criteria: |
| |number of hops, |
| |bandwidth availability, |
| |delay, |
| |relative reliability of each available path, |
| |traffic load, |
| |media preference (to prioritize non performance functions such as LPI/LPD, AJ, fast handoff |
| |capability), |
| |path bit error rate or packet loss rate |
| |cost (i.e., dollars). |
| |As a goal, the AN shall also enable routing decisions to be based upon the following criteria: |
| |relative stability of the path as determined by the number of link state changes that have |
| |occurred in a unit of time over all links comprising the path, |
| |relative availability of the path as determined by the proportion of time the path has been |
| |operational in an interval of time, |
| |geographic position, |
| |speed and heading. |
|Constraint Based |The AN will enable the use of any combination of the above route selection criteria for routing |
|Routing |decisions, prioritized and weighted according to user determined policy and quality of service |
| |needs. |
|Responsiveness |The AN will change the routes used to forward information in response to changes in the available |
| |communications resources, offered traffic patterns, and performance demands in order to make most |
| |efficient use of network resources in accordance with the communications policy in place at the |
| |time. |
|Scalability |The AN routing protocols will operate with varying numbers of platforms, varying numbers of fast |
| |moving platforms, varying amounts of offered traffic per platform. |
|Robustness |The AN routing protocol will be resistant to link or node failures or high link bit error rates. |
| |In the event of a failure of a single AN Node or link, the AN will be capable of routing traffic |
| |to the remaining AN Nodes. |
| |The AN will provide a failover mechanism for any critical AN nodes to avoid potential single |
| |points of failure. |
| |The AN will be capable of routing information to segments of the network that became partitioned |
| |due to critical AN Node or link failures by using any other links or networks available, including|
| |terrestrial and space networks. |
|Compatibility with |AN routing will be compatible with standard Internet routing protocols and compliant with |
|standard Internet |applicable Air Force and DoD directives on their use. |
|protocols | |
5.2.1.2 Quality of Service (QoS)/Class of Service (CoS)
QoS mechanisms will allow the AN to make decisions on resource allocation and traffic handling based on recognition of different types of traffic with different performance expectations. The AN must also provide the capability to prioritize traffic based on class of user, application, or mission; and to preempt a lower priority data flow if a higher priority flow is initiated and insufficient resources exist to carry both flows simultaneously. This capability, referred to as Class of Service (CoS) support, corresponds approximately to Multi-Level Precedence and Preemption (MLPP).
The AN will provide the capability to assess QoS/CoS requirements to determine if they can be met. QoS requirements are used to derive network resource and configuration needs. They are successively mapped into quantitative QoS parameters relevant to various AN systems that can be monitored and controlled. QoS parameters may be oriented towards
• Performance - sequential versus parallel processing, delays, data rate
• Format - transfer rate, data format, compression schema, image resolution
• Synchronization - loosely versus tightly coupled, synchronous versus asynchronous
• Cost - platform rates, connection and data transmission rates
• User - subjective quality of images, sound, response time
In allocating resources, the Link Management system must not only consider resource availability and resource control policies, but also QoS requirements. To ensure the required QoS is sustained, the Link Management system must be capable of monitoring QoS parameters and reallocating resources in response to system anomalies. This requires monitoring resource availability and its dynamic characteristics, e.g., measuring processing workload and network traffic, to detect deviations in the QoS parameters. When there is a change of state, i.e., degradation in the QoS, and the Link Management system cannot make resource adjustments to compensate, then the application is notified. The application must either adapt to the new level of QoS or scale to a reduced level of service.
Supporting these QoS functional requirements for the AN, where the network topologies, links, platforms, and information exchange needs are dynamic will require an adaptable QoS architecture. This architecture must include QoS-aware application interfaces, a variety of dynamically configurable QoS/CoS mechanisms, QoS-based routing, and a network-wide QoS manager as depicted in Figure 5-1.
[pic]
Figure 5-1. QoS Functional Components
5.2.1.2.1 QoS-Aware Application Interfaces
The AN must be capable of providing adequate communications services for a wide variety of user mission applications, from those that do not address QoS to those that are fully QoS-aware capable of requesting specific QoS needs and adapting to degraded network conditions. QoS-aware application interface components will provide the functionality necessary to provide consistent QoS treatment for all user mission applications, including:
• Identification, classification, and marking of traffic flows
• Monitoring and controlling of traffic flow rates and bandwidth allocations
5.2.1.2.2 QoS/CoS Mechanisms
The AN end-to-end QoS/CoS architecture must include multiple, complementary mechanisms, such as admission control, traffic shaping, various queue management strategies, and application-layer aspects as listed in Table 5-2.
Table 5-2. QoS Mechanisms
|Tools/Techniques/Technologies |Use and Benefit |
|Differentiated Services (DiffServ) |Prioritizing tool |
|Admission Control |Policy admission tool |
|Bandwidth Broker |Network controlling tool |
|802.1Q and P |Traffic classification and routing tool |
|Resource Reservation Protocol--Tunneling Extensions |Connection assurance tool |
|(RSVP-TE) | |
|Multi-Protocol Label Switching--Traffic Engineering |Connection assurance and traffic engineering tool |
|(MPLS-TE) | |
|Real-time configuration management of applications, |Positive enterprise control tools |
|networks, and edge-user devices | |
|Application-to-Network exchange of network capability |Applications can behave adaptively to changing network conditions to |
|and performance information (traffic engineering) |provide the user with best possible service |
|Metadata Tagging (pending modification of DoD |Data is marked with time sensitivity to indicate usefulness, accuracy, |
|Standards) |and/or need |
5.2.1.2.3 QoS-Based Routing/Switching
The AN will employ QoS-based routing/switching in which paths for flows are determined based upon knowledge of available network resources as well as the QoS requirement of the flows. QoS-based routing path-selection criteria will include QoS parameters such as available bandwidth, link and end-to-end path utilization, node resources consumption, delay and latency, and induced jitter.
The main objectives of QoS-based routing are:
• Dynamic determination of feasible paths: QoS-based routing will determine a path, from among all available choices, that is capable of accommodating the QoS of the given flow. Feasible path selection will be subject to policy constraints.
• Optimization of resource usage: Network state-dependent QoS-based routing will enable the efficient utilization of network resources by improving the total network throughput.
• Graceful performance degradation: State-dependent routing will compensate for transient inadequacies in network engineering (e.g., during focused overload conditions), giving better throughput and a more graceful performance degradation.
5.2.1.2.4 QoS Manager
Each AN node will have a QoS manager that brokers network resources and services for user mission applications, provisions network resources, and controls the QoS-related configuration of network components. Each QoS manager will receive requests from host applications and peer QoS managers for network services. The QoS manager at Network Service Provider nodes will also receive requests from other component GIG networks. Each QoS manager will interoperate with the link management, policy-based network management, and policy-based security managements systems to provision network resources. Each QoS manager will also be capable of controlling the QoS-related configuration of the network components located at the node.
The QoS manager will be a distributed function capable of performing the following:
• Brokering Network Resources and Services
o Verify user/application QoS privileges
o Negotiate service level agreement (SLA) with application subject to network and security policies
o Negotiate SLA with other GIG networks subject to network and security policies
o Monitor network performance
o Alert application/GIG network when network not meeting SLA (i.e., QoS violations)
o Identify corrective actions and renegotiate SLA with application/GIG network
• Provisioning Network Resources
o Map QoS requests to network devices
o Manage end-to-end network configuration
o Perform admission control
o Monitor, allocate, and release network resources
o Request additional network resources
o Adapt to changes in available network resources
• Controlling Network Components
o Configure network components for selected QoS/CoS mechanisms
o Adapt/modify network component QoS/CoS related parameters (e.g., routing metrics, router update mechanism, router flow conditioning, queue management, flow scheduling, etc)
5.2.2 Information Assurance
AN Information Assurance components will enable or extend access to DoD GIG based security or may organically provide the security services. IA services will be enabled regardless if the AN is connected to other GIG transport networks or operating as a GIG disconnected, stand-alone network segment. IA services will be designed to function under constraints such as low-bandwidth, high-latency connections, unidirectional links, or with nodes operating in LPI/LPD modes to include receive-only. AN IA components will interoperate with the GIG IA infrastructure and other non-GIG IA infrastructures including coalition IA infrastructures. This interoperability may come from direct interface with the external infrastructure (e.g., with GIG core security functions) or through a gateway or proxy system (e.g., interoperating with allied or coalition IA infrastructure.)
5.2.2.1 GIG IA Architecture
The Department of Defense (DoD), Intelligence Community (IC), and other Federal agencies (e.g., the National Aeronautics and Space Agency (NASA) and the Department of Homeland Security (DHS)) require the development of an assured global national security information technology enterprise to achieve their strategic visions of information superiority, net-centric operations, and collaborative information sharing. To achieve their visions, the DoD’s GIG and the IC’s Horizontal Integration (HI) initiatives will transform the way they operate, communicate, and use information. This transformation from a need-to-know to a need-to-share information protection model is enabled by tightly integrating the business, warfighter, and national intelligence domains with the technical infrastructure domain through a net-centric enterprise capability. The AN is an element of the GIG technical infrastructure, providing airborne connectivity to support mission critical communications and applications. The GIG IA Architecture defines six operational mission concepts that IA enablers must support. (See section 6 for additional discussion on GIG operational mission concepts and IA system enablers.)
GIG Mission Concepts and IA System Enablers (Functions)
As an element of the GIG fabric, the AN is a transport component of the larger GIG enterprise. The AN IA architecture will support the six primary GIG mission areas as follows:
• Provide Common Services – Provision a set of common services to all users to support all missions, enabling the Task, Post, Process, and Use (TPPU) model of information management.
o The AN will use Distributed Policy-Based Access Control to mediate access for all users to system communications, information and services based on user identities, privileges, digital policy, object attributes, environmental attributes and mission need.
o The AN will determine the end-to-end protection that can be provided combined with the end-to-end protection required by an information object and visibility into enforcement mechanisms to ensure that information is not shared with systems that cannot adequately protect it to create a Secure End-to-End Communications Environment.
o Enterprise-Wide Network Defense and Situational Awareness will allow the AN to audit all accesses to communications, information and services, protect audit information during generation, processing and storage in such a way as to ensure non-repudiation by the user, and use audit information to detect inappropriate access to information and resources.
o The AN will use Distributed Policy-Based Access Control to enable authorized users to access control policy when critical mission needs require it.
• Provide Worldwide Access – The ability to connect regardless of location giving users access to all assets needed to accomplish their mission.
o Using Identification and Authentication Strength of Mechanism to ensure confidentiality and authentication, the AN will provide a communications path for users that have strongly authenticated identities and verified authorizations.
o Using Enterprise-Wide Network Defense and Situational Awareness, the AN will provide notification of compromised devices and the revocation of all authorization for that device.
o Using Enterprise-Wide Network Defense and Situational Awareness, the AN will have the ability to create audit files that include strongly authenticated and protected information about endpoints, network devices and processes, and network management control actions.
o To ensure confidentiality, the AN will protect network topology and access location data using the Secure End-to-End Communications Environment that could be used to geolocate users.
o Using Distributed Policy-Based Access Control, the AN will provide access control to network transport capabilities based on authenticated user identity, user privileges, authenticated network access device identity, location, Quality of Service/Class of Service (QoS/CoS) and user priority settings.
• Provide Dynamic Resource Allocation – Allocate network and computing resources based on dynamic mission needs. The AN will use Assured Management and Allocation of Resources to:
o Provide two-way authentication and the establishment of the integrity of all management and control commands that implement resource configuration, allocation and enforcement.
o Provide a policy based enforcement mechanism to ensure that users are not exceeding their allocated resources or privileges.
o Provide a policy override feature to enforce priority of certain information such as survival data.
o Ensure audit log entry of all changes to the QoS/CoS settings and policy override actions are securely maintained.
o Provide real-time situational awareness picture of all resources.
• Provide Dynamic Group Formation – Dynamically form groups of users and enable these groups to communicate and share a common set of information and services only with each other.
o Using Dynamic Policy Management, the AN will provide dynamic allocation and enforcement of COI communications and computing resources and services.
o Dynamic Policy Management will also provide support for cross-domain connectivity between the GIG, the AN, and other external systems.
• Provide Computer Network Defense (CND) – Provide a proactive and reactive capability for computer network defense; protect, monitor, detect, analyze and adaptively respond to unauthorized system and network activities. Using Enterprise-Wide Network Defense and Situational Awareness, the AN will be able to:
o Provide increased priority to enable the timely delivery and processing of sensor data and the derived situational awareness information to support the execution of analyzed and deliberate responses.
o Provide real-time monitoring, collection, anomaly detection and analysis of all sensor data.
o Ensure protection mechanisms are provided to sensor data and the derived situational awareness information to guarantee their integrity and availability.
o Provide for the secure collection and processing of sensor and situational awareness data throughout the AN.
o Provide secure logs to record all CND and IA actions taken to adjust the AN and GIG configurations. The logs should include the initiating user, time of action and the action taken.
o Provide an ability to automatically uncover vulnerabilities and predict intrusion/attack strategies that can exploit the vulnerabilities.
• Provide Management and Control of GIG Network and Resources – Securely manage and control all communication, computing resources and services, remotely and in an automatic manner. Given the scope of management and control, protection of this information is critical to preventing unauthorized entities (including GIG and non-GIG entities) from gaining access to GIG components and affecting the availability of the GIG.
o Using Assured Management of Enterprise-Wide IA Mechanisms and Assets, the AN will provide secure management of the configuration of the GIG, monitoring for unauthorized configuration changes and securely applying updates; provide the capability to automatically configure and reconfigure its resources, receive configuration status from its resources and generate reports on the configuration of its resources; provide the ability to set limits on the usage of its resources and provide for automatic corrective actions when thresholds are exceeded; provide the ability to define, enforce and control a digital security policy across security domains and COIs; provide the ability to correlate and deconflict differing policies to arrive at a mutually acceptable policy; provide the ability to securely distribute and validate updates or changes to the digital security policy; and provide the ability for network managers to manage and control differential delivery of information, based on QoS/priority settings of the information flow, as well as traffic planning/engineering inputs at a network level.
o Enterprise-Wide Network Defense and Situational Awareness will allow the AN to ensure all components, especially IA-specific, have the capability of recording audit events and posting audit reports for access by management and control entities, and maintaining the availability and integrity of all such records.
5.2.2.2 Supporting Infrastructures
5.2.2.2.1 Security Management Infrastructure (SMI)
Supporting infrastructures provide the foundation upon which IA mechanisms are used in the network, enclave, and computing environments for securely managing the system and providing security-enabled services. Supporting infrastructures provide security services for networks, end-user workstations, servers for Web, applications, and files, and single-use infrastructure machines (e.g., higher-level Domain Name Server (DNS) services, higher-level directory servers).
An overall supporting infrastructure for secure environments is referred to as a Security Management Infrastructure (SMI). An SMI is comprised of components, functions, and products provided by external systems and/or within the system. Examples of SMI provided products include software-based cryptographic algorithms, symmetric keys, public keys, X.509 certificates, and virus update files.
Under the Cryptographic Modernization Initiative (CMI), the DoD is transforming the cryptographic inventory to offer significant operational benefit in alignment with the Department’s commitment to transformational communications and related (e.g., net-centric) warfare doctrines. The CMI will introduce new End Cryptographic Units (ECUs) incorporating flexible, programmable cryptography, new cryptographic algorithms, new key types, and capabilities for electronic downloading of new operating or application software, including cryptographic software. ECUs will have provisions for dynamically changing operating modes, algorithms, or keys in response to new missions. The emerging ECU characteristics require an overarching ECU Management Infrastructure. Currently, a framework consisting of five categories of ECU management has been defined.[1]
• Inventory Management – Tracking possession (quantities, locations, status, owner identity) of ECUs.
• Configuration Management – Establishing hardware and software baselines for ECUs; managing optional and mandatory hardware and software updates; and maintaining records of approved equipment and system configurations.
• User Data Management – Creation, distribution and installation of various types of user data associated with a specific mission, not categorized as configuration or key management data. Examples are frequency allocations or hop sets and IP addresses.
• Key Management – Provisioning of cryptographic key and PKI certificates to ECUs, including ordering, generation, production, delivery, loading, auditing, accounting, and tracking of keys and certificates.
• Policy Management – Provide authority structure to manage and change security policies enforced in ECUs.
The specific infrastructures and processes supporting these management categories will consist of a combination of external infrastructures and local, organizational infrastructures. For example, management of AN ECU inventory records will be conducted at an AN management facility with interfaces to external organizations such as NSA. User data management, policy management and configuration management functions will also be initiated and performed at an AN management facility. Configuration functions such as reprogramming of cryptographic algorithms will require interfacing to the DoD’s KMI. The KMI will provide the secure creation, distribution, control and management of public key products, traditional symmetric keys, and support for manual cryptographic systems. The KMI will support the entire range of key management needs including registration, ordering, key generation, certificate generation, distribution, accounting, compromise recovery, rekey, destruction, data recovery, and administration. While the DoD KMI is the primary source for AN key-related products, dependent on mission requirements, the IC Public Key Infrastructure (PKI) and the DoD PKI may provide support for certain key and certificate requirements.
Currently, the DoD is operating a separate PKI that provides X.509 based certificate products for DoD personnel and devices. Similarly, the DoD is currently operating the legacy Electronic Key Management System (EKMS) that provides key management support for all other symmetric (i.e., traditional) and asymmetric (i.e., public) key management needs. However, in the FY07 – FY09 timeframe, EKMS functions will be transitioning into the DoD KMI.[2] Also, the DoD PKI will be brought under the DoD KMI umbrella. Early AN operations may need to interface with the EKMS to obtain key. The AN must also project evolving its key management processes from EKMS to KMI.
5.2.2.2.2 DoD Key Management Infrastructure (KMI)
The AN will use the DoD Key Management Infrastructure (KMI) and Electronic Key Management System (EKMS) processes as its core key management capability. The AN will limit the keys it requests from the KMI to those necessary to configure, operate and manage the devices that are integral to and directly managed by the AN. These keys will include those necessary to enable operator, manager, and administrator access to AN components.
The KMI will support the AN by providing:
• End Cryptographic Unit (ECU) registration
• Key ordering and generation
• Certificate generation
• Key distribution, accounting, and compromise recovery
• Rekey functions
• Key destruction
• Key and ECU administration
• Over the Network Keying
• HAIPEs, IPSec, and circuit link encryptors electronic key products and upgraded cryptographic algorithms
• TRANSEC device and packet masking function key material
• TBD functions and keys
5.2.2.2.3 Public Key Infrastructure (PKI)
PKI delivered Public Key (PK) services will support several security functions including validating integrity and origin of signed executable code (e.g., waveforms), configuration data, distributed key material, and management and control data. PK services also provide the basis for mutual authentication, and support identification and authorization. Finally, the PK certificates will be used to secure IPSec, TLS, and SSL tunnels and provide security to AN control and management data.
An AN will require node authentication and access control. The AN nodes will not process information received from other nodes or AN management systems or devices external to the AN until it validates that it is communicating with a valid, operational entity via crypto verification of the public key certificate. The digital signature will be used to provide authentication and integrity security services.
The AN must provide the means for AN connected networks to access GIG resident PK services. The AN may need to host functionality that will extend PKI services, such as certificate status checking, to the airborne network thereby ensuring entities (applications, devices, and humans) are able to seamlessly access PK services.
PKI will support the AN by providing:
• Identity, integrity, confidentiality, and non-repudiation
• Class TBD person certificates
• Class TBD device certificates
• Support certificate issuance, validation, and revocation for device and people certificates
PKI must support
• Disconnected operations
• Terminal, ECU, manager, operator, and administrator and other AN entity authentication
• Role based access management for nodes and other AN components including system managers, administrators and operators
• Secure policy distribution
• Network management and operations
• Protocol security
The AN may need to support extending PKI services to the AN operational domain by providing:
• Local storage of for certificate status validation data such as Certificate Revocation Lists (CRL)
• Processes, such as OCSP responders, necessary to support accomplishing certificate validation while minimizing bandwidth impact
• Local support for certificate public key storage
• LDAP or other DoD PKI interoperable directory service
• Extended PKI support when disconnected from DoD infrastructure.
5.2.2.3 AN Information Flows
Though the AN will support multiple user communities, the types of information flows handled by the system are common among those user communities. Table 5-3 identifies the types of AN information flows that need to be protected within the system boundaries. Security of the AN and the information transiting the system are critical to mission success. Classified national security information carried over the AN will be transmitted only by secure means. Sensitive but unclassified information will be protected during transmission according to the level of risk and the magnitude of loss or harm that could result from disclosure, loss, misuse, alteration, destruction, or non-availability. The AN will have the capability to transmit user information ranging in classification from unclassified up to and including Top Secret/Sensitive Compartmented Information (TS/SCI). The classification levels will be dependent on the ability of the system security components and processes or information originator to encrypt the information and the ability of the end user to provide the appropriate cryptographic devices for decryption. AN system information (management, disseminated policy, etc.) will be protected in a threat environment up to TBD.
Table 5-3. Summary of MAC and Confidentiality Level by Information Flow
|Information Flow |Mission Assurance Category |Confidentiality Level |
|User |MAC 1 |Defined by User |
|Policy Dissemination – Category I |MAC 1 |Sensitive |
|Policy Dissemination – Category II |MAC 1 |Classified |
|Network Management – Category I |MAC 1 |Sensitive |
|Network Management – Category II |MAC 1 |Classified |
|Network Control – Category I |MAC 1 |Sensitive |
|Network Control – Category II |MAC 1 |Classified |
Figure 5-2 depicts the System information flows and where those flows will interface with AN components and the GIG.
[pic]
Figure 5-2. Data Flows in Relation to AN, AN Nodes, and the GIG
5.2.2.3.1 Least Privilege
Least Privilege is an important IA concept for the AN. The key concept behind least privilege is that a user be provided no more privileges than necessary to perform a task. In an environment like the AN, this clearly becomes important in trying to ensure that users in a given user community are not capable of exceeding their assigned permissions and administrators of the AN are given system access compatible with their roles and responsibilities. To accomplish least privilege requires identifying what the user's job is, determining the minimum set of privileges required to perform that job, and restricting the user to a security domain with only those privileges. By enforcing least privilege, users or objects of the AN system will be unable to circumvent the organizational security policy.
5.2.2.3.2 User Traffic
Transport of user information through the AN is the core mission of the system. User information will flow from a user’s enclave – with confidentiality protection provided by the AN node or, in some cases, the user – to the AN. Typically, user information will enter the AN via an AN node or an edge interface with another transport network, then flow through the AN out to another AN node or through an interface to another transport network, and then to the distant end user’s enclave. User information can be data, voice, video, or imagery. The information owners or producers will determine the information sensitivity or confidentiality level; the AN node or the user’s system will provide for end-to-end confidentiality protection. While the user information will enter the AN as sensitive unclassified, the AN will be responsible for ensuring the availability of the transport and will be required to provide services to protect the transport, such as TRANSEC, logical separation between users in different user communities, and packet header masking or cover over RF communications.
5.2.2.3.3 Policy Dissemination
Policy dissemination information is the system data flows that are used to distribute security and management policy and enforce how AN components are managed, utilized and protected. Those AN components include all resources within the enterprise such as physical devices (e.g., routers, servers, workstations, security components), software (services, applications, processes), firmware, bandwidth, information, and connectivity. The policy dissemination data flows are the digital set of rules, coded in software or hardware into GIG assets, by which all actions of these assets must abide. To achieve enterprise wide (end-to-end) policy management of the AN, the policies defining the rules for use of information, communications (transport), and management and control functions must be integrated into a cohesive system policy. This includes establishment of an agreed approach for risk measurement, risk management and risk acceptance, through an Assured Information Sharing policy [TBD]. The policy defining interconnections with non-AN entities would specify functions such as U.S. access and handling rights for a foreign partner’s restricted data. Reciprocally, AN policies must address the access to GIG assets by these partners.
The dynamic and adaptive aspect of policy dissemination information allows for the rapid adjustment of these rules in response to crisis situations that require either a reduction of privileges or increased latitude. These adjustments will change the criteria used to determine how resources are allocated to users and how access control decisions are made. The AN must not only support adjustments to policy, but must also support conditional policies.
5.2.2.3.4 Network Management
Network management information is essential to gaining a view into the status and configuration of the AN. Network management information may include audit data, the capturing of AN network events, configuration commands and information, component management commands (such as AN node session establishment or disconnection), traffic statistics and performance data. Keying management information is also considered part of network management information.
Network management information is transmitted between the AN Network Manager and the AN network components. Network management data flows are two-way flows of information.
In addition to the intra-AN management flows, network management information will also be securely exchanged with external network operations centers (NOCs) (such as the Global Network Operations and Security Center (GNOSC)).
All AN management information flows must use authentication and protection techniques approved by NSA to ensure the authenticity and integrity of the information.
5.2.2.3.5 Network Control
Network control information includes link management exchanges, network services exchanges, router exchanges (e.g., Interior Gateway Protocol (IGP) exchanges, Exterior Gateway Protocol (EGP) exchanges, routing table updates), QoS signaling exchanges (e.g., Resource Reservation Protocol – Traffic Engineering (RSVP-TE). Network control information protection must include confidentiality mechanism to protect against traffic analysis attacks as well as integrity and authentication mechanisms to ensure the control information is authentic and unaltered. Control information that contains information that identifies individual users of the AN and/or their location must be protected at the MAC 1, Classified level.
5.2.2.4 AN IA Boundary
Definition
For the purposes of AN IA Architecture, an Information Assurance Boundary will be defined as:
A conceptual term used to delineate system Security Services; Integrity, Confidentiality, Non-Repudiation, Authentication and Availability, from other system services. The Information Assurance Boundary is rarely analogous to a physical boundary and will often consist of functions implemented in both hardware and software.
IA Boundary Identification Process
Identification of a system’s IA Boundary begins with creating the system’s Security Policy. This Security Policy specifies the system’s Security Services to be provided, the data elements requiring these protections and the handling requirements to be implemented. Any physical or functional component of the system which implements a part of its Security Policy is considered to be “Inside the IA Boundary” of that system. Once the IA Boundary is established, it is submitted to the system’s Designated Approving Authority (DAA) for Approval.
AN IA Boundary
The IA Boundary is established by the Designated Approving Authority (DAA) to include all hardware and software sub-systems which implement parts of the system Security Policy. AN functions which may be included in the AN IA Boundary are listed below:
• Encryption: TRANSEC, HAIPE, Bulk Encryption
• Privilege Management (e.g., PCF functions).
• Data Security Services (Integrity, Confidentiality, etc.)
• ASWR
• Key Management: Key Ordering, Generation, Distribution, etc.
• Network Operations and Management
• Network Services (e.g., DNS, Configuration Management Server)
• Backbone Routing Services (e.g., Routers, Switches)
• Operator Authentication mechanism(s)
5.2.2.5 Dynamic Policy Based Security Management (PBSM)
The AN, characterized by dynamic network topologies, will be subject to various types of complex security attacks and varying operational needs. The AN IA management capability will need to cover multiple security domains and COIs. This will require the trusted creation, distribution, and automated enforcement of IA policy directives. Policies prescribe the operational need, acceptable security risk, and weighting between the two under various conditions. The policy must be implemented in a manageable, flexible means, not “hard coded” into the design of system components.
Dynamic policy management is the establishment of digital policies for enforcing how AN assets are managed, utilized, and protected. This includes policies for access control, quality of protection, quality of service, resource allocation, connectivity, prioritization, audit, and computer network defense, as well as policies covering the use of AN component hardware and software. AN assets include all resources within the AN such as the physical devices (e.g., terminals, gateways, routers, security components), software (services, applications, processes), firmware, bandwidth, information, and connectivity. For example, security policies will be used to guide:
• Firewall configurations including open and closed ports and allowed or disallowed protocols
• Proxy configuration
• Attack profiles to detect
• Actions to take when an attack is detected
• Identification and Authentication (I&A) policy
• Virus checking policies, etc.
To achieve enterprise wide (end-to-end) policy management, the AN will implement core policies promulgated by the GIG. These policies will define the rules for information use, communications (transport), management and control functions, and service access. The AN will take these core policies and modify them for operations within the AN’s domain and unique operational requirements.
The AN must be able to support the policies of non-AN participants (e.g., IC, Allied Nations, NATO, etc.) who may have airborne and other networks that will need to interoperate with the AN. Support and interoperating with policies generated by non-AN sources will require establishment of an agreed approach for risk measurement, risk management and risk acceptance. The policy would also specify functionality such as U.S. access and handling rights for allied-restricted data. In most cases, the GIG core policy will addresses cross-user group handling rules requiring little modification within the AN.
The dynamic aspect of policy management allows for the rapid adjustment of these rules to meet operational scenarios that require a rapid reduction of privileges and accesses or increased latitude. These adjustments will change the criteria used to determine how resources are allocated to users and how access control decisions are made.
The AN must support conditional policies. The policy for accessing an AN asset will specify different access rules based upon the conditions that apply to this set of information. Factors such as destination system or data source, path (within the AN or from outside the AN, or routing through the AN) etc., may modify the level of trust afforded an entity within the AN ultimately modifying the level of access allowed.
5.2.2.5.1 PBSM Framework
Policy based security management requires a framework that addresses policy management from the point of policy creation to policy installation in end devices. This framework must include the ability to dynamically update AN policy in response to changing network conditions or in response to updated GIG security policies. Figure 5-3 provides an architectural framework (based upon the policy management architecture developed by the IETF Policy Framework Working Group) for performing dynamic policy management within the AN.
[pic]
Figure 5-3. Notional Policy Management Architectural Framework
Policy management begins with a pre-engineering phase in which the GIG source policy and locally developed policy or modifications to the GIG policy is validated before entering into the AN. Validated GIG and local security policies enter the AN at a policy input point as follows:
• The entity entering the policy at the input point must be authenticated and validated – the input point must determine if the entity has the proper authorizations to enter policy. The policies are coded in a high level language suitable to define policy that will be transferred to a policy promulgation point.
• The policy promulgation point performs policy deconfliction to resolve any conflicts between the GIG enterprise-wide policy, AN mission specific and community of interest policies, and the policies of non-AN entities (e.g., allied, coalition, etc.) that have access to the AN.
• The deconflicted policy is provided to a policy distribution point, which will likely be at management and configuration nodes, for inclusion in AN device configuration loads.
• The policy is distributed to a policy enforcement point -- a network or security device -- using a push or pull model. The push model will be used for policy that must take effect immediately because new behavior is needed under a particular condition. The pull model can be used in cases where a policy change is scheduled to take effect at a particular time but is not critical to current operations. Ensuring that AN entities stay synchronized with current policy is a critical aspect of policy distribution
As needed to meet network node distribution, policy promulgation, distribution, and enforcement points may be hierarchal distributed in order to support the distributed nature of the AN. It is anticipated the network and security management structures will take advantage of similar data flow and physical architectures to ensure that all AN assets are security and operationally managed.
5.2.2.5.2 Policy Protection
The AN policy management architecture will implement the security services and mechanisms necessary to protect the policy throughout its life cycle. From the point of creation to installation in the policy enforcement point, every entity handling digital policy must maintain the integrity of policy information for policy-at-rest and policy-in-transit. AN assets must maintain integrity of the source of origin for policy throughout the management infrastructure. Depending on the source and value of the policy, the AN may need to provide policy confidentiality protection.
Every entity sending or receiving policy information must be identified and authenticated. An AN entities privileges to send, receive, and modify policy as well as to send error messages to the policy promulgation point must also be validated. Other security services include the logging of all policy management transactions and the assured availability of the management infrastructure. A critical aspect of maintaining the security posture of the AN, the availability of the policy input, promulgation, distribution, and enforcement points is vital to nearly all AN functions.
5.2.2.5.3 Security Management System
TBD
5.2.2.6 Data Protection
The AN will use a variety of mechanisms to secure user and system data at rest and in transit. These mechanisms will range from the Type 1, High Assurance Internet Protocol Encryptor (HAIPE) to commercial Type 2 encryption systems, to software based mechanisms, such as the IPSec protocol described by RFC 2401. The level of security to be applied to a data object will be defined by the object’s “Quality of Protection”[3] or QoP markings. The AN Distributed Policy Based Security Management and Access Control systems will provide the enforcement mechanisms to assure the specified QoP is provided. Data, be it user data or system management data including policies, is vulnerable at two different times, when at rest stored in a form waiting to be used and when in transit between the storage facility and the user.
Data-at-rest protection will be required for some types of data (e.g., sensitive data, some policy, etc.) and for certain environments, such as information stored on a system in a hostile environment. For shared information, data-at-rest protection must be provided at the object level, where an object is defined as a file, or pieces of a file. This leads to a large range of object types each of which must be properly protected. Data-at-rest protection will be provided in a number of ways including media encryption mechanisms.
Data-in-transit protection consists of the ability to provide confidentiality, integrity, and or authentication services to the information as it is transmitted through the AN. Protection of data-in-transit includes providing traffic flow security (TFS). Traffic flow security should be provided for all high-risk links in the AN but could also be provided for medium or low risk links. In general, TFS protections include protections against network mapping and traffic analysis. In general, the lower in the protocol stack confidentiality is applied, the greater the TFS benefit. For IP networks a variety of mechanisms can be used. For IP environments where the communications links are circuit based and routers are protected, hop-by-hop link encryption can be applied to provide TFS for encrypted packet traffic. AN network traffic will be protected at the application, network, and link layers.
5.2.2.6.1 Application Layer Protection
Application layer data-in-transit security is the protection of information as it flows from one end user terminal to another, where the end user terminals apply the protection mechanisms, and the protected information is not accessible at any point during transmission. Application layer protections, implemented by user applications or other user-managed security tools, are beyond the scope of the AN. However, they can impact AN security by preventing virus checking and intrusion detection and prevention tools from inspecting the contents of the data payload.
5.2.2.6.2 Network Layer Protection
Network layer data-in-transit security is the protection of IP packets as they flow across the AN to other AN nodes or to nodes existing beyond the edge of the AN. Protection could be from enclave to enclave, or from host to host. High Assurance Internet Protocol Encryptor (HAIPE) compliant devices will be used to provide Type 1 data-in-transit network layer security.
The AN HAIPE device will be a modular, software programmable INFOSEC module designed to meet the low and high data throughput requirements necessary to support all AN users. Its modular design will facilitate its operation as a component of the AN node or as a platform LAN supporting component.
In order to support backwards compatibility with legacy communications systems, the HAIPE supporting programmable INFOSEC module (PIM) will also support operations as a bulk encryption device. Being able to program the PIM as a HAIPE device or bulk encryption device will facilitate use of AN supporting components to provide capabilities that will be matched to the mission, platforms, and communications transport needs. Figure 5-4 provides a notional, block diagram view of the components that may comprise an AN node supporting terminal. Key to Figure 5-xx components is their flexibility – they are designed to support straight through connectivity or bypassing and are designed around a function agnostic switching fabric. This will allow a module to be programmed as a switch, router, or other network component as required to meet mission needs.
[pic]
Figure 5-4. Notional AN Supporting Terminal Block Diagram
5.2.2.6.3 Link Layer Protection
As an RF based network, the AN will need to provide protection against a number of threats, such as jamming, not found in wired networks. IP networking link layer protection will be provided by Transmission Security (TRANSEC) mechanisms. TRANSEC implemented link layer security provides the following protection and functions:
• Anti-Jam (A/J) protection
• Low Probability of Interception/Detection (LPI/LPD) protection
• Traffic Flow Security (TFS) and Traffic Analysis Protection (Note, the HAIPE device provides IP network layer TFS protection)
• Signals analysis protection
• Protocol and header cover/packet masking
• TRANSEC isolation for major sets of users (If connecting to TSAT, AN supporting TRANSEC will need to meet TSAT TRANSEC user group separation requirements.)
TRANSEC will be implemented in a stand-alone, embedded, modular programmable INFOSEC device that will operate at the data rates and crypto algorithms necessary to support user needs.
5.2.2.7 Key Management
Key management is one of the fundamental aspects of Information Assurance. Key management includes the following elements/attributes:
• Key Management Plan – a document that describes the process of handling and controlling cryptographic keys and related material (such as initialization values) during their life cycle in a cryptographic system, including ordering, generating, distributing, storing, loading, escrowing, archiving, auditing, and destroying the material.
• Algorithm Flexibility – the capability to support a variety of cryptographic algorithms and systems, of varying strengths and types, and to change algorithms when appropriate to meet new interoperability or mission requirements.
• Coalition Interoperability – the capability of interoperating with cryptographic systems used by coalition partners while simultaneously providing a high assurance U.S.-only capability.
• Authorized Key Sources – keys can be either locally generated or provided by a central authority which is source and integrity validated.
• Trusted Key Storage – keys must be stored securely on an End Cryptographic Unit (ECU) such that it cannot be extracted in a useful way by an attacker (including attackers’ software agents), and it cannot be modified in an unauthorized way without detection.
• Key compromise recovery mechanisms – the capability to identify all ECUs impacted by a key compromise and ensure the rapid recovery of operations.
• Key destruction mechanisms – the capability of “destroying” keys when required by circumstances.
Key Management Architecture (KMA)
The AN KMA will consist of the following elements:
• AN Network Operations Center (NOC) (i.e., terrestrial management facility or network service provider)
• AN Nodes and Terminals
• Key Loading and Initialization Facility (KLIF)
• National Security Agency (NSA) KMI/EKMS
• TBD
The AN key management infrastructure must be capable of operating for extended periods of time without connectivity or support from the. Therefore, a closed system for supporting the key material requirements of the AN elements will be needed, rather than an open system where the elements could interact directly with the NSA KMI/EKMS for all key materials. The AN NOC will be the primary interface to the NSA KMI/EKMS for key material. The NOC is expected to support and supply keying material to all other elements of the AN as well as supporting all crypto planning functions, compromise recovery functions and support the controlling authority. Prior to performing any key management services, the identity of the node or component must be ascertained using a robust method such as a PK-based digital signature. Benign key distribution techniques must be used to ensure that RED keys are accessible only to the end-device.
Where possible, and in any newly developed cryptographic devices, the use of asymmetric (public) keys should be used in favor of symmetric keys. Asymmetric keys have inherent properties that make them more secure than symmetric keys.[4] The AN network must support in-band benign keying and rekeying of AN node and component public key certificates. Also, with the emergence of multi-channel, software programmable communications systems, it may be advantageous to distribute all keys for a given system as part of the system’s configuration file essentially delivering initial key material outside the key distribution system.
TRANSEC for RF links will continue to require the use of symmetric keys. The AN must support the benign distribution of these keys to the node in support of the appropriate user group, protect these keys while resident in the equipment through robust anti-tamper and provide timely compromise recovery.
The AN NOC will also:
• Report key compromises to KMI
• Report public key certificate revocations back to the PKI.
• Control of the PCFs
• Authenticate terminals/users/networks
• Download/upload mandatory software
• Maintain ECU inventory records
• Manage ECU (inventory, configuration, user data, key and policy)
• Manage the security configuration of AN resources
• Audit and ASWR
• Manage security policies
• Manage user groups
5.2.2.8 Authentication System
Authentication establishes the validity of a claimed identity and Access Control is the prevention of unauthorized use of the system’s resources. Robust Authentication and Access Control is especially important to the AN to ensure that the given user/device has been provided appropriate access to the AN’s resources.
Authentication applies to all of the information flows as follows:
• User Information Flows: Required in order to establish/maintain the logical separation of COIs.
• Network Management Flows: Required to avoid spoofing by a potential adversary.
• Network Control Flows: Required to insure the integrity of network operations and to enable proper management/control.
• Policy Control Flows: Required to insure proper maintenance and separation of the COIs.
Access to and use of the system will be restricted to known verified users. Factors that may be used in the authentication process include Biometrics, cryptographic tokens, and integrated Public Key Infrastructure etc. Multiple factors will be required to ensure that only users with known, verified identity are allowed access.
Network management information flows must include a minimum of two factor authentication features. Configuration files, routing tables, and software updates must have robust authentication to assure management by only the control center.
Network control systems must be protected by rigorous physical and personnel security methods. Robust and, at a minimum two-factor authentication, including PKI and biometrics must be used to improve the security of network control transactions.
5.2.2.9 ASWR
The AN will provide host and network based Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), and Virus Detection, Prevention, and Removal applications. Larger AN nodes, such as the Network Service Provider and Internetwork nodes, will support full IDS, IPS, or virus applications and detect and respond to anomalous network traffic. Less capable nodes, such as Network Access and Network Capable nodes, will employ agents that monitor network traffic for anomalous behavior sending data back to an aggregation point and then responding to the central services instructions.
Transient encrypted user data will not be tested for anomalous content as the node will not have the keys or requirement to unwrap the packet for inspection.
The AN will support plain text (red side) IDS, IPS, and virus capabilities. However, platforms with organic IDS and/or IPS capability may request the AN node to pass their plain text data directly to their processes.
The AN node is responsible to monitor the AN management and control path for anomalous network behavior and virus infected code taking action based on the current policy.
ASWR process and sensor collected data will be sent to network management aggregation points. The network management nodes will analyze the data to determine if detected anomalous behaviors are localized to a few nodes or occurring network wide. Processed and aggregated data will be forwarded to GIG network operations centers. Dependent on the analysis results, network security and operations policy will be generated and distributed throughout the network modifying IDS, firewall, and other security component behavior, to minimize anomalous behavior impact.
The AN will employ reactive IDS and migrate to IPS as intrusion detection systems and software technology matures.
5.2.2.9.1 Network Intrusion Detection System
The Intrusion Detection System (IDS) defends system components against threat actions carried by network data traffic. The AN will use a combination of host based and network based IDS processes. Host-based IDS components -- traffic sensors and analyzers – will run directly on one or more of the hosts they are designed to protect. Network-based IDS sensors will be placed on subnetwork components, and associated analysis components run either on subnetwork processors or other, more powerful, hosts.
The IDS will be configured using GIG provided attack signatures that will be delivered with the AN Node configuration files. Updated attack signatures that result from local detection of previously unknown attacks or is received from the GIG will be delivered using security policy updates or via an updated configuration file.
The IDS will evolve to become the Intrusion Prevention System (IPS.) The IPS hardware and software detects and prevents known attacks. It will employ methods such as heuristic, anomaly checking, or signature based filtering to detect the attack. Intrusion prevention is specifically targeted at detecting and then preventing publicly known yet stealthy application-specific attacks. Intrusion prevention blocks malicious actions using multiple algorithms and will provide blocking capabilities that include (plus go beyond) signature-based blocking of known attacks.
The AN IDS and IPS processes will locally log and report back to the AN NOC detection and any remediation results. The NOC will use the information to modify network security policy. In addition, the NOC will aggregate the information and report it back to the appropriate GIG network operations center.
5.2.2.9.2 Virus Detection, Prevention, and Removal
The AN virus detection, prevention, and removal implementation will employ signature matching, code enumeration, and checksum comparison to detect virus infected code or data.[5] Once detected, and dependent on the security and operations policy in place, the virus checking application may attempt to remove or “fix” the data file or it may alert the operator or it may quarantine the file for later action. The virus checking application is only effective when applied to plain text data. Because of this and the need to provide a defense in depth capability, hosts on platform LANs should also implement their own local virus checking applications.
The AN virus detection and remediation processes will locally log and report back to the AN NOC detection and remediation results. The NOC will use the information to modify network security policy. In addition, the NOC will aggregate the information and report it back to the appropriate GIG network operations center.
5.2.2.9.3 Vulnerability Assessment System (VAS)
TBD
5.2.2.10 Protocol Security
The routing, transport, management, and other protocols used to enable the AN must be secured. At a minimum, protocol security will include origin validation, integrity, confidentiality, and mutual authentication between endpoints. Dependent on the sensitivity of the protocol’s data, that security may require use of Type 1 or Type 3 encryption techniques.
Many of the standards based protocols do not organically provide for the level of security required by the AN or else have security implementations that will cause excessive overhead if employed in the AN. These shortfalls must be remediated by extending current specifications or generation of replacement specifications that are optimized for use in the wideband, wireless domain.
5.2.2.11 Other Security Functions
5.2.2.11.1 Firewalls
TBD
5.2.2.11.2 Guards – Cross Domain Solutions
TBD
5.2.2.11.3 Covert channels
TBD
5.2.2.12 Security Modeling and Simulation
TBD
5.2.3 Network Management
The Airborne Network will be characterized by dynamic network topologies and bandwidth-constrained, variable quality links. Due to the special challenges posed by these features, it will be impractical to apply the same network management (NM) methods used in terrestrial networks to the Airborne Network. Two significant architectural challenges must be addressed: (1) enabling the NM capability to adapt to dynamic topology changes; and (2), developing efficiency enhancements to minimize management overhead over bandwidth constrained, variable quality links.
The NM architecture for terrestrial networks is typically a centralized or hierarchical structure in which the relationship between the manager(s) and managed nodes changes very infrequently. The Airborne Network, however, will self-form, and undergo dynamic topology changes. Nodes may enter and leave the network, subnets may partition from the main network, separate subnets may merge to create a larger network, etc. As such, reliance upon static management relationships between nodes, and the assumption of a static topology, cannot be applied to the management architecture of the Airborne Network.
The Airborne Network will also be confronted by significant efficiency demands. In general, maintaining network robustness when the majority of the network nodes are mobile will require a higher degree of maintenance overhead when compared to static terrestrial networks. Yet Airborne Network links will be bandwidth limited, and of variable quality; the dynamic nature of highly mobile airborne platforms will result in occasions of link outages and degraded link quality. These constraints make it critical that the network management function be not only efficient, but also balance the “cost” of its transactions against the benefit that would result from conducting the transactions.
5.2.3.1 Cluster-Based Management Architecture
To address these challenges, a cluster-based management architecture is needed. A cluster-based management architecture groups individual nodes into clusters that are managed by a cluster manager. The cluster managers are in turn managed by a network manager. The main concept behind cluster management is to convert a traditionally centralized process into a semi-distributed process to address the challenges posed by mobile networking (i.e., a dynamic topology and enhanced NM efficiency). The major components of the architecture include a Network Manager, Cluster Managers, and Intelligent NM Agents.
5.2.3.1.1 Network Manager
The Network Manager executes management applications that monitor and control the managed elements – i.e., the subordinate cluster managers. Location options for the Network Manager include an air-based or ground-based node. Based on the tenet that the Airborne Network management solution scale across the variety of operational configurations (including autonomous operations disconnected from GIG enterprise services), it is assumed that the Network Manager will typically be air-based. It should be noted that a ground-based manager is not precluded in this architecture; in certain instances, a ground-based manager may be advantageous given the benefits of collocation within terrestrial centers of C2. However, to enable the desired management efficiency and autonomy features, the architecture will assume capabilities of an air-based manager. A required feature of an airborne Network Manager is its ability to transition management responsibilities to another node if the hosting platform leaves the network, or is no longer able to serve as the Network Manager. As such, a fail-over and hand-off function is required of the manager.
Figure 5-5. Cluster Based Management Framework
5.2.3.1.2 Cluster Managers
Cluster Managers are selected dynamically as the network forms. The performance objective in selection of clusters is to minimize protocol overhead between the node and manager, while maximizing management service availability over a dynamic topology. As Cluster Managers are selected, local NM/PBNM services are instantiated within them. These intermediate managers then take responsibility for local NM and policy dissemination functions in accordance with the policies of Network Manager. Cluster Managers act as proxies to aggregate and filter information -- based on cost-benefit examination -- from the cluster’s nodes to the Network Manager. Likewise, Cluster Managers receive NM and policy directives from the Network Manager and disseminate as appropriate to constituent cluster nodes.
When acting as elements of a larger network, the Cluster Managers may collaborate among themselves to adapt to the changing topology. New Cluster Managers may be designated as subnets partition. As partitions merge, Cluster Managers may collaborate to determine who will serve the role of Cluster Manager of the larger network. Thus, the maintenance of Cluster Managers is dynamic to adapt to the topology changes of network.
Cluster Managers enable clusters to operate autonomously while disconnected from the Network Manager due to network partitioning, loss of links to the Network Manager, etc. Because the Cluster Manager maintains the cluster’s topology, health, and status information locally, this information will be available to the Network Manager upon reconnection of the cluster to the network. Thus, a dynamic and distributed management structure, rather than a centralized static structure, is applied to adapt to the dynamic topology of the Airborne Network.
5.2.3.1.3 Intelligent NM Agents
Imparting local intelligence within the managed elements enables the nodes to conduct localized and autonomous collection, aggregation, analysis, and problem resolution -- thus reducing the management overhead that occurs in centralized architectures with “dumb” agents. Intelligent NM Agents conduct cost-benefit assessments for interacting with the Cluster Managers – taking into account the link’s available bandwidth, the node’s Emission Control (EMCON) state, the importance and timeliness of event reporting, etc.
5.2.3.2 Policy Based Management Framework
The IETF Policy Framework Working Group has developed a policy management architecture that is considered the best approach for policy management on the Internet. It includes the following components:
• Policy Server – A graphical user interface for specifying, editing, and administering policy.
• Policy Repository – A device used to store and retrieve policy information.
• PDP (policy decision point) – A resource manager or policy server that is responsible for handling events and making decisions based on those events and updating the PEP configuration appropriately.
• PEP (policy enforcement point) – Network devices such as routers, firewalls, radios, and hosts that enforce the policies received from the PDP.
• LPDP (local policy decision point) – Scaled-down PDP used when a policy server is not available.
In addition to the Policy Server/PDP and PEPs, an intermediate set of elements, termed cluster PDPs, will be needed within the airborne management architecture to accommodate efficiency and autonomy requirements.
In most implementations of the framework, the Policy Server, Policy Repository, and PDP are collocated and may potentially be hosted within the same physical device. The discussion of the framework below assumes this consolidation of system components.
In the framework, a ground-based resource planner would formulate high-level airborne networking policies -- that is, formulation of the relatively static, high-level specifications of the desired behavior of flows. These sets of high-level policies would be downloaded into the Policy Server/Repository/PDP. The Policy Server/Repository/PDP is responsible for distributing policies to the intermediary PDPs. There are two approaches for distributing policy: outsourcing, and delegated provisioning. In outsourcing, all policy decisions are conducted at the PDP. In delegated provisioning, policy directives may be defined in broader terms, with flexibility for local policy interpretation based on local events and conditions. The accompanying figure illustrates a hybrid solution for policy distribution. The outsourcing model (as reflected by the blue lines) is applied to maintain explicit control of particular PEPs. The provisioning model (as reflected by red lines) is recommended at cluster PDPs to minimize signaling overhead and enable the adaptation features required in policy enforcement to accommodate a dynamic topology. Policy managed services may include quality of service, traffic engineering features, and security attributes. Each service would employ a common set of policies, called a Policy Information Base (PIB).
[pic]
Figure 5-6. Policy Based Network Management Framework
PBNM Overlay
The policy network management framework outlined above may be overlaid onto the cluster-based management architecture. As shown in the figure below, cluster managers are provisioned to act as intermediary (Local) Policy Decision Points (LPDP), interpreting and distributing policies from the Policy server/PDP to their cluster nodes (Cluster PEPs). Because each cluster manager acts as a local PDP for its cluster PEPs, the node is imparted with a degree of self-sufficiency required in semi-autonomous cluster operations.
Figure 5-7. Cluster Based Management Framework with PBNM Overlay
Modeling, Analysis, and Simulation tools would take policies formulated from the Resource Planner -- and policy accounting statistics from the Policy Server/ Repository/PDP -- to evaluate the performance of current policies, and provide a facility to conduct “what if” scenarios to formulate improved and/or adjusted policies. These functions would be conducted at a ground based node.
5.2.3.3 Network Management System Components
The general system components for conducting NM across the AN is reflected in Figure 5-x. This particular diagram depicts the notional placement of those system components within the platform AN Equipment and On-Board Infrastructure. In today’s Internet, management interoperability is accomplished using TCP/IP for communications protocols, SNMP for a management protocol, and a standard management information base for managing these protocols (MIB-II). In a similar fashion, the objective AN will require an analogous set of communications protocols, management protocol, and the corresponding MIBs.
Every AN managed device will implement an Intelligent Agent (IA). The IA will execute the client-level portion of FCAPS functions for the AN, maintaining the fault, configuration, performance, and security attributes of the device. In platforms with multiple managed devices, a “master” IA will proxy and aggregate information across the “slave” IAs, compiling summary reports to the Cluster Manager. The IA is focused on minimizing unnecessary management overhead across bandwidth-constrained AN links. As such, the master IA will apply a high degree of “intelligence” to conduct localized and autonomous collection, aggregation, analysis, and problem resolution functions concerning the platform’s managed objects. The master IA acts as a proxy to aggregate and filter information -- based on cost-benefit examination -- from the platform’s managed devices to the Cluster Manager. A MIB specifically tailored to these features (IA MIB) will support Intelligent Agent functionality. In platforms with a single managed device, the IA will act in a combined master/slave role. In platforms with an on-board infrastructure and local network manager, the IA can provide an HMI by “piggy-backing” on the local platform NM process. This HMI will present local health and status of the platform’s managed devices.
All nodes that are “Network Capable” will implement Cluster Manager functions. The Cluster Manager is the crucial component in adapting the NM architecture to nodal mobility and topology changes. The Cluster Manager is an application process that is invoked autonomously and dynamically via participation within server election and hand-over protocols. When invoked, the CM process assumes the mid-level management role in FCAPS functions, distributing control and configuration commands to IAs in accordance with the policy and provisioned directives of the Network Manager (NM). Likewise, the CM aggregates IA summary reports of fault, configuration, performance and security data and forwards them to the NM. To enable management over the dynamic network, these processes conduct (or leverage) a clustering protocol that adapts the regional management function to the local topology changes. An affiliated CM MIB is accessed by these processes and provides the required database for conducting cluster management.
Internetwork nodes and Network Service Provider nodes will implement a Network Manager application process. This application layer process manages the airborne network as a whole, via provisioning of commands to managed devices via the elected cluster managers. The NM application accesses an affiliated MIB data base (NM MIB). The HMI for this function is hosted by the on-board infrastructure, and provides top-level Network FCAPS and Network SA.
[pic]
Figure 5-8. Network Management System Components
Figure 5-9. Network Management System Components: Relationships and Activities
5.2.4 Link Management
5.2.4.1 Link Management Architecture
A Link Management (LM) architecture that accommodates the characteristics and challenges of the AN consists of employing multiple managers each responsible for a subset of the total nodes that constitute the AN. This architecture will allow the LM system to function in a modular decentralized fashion that promotes efficiency as well as adaptability.
The LM architecture components consist of a high level LM Executive, LM Autonomous Managers, and Intelligent LM Agents. Figure 5-10 shows the overall architecture.
[pic]
Figure 5-10. LM Architecture
LM Executive
The purpose of LM Executive (LME) is to maintain status of the entire AN, and if necessary, control subordinate LM Autonomous Managers. The LME monitors and evaluates the AN overall topology by interfacing with LM Autonomous Managers (LMAMs). The LME identifies any specific actions to be taken to alter the network topology when needed and executes them by controlling/overriding the LMAMs. The LME also prepares summary reports of LM information pertaining to the entire AN.
LM Autonomous Managers
Each LM Autonomous Manager monitors and controls a subset of the total nodes (and associated links) that constitute the AN. As described above, the LM Executive monitors and controls these subordinate managers. In addition, each autonomous manager can exchange information with other autonomous managers to accomplish operations involving more than one LM subnetwork.
The LM Autonomous Manager (LMAM) determines how the nodes of the subnetwork will be interconnected, performs admission control for each node, and provisions the needed link resources. The LMAM also monitors its LM subnetwork (nodes and links) and determines whether or not the current topology needs to be altered to accommodate any changes such as link or component failures or changes to the subnetwork participants. When necessary, the LMAM identifies the specific actions to be taken to alter the network topology and commands the corresponding LM Agent to perform these actions on the target link. In addition, the LMAM recognizes the conditions requiring hand-offs between nodes and will enable these hand-offs to be performed seamlessly.
Intelligent LM Agents
An LM Agent (LMA) advertises the identity and location of its node and identifies, authenticates, locates and determines the role of AN nodes from which it receives advertisements. This information is used by the topology establishment and adaptation functions in the corresponding LMAM. The LMA also determines the operational state of the resident network components and links and the network performance being achieved. Under the direction of an LMAM, the LMA changes the value of network and link parameters when necessary to modify the performance of any link.
5.2.4.2 Link Management System Components
AN Link Management system components are depicted in Figure 5-11.
[pic]
Figure 5-11. LM System Components
5.2.5 Network Services
5.2.5.1 Overview
Network services refer to the services necessary for the effective access to and utilization of the network’s communications transport service. Examples include name resolution, dynamic host configuration (including dynamic address configuration), security authentication services, policy services for network admission, etc). These network services may be accessed by hosts or applications.
Since the AN must be capable of self-forming and self-adapting with nodes dynamically joining or exiting the network, the network services architecture must be either: (1) impervious to these dynamics, able to supply the desired services despite the dynamic changes of the network; or (2) capable of adapting to these changes to provide the desired services. Also, when the AN must operate autonomously, without connectivity to ground nodes, the network services must be provided from airborne locations. Finally, the network service overhead traffic needs to be minimized over the bandwidth-constrained, variable quality links of the AN.
For dynamic networks, if every network service (e.g., name resolution, address configuration) as well as, Network Management and Link Management conducts its own service transactions separately and independently of the other services, it could create an environment in which the service overhead traffic saturates the capacity of the network links. This condition and the above factors dictate the need for a distributed network services architecture with common approaches used to deliver the different services.
Options for distributed architectures range in the “level of distribution” delivered: from (1) partitioning of the network into regional clusters, in which cluster heads provide services to a network region or “cluster”; to (2), complete distribution, in which every node can render the service.
Delivering network services with a distributed service architecture across a dynamic network will require that a number of service maintenance functions be performed. These service maintenance functions include server election, service discovery, service advertisement, and the need to maintain regional clusters through which to deliver services. Rather than forming separate, independent architectures – with each service employing its own physical architecture and corresponding maintenance transactions – a unified, common architecture for AN Network Services is established to achieve efficiency gains across the AN. In this architecture, cluster maintenance is conducted as a single process for all network services. Additionally, servers of the various services are collocated such that functions such as service election, discovery, advertisement, and other common service maintenance operations can be conducted on a common basis, rather than once per independent service. This enforces a single physical services architecture. (Another opportunity for leveraging commonality may be exploited by “piggy backing” upon functional facilities provided by other lower-layer processes, such ad hoc routing maintenance transactions.)
The basic functionality of these service maintenance functions are described below:
Server Election
One of the attributes of a distributed architecture that supports dynamic networking is the ability of multiple (and in some cases, all) nodes to act in the capacity of “a server”. As a network self-forms, nodes that can act as a server are elected (or selected), and take on the server capability. To minimize potential performance impacts in highly dynamic networks, this process could include election of primary and backup servers. If a node leaves or becomes inoperable, an election process ensues to select a new server. If two subnets, previously disconnected and employing their own server merge, the election/selection process reconciles the redundancy.
Service Advertisement
Once nodes have been elected to act as servers, an advertisement feature is often employed to announce that it is acting in the server capacity. This announcement is conducted periodically, or on an event-oriented basis. Minimizing service advertisement overhead is a critical need for constrained-bandwidth networks; as such, various features may be employed, including constraining the broadcast announcement to n-hops (i.e., a cluster), using multicasts rather than broadcasts, and enacting the announcement only upon trap-driven events, etc.
Service Discovery
A feature that often complements, and works in concert with the service advertisement function, is the service discovery function. This is employed by nodes which are in search of a server, such as those that have recently joined the network and need immediate service. Again, minimizing overhead is a critical need for constrained-bandwidth networks; the same approaches to mitigate overhead for service announcement may also be employed within this function.
Cluster Maintenance
A clustering approach to distributed architectures groups individual nodes into clusters that are serviced by a cluster server. The main concept behind clustering is to convert a traditionally centralized process into a semi-distributed process that adapts to dynamic network challenges. The performance objective in selection of clusters is to minimize protocol overhead between client and server while maximizing service availability. To do this, clusters maintenance protocols optimize the cluster attributes to adapt to the dynamics of the network. Clusters that are too large suffer from an excess of client-server transaction traffic, while clusters that are too small suffer from an excess of cluster maintenance overhead. Additional factors that impact cluster maintenance include, among others, relative node speed, cluster density, mobility characteristics, etc.
5.2.5.2 Name Resolution Service
A name resolving service (or naming service) translates the name of a resource to its physical IP address. A name resolving service also uses reverse mapping to translate the physical IP address to the name of the resource. Application of the current terrestrial-based Domain Name System (DNS) to the AN is impractical due to its reliance upon dedicated, fixed, terrestrial-based name servers. Since the AN must be able to operate disconnected from the terrestrial GIG infrastructure, an airborne-based naming service is needed that is self-sufficient and autonomous, while at the same time backwards compatible and interoperable with terrestrial-based services DNS services. The naming service must also be adaptive to AN dynamics -- name-providing nodes may leave the network, become disconnected due to topology partitioning, or go into EMCON mode. Finally, the AN naming service must also be efficient in the face of bandwidth-constrained, variable quality AN links.
5.2.5.2.1 Naming Service Features
Interoperability and compatibility with GIG-based name services
The AN name resolution architecture will accommodate both airborne- and GIG-based name resolution. The architecture should leverage terrestrial GIG-based name resolution services when appropriate. However, in instances in which GIG-based services are infeasible, unavailable, or impractical -- (e.g., due to disconnected operations, high-cost ground-air links, etc.) -- the architecture will provide a self-sufficient, air-based name resolution capability. The air-based capability will be backwards compatible and interoperable with GIG-based services, to allow zone transfers/updates and airborne-based caches of GIG-based authoritative zone information.
Autonomous Name Registration
The AN air-based name resolution service will require an autonomous name registration process to discover and formulate a knowledge base of the existing names.
Self Configuration and Service Advertisement/Discovery
The AN air-based name resolution service will require a distributed naming architecture with self-configuration, autonomous server election, and service advertisement/discovery capabilities to support the spontaneous, self-forming features of the AN. An autonomous name registration capability will provide self-configuration of zone data and supporting resource records upon which naming services are based. After self-configuration of resource records, an autonomous server election process will occur to select naming capable nodes. A service advertisement/discovery processes will then enable nodes that can provide naming services to announce themselves. Other nodes seeking name resolution services will employ a server discovery process to locate appropriate name servers. Thus, a distributed naming architecture is formed such that airborne nodes do not have to rely on fixed, dedicated name servers.
Distributed Architecture for Adaptation to Network Dynamics
Continuous self-configuration and autonomous advertisement/discovery processes provide continuous service adaptation to dynamic topology changes. Additionally, these distributed services provide built-in redundancy and fail-over features to accommodate loss of primary service-providing nodes and/or their supporting links.
Scalability
The architecture must scale across the range of operational AN scenarios – i.e., from a small cluster of nodes disconnected from the GIG to a theater-wide deployment of AN assets.
Efficiency
The AN will provide efficient discovery of the naming service across the bandwidth-constrained, variable quality links of the dynamic AN topology. The discovery apparatus must be efficient and optimized to the current state of the dynamically changing network. Efficiency options include use of multicast and/or constrained (hop-limited) broadcasts. The AN name resolution architecture will conduct efficient name-resolution transactions. In GIG-connected operations, the naming service will evaluate when it is more efficient (or more expedient) to conduct name resolution via GIG-based services, rather than via AN-based services, and vice-versa.
5.2.5.2.2 Naming Service Architecture
The AN name service architecture will consist of a distributed airborne-based naming system, with gateways to provide access, interoperability, and backwards compatibility to terrestrial-based GIG DNS services. Autonomous features (such as name registration, name server election, and name server discovery) will be supported by protocols to minimize overhead and efficiently use bandwidth-constrained AN links, such localized multicast and/or constrained (hop-limited) broadcast transactions.
5.2.5.3 Dynamic Network Configuration Management
The AN will automatically configure and reconfigured as nodes join, depart, and move from one subnet to another. Providing a network-wide reconfiguration capability will require accurate current knowledge of the entire network structure. The AN dynamic network configuration management system will collect node configuration and capability data. This network configuration data will be stored in a repository and distributed to each of the AN subnetworks. Within a subnetwork, the AN dynamic network configuration management system will dynamically assign and distribute IP addresses, subnet mask, domain name for any network interface and distribute (and update) addresses of network servers (e.g., Name Resolution Server, Network Time Server, Network Policy Server, QoS Manager, Security Manager, Network Manager, Link Manager). The AN dynamic network configuration management system will also distribute other network configuration information (e.g., routing protocols and configuration). Figure 5-12 depicts the major functional components of the AN dynamic network configuration management system.
Figure 5-12. Dynamic Network Configuration Management Functional Components
5.2.5.4 Network Time Service
The AN Network Time Service will enable the synchronization of all AN network devices, as well as the synchronization with external time sources. Time provided by the AN Network Time Service will be traceable to the Coordinated Universal Time (UTC), an international standard, based upon atomic timekeeping coordinated between the U.S. Naval Observatory (USNO), the National Institute of Standards and Technology (NIST) and 25 other countries. Each AN node will include a Network Time Server (NTS) synchronized with the UTC (when able to connect to a UTC or Intermediate node) to provide synchronized time distribution within the AN node. The AN NTS will be fully integrated into the GIG UTC, Intermediate, and Client Node Network Time Service architecture [per the Network Time Service Profile]. Each AN node will include:
• An NTS capable of being synchronized with UTC using one of the following as primary and at least one other as secondary:
o Network Time Distribution (e.g., Network Time Protocol) – USNO and NIST provide precise (±30 ms) time synchronization services over the network using the Network Time Protocol (NTP). Since NTP uncertainty is heavily based upon network latencies, in reliable, high bandwidth, low latency networks, the uncertainty factor can be reduced to µs or ns precision.
o Global Positioning System (GPS) using redundant antennas – GPS is a highly precise (±200 or ±340 ns) method of time synchronization. GPS satellites employ redundant atomic clocks synchronized with USNO to ensure precise timing and availability. The GPS Standard Positioning System (SPS) provides time accuracies to within 340 ns for most non-military applications. The Precise Positioning System (PPS) provides time accuracies to within 200 ns for military applications.
o Two-Way Satellite Time Transfer (TWSTT) – TWSTT is the most accurate method of delivering time to a node. A dedicated satellite connection to USNO is established to provide highly precise (±1 ns) synchronization.
• The ability to synchronize the NTS with the NTS of any peer AN nodes to achieve locally coordinated time.
• A backup clock providing at least the accuracy of a rubidium clock configured as a failover device in case of a disconnected or degraded state.
Within each AN node, time will be distributed to supported network devices and hosts, using the Network Time Protocol.
5.3 Off-Board Transmission Systems
As a minimum, the Off-Board Transmission Systems provide the physical and data link layer capabilities used to create the backbone, subnet and network access links of the Airborne Network. Off-Board Transmission Systems components include radios (i.e., RF/optical and modem subsystems), multiplexers, and transmission security (TRANSEC) equipment used for the transport of all information onto and off of the platform. Off-Board Transmission Systems must be capable of interfacing to and interoperating with the AN Equipment system components. As such it must be capable of being managed by the AN Network Management System and Link Management System. Furthermore, the Off-Board Transmission Systems components must be capable of implementing QoS mechanisms that enable the required end-to-end services to be provided when used in conjunction with the AN Equipment.
Multiple transmission systems may be implemented on some platforms to accommodate various communications needs. The physical and data link layer capabilities of each of these transmission systems may be very different, each optimized for different needs such as high bandwidth, beyond line of sight connectivity, high mobility, or low probability of detection. However, the Off-Board Transmission Systems must provide a common interface to the AN Equipment network components to enable interoperability between these different systems. Note, some of the network functionality may actually be implemented as part of a transmission system component (e.g., radio or terminal), but the network functions must be separable to accommodate network functions implemented on the platform and to facilitate implementation of different network configurations. Legacy transmission systems will interface to the AN Equipment through gateways as described in section 5.1.
[pic]
Figure 5-13. Off-Board Transmission Functional Representation
6. GIG Integration and Interoperability
The future Global Information Grid (GIG) will provide an end-to-end, seamless, internet-like communications capability that meets the mobility, security, and reliability needs of the DoD for mobile and fixed ground-based, air-based, and space-based assets. The communications traffic will be comprised of a combination of voice, video, and data, across multiple security levels using an unclassified (black) transport layer.
The GIG transport network will be comprised of a number of component networks, including the Airborne Network, as depicted in Figure 6-1. Each component network will need to pass data both internally among its network members and externally to/from other GIG component networks. Achieving the end-to-end functionality required by the GIG will necessitate that the Airborne Network interface and interoperate with other GIG component networks and with the GIG Enterprise Services (GIG ES).
[pic]
Figure 6-1. Major GIG Component Networks
6.1 GIG Operational Mission Concepts
The following GIG operational mission concepts define the target functionality of the integrated GIG transport network which must be provided by the GIG component networks, including the AN.
6.1.1 Provide Common Services
GIG information, service applications, transport capabilities and management features are focused toward providing the user with the resources needed to successfully complete any mission, anytime, anywhere. This focus is best evident in the shift from the existing centralized Task, Process, Exploit, and Disseminate (TPED) operational concept of providing information from producers to consumers based on a “need-to-know” sharing model to a net-centric Task, Post, Process, and Use (TPPU) “need-to-share” paradigm in which information is posted to the GIG allowing all users of the GIG (and subsequently the AN) to discover and use information. The primary emphasis of TPPU is to get the right information to the user as quickly as possible to impact the decision making process. Users across the enterprise must be able to discover the existence, and location, of needed information, retrieve it in a timely manner, process it as required and post the resulting “value added” product for sharing with the community.
6.1.2 Provide Worldwide Access
GIG users will be able to access GIG information and services from anywhere in the world. This includes access from both fixed and mobile locations as well as access in both wired and wireless environments. The GIG will provide ubiquitous login that enables users to identify/authenticate themselves and their current role/context to the network, to GIG services, and for information access from any supported physical location. Once a user has been authenticated and is granted access, the GIG infrastructure will institute and maintain network connectivity, employing a variety of communication and usage modes to provide near real-time access to information and services (e.g., survival information, “task” requests, “post” or “use” services, collaboration via multimedia) at all security levels. Assuring on-demand connectivity, the GIG will be able to dynamically route traffic as needed to achieve mission needs in all environments (i.e., fixed, mobile, wired and wireless connections).
6.1.3 Provide Dynamic Resource Allocation
The GIG will support simultaneous, multiple, global missions. The GIG communications and computing resources, while large, are still limited and these resources must be dynamically allocated to provide optimal support to the many varied mission objectives that are constantly evolving and changing in priority. The GIG must have the ability to establish and manage critical characteristics of all resources needed by a GIG user/entity including priority/ precedence level, QoS and CoS levels (e.g., guaranteed or expedited delivery options), and computing resources (e.g., bandwidth, storage, processing). Ensuring efficient and flexible use of GIG resources will require the convergence of voice, data, and video onto a single network. Additionally, the mobile and dynamically changing tactical environment will require users/entities to connect/re-connect to GIG throughout a communication session to react to changes in the communications infrastructure topology. The GIG will need the ability to identify a user/entity as a GIG entity and dynamically establish the user’s device(s) connectivity, resources, and privileges.
6.1.4 Provide Dynamic Group Formation
GIG information will need to be shared among users/entities with varying levels of privilege and trust in order to carry out specific missions. Communities of Interest (COI) will allow groups of users with common information needs to access, and control access to, the information they need to carry out a specific task. Users and entities will need to be able to be members of multiple COIs under either a periods processing or simultaneous access model (e.g., participating in a U.S.-only COI, a Coalition COI, and a bilateral COI with a Coalition partner nation in execution of a mission). The scope of COI group formation includes dynamic allocation of communications and computing resources as well as dynamic access to enterprise services. COIs may be established and disestablished dynamically, to meet changing missions, or remain fixed to support on-going tasks. The COI construct is envisioned as the main mechanism for enabling coalition partners to use the GIG as needed, without having their access jeopardize the availability of the GIG. When only small numbers of coalition partners need to participate, GIG identities could be issued to them temporarily.
6.1.5 Provide Computer Network Defense (CND)
The GIG will provide a proactive and reactive capability for computer network defense. The GIG will protect, monitor, detect, analyze and adaptively respond to unauthorized system and network activities. Authorized managers and users of the GIG will have the ability (based upon their user profile and privileges) to receive near real-time situational awareness of current threats, configuration, status, and performance of the GIG communications and computing resources. This CND situational awareness will be provided via monitoring of the GIG to obtain sensor data, detection of anomalies within that sensor data, and analysis of those anomalies to provide defensive courses of action. All of these defensive capabilities (i.e., monitoring, detection, and analysis) combine to support CND situational awareness, which enables CND response actions. AN CND situational awareness will be a user defined operational picture (UDOP) of the AN cyberspace at the various organizational levels. Automated situational views will be enabled through user- defined subscription of sensor data, which is combined with appropriate analytical tools that produce awareness, knowledge, and defensive courses of action.
6.1.6 Provide Management and Control of GIG Network and Resources
The GIG will support the ability to remotely manage and control all GIG communications, computing resources and services. The common management and control capability of the GIG includes the generation, collection and/or distribution of resource, access, audit, status, performance, fault, configuration, and inventory data to support the auditing/supervisory functions required for network management, security management, and CND operations. It also includes the management and control of the control (signaling) information flowing between GIG communications and computing resources to support end-to-end connectivity, QoS, and prioritization.
6.2 GIG Enterprise Services
GIG ES will be a suite of value-added information, web, and computing capabilities that will be available to all components, deployed by users across DoD in a consistent manner. This will enable leveraging of best-of-breed concepts and will maximize the net-centric performance of the GIG. When GIG ES is first fielded, the first suite of services that will be offered as part of the core enterprise services (the services that are useful throughout the DoD) will include Enterprise Service Management and IA/Security.
All information technology (IT) systems and National Security Systems (NSS) acquired, procured (systems or services), or operated by any DoD component will need access to the Core Enterprise Services. There is no single DoD “net” for a service provider to live within, and it is desirable to offer common core services across all the nets. The networks may require separately hosted solutions for core support. Interface devices such as gateways and guards that span some of these boundaries may also be required. Thus the core services must exist in Operational Area networks (OANs), Metropolitan Area Networks (MANs), and Wide Area Networks (WANs) (both Continental U.S. (CONUS) and Theaters) to include the AN.
6.2.1 Enterprise Service Management/Network Operations
Effective operational management of GIG transport systems and their components will in large part depend upon having an infrastructure that has been instrumented with monitoring and reporting capabilities, an in-depth knowledge regarding critical mission processes that the infrastructure must support, an understanding of the relationships between the two, and the ability to present relevant status and associated mission impact assessments to decision makers at all levels. This will necessitate an increased level of information sharing and integration between management operations across different technology, operational, and security domains.
GIG transport service providers must take an active role in developing the necessary set of cross-domain operational policies, processes, and procedures, based on internationally accepted common bodies of knowledge needed to enhance the flow of information between different management domains thereby ensuring that problems are proactively detected, isolated and resolved with the minimum impact to the user as well as providing for improved planning and provisioning through better communications of requirements.
Enterprise Service Management will provide end-to-end GIG performance monitoring, configuration management and problem detection/resolution, as well as enterprise IT resource accounting and addressing, for example, for users, systems and devices. Additionally, general help desk and emergency support to users is encompassed by this service area, similar to 911 and 411.
6.2.2 Information Assurance/Security
The GIG operational mission concepts provide the target functionality for which IA constructs were conceptualized and specified. Seven core IA functions emerged as the foundational enablers for the GIG mission concepts. Each of these constructs, referred to as IA system enablers, are the architectural building blocks for achieving (enabling) one or more of the GIG mission concepts. Full interoperability with the GIG IA Architecture and other, GIG supporting transport networks, requires the AN support the core IA functions:
• Identification and Authentication Strength of Mechanism is the process of evaluating the strength of user authentication, the assurance of the requesting client and other Information Technology (IT) components, and the risk associated with the user’s operating environment to determine the associated level of trust of the entity. Identity and Authentication (I&A) Strength of Mechanism (SoM) scores enable dynamic access control decisions to be made based on how resistant the authentication of each service request is to impersonation or forgery.
• Distributed Policy-Based Access Control is used to manage and enforce rule-based access control policies based on real-time assessment of the operational need for access and the security risk associated with granting access.
• Secure End-to-End Communications Environment as it applies to the AN primarily involves the protection of data in transit and, to a lesser extent, data at rest.
• Dynamic Policy Management enables the establishment of digital policies for enforcing how assets are managed, utilized, and protected. It allows the flexibility needed to ensure the right asset is available, at the right place, at the right time.
• Assured Management and Allocation of GIG Resources maintains the integrity and availability of all enterprise resources and ensures that they are available based on operational needs.
• Enterprise-Wide Network Defense and Situational Awareness consists of enterprise-wide protection, monitoring, detection and analysis that support mission situational awareness and response actions.
• Assured Management of Enterprise-Wide IA Mechanisms and Assets encompasses the policies, procedures, protocols, standards and infrastructure elements required to reliably support initialization and over-the-network security management (command, control and monitoring) of IA mechanisms and assets.
Consequently, the AN will be expected to achieve the requisite level of system security needed to maintain the overall level of GIG enterprise security that enables these mission capabilities. Properly designed and implemented, IA within the GIG will provide the needed availability, integrity, and confidentiality to allow authorized users to access the information they need to carry out their mission while preventing unauthorized users from denying, degrading, or exploiting that mission. AN IA functions will ensure these security services are in place for the GIG supporting, AN air-to-air, air-to-ground, and air-to-space transport infrastructure.
6.3 GIG Transport Convergence
GIG transport convergence (i.e., convergence of voice, data, and video onto a single network) will require the phase out all legacy transmission and link-layer technologies over time. In the ideal end-state, all information will be transferred over a secure black core using the Internet Protocol.
IP convergence necessitates the development of a comprehensive end-to-end architecture for information transfer that addresses all aspects of the GIG infrastructure (e.g., LANs, WANs, etc). This architecture must ensure consistent voice/video over IP implementations, application modifications to adjust to changing network conditions, and consistent definition and treatment of service level agreements. However, one of the most difficult parts of this architecture will be addressing the performance management of end-to-end flows which transit nodes in the infrastructure with extreme changes in bandwidth, heavy congestion, long latencies, and the inherent difficulties of mobile tactical environments. No technology exists today to achieve end-to-end enforceable and measurable performance in the heterogeneous DoD environment with its many transformational communications networks.
Additional details on the DoD IP convergence planning can be found in TBD.
6.4 GIG Routing Architecture
TBD
6.5 GIG Quality of Service Architecture
The Military Communications Electronics Board (MCEB) has established a GIG End-to-End QoS Working Group led by the Defense Information Systems Agency (DISA). This working group is preparing recommendations for a phased approach to implementing QoS within the GIG. Figure 6-2 depicts a notional technical approach for realizing end-to-end QoS across several network domains. This diagram and the QoS mechanisms listed are not intended to specify a specific framework, but to illustrate the recognized subdivision of the GIG into multiple domains and types of domain, as well as to identify mechanisms of potential utility within each type of domain.
[pic]
Figure 6-2: End-to-End Strawman Technical Approach for QoS/CoS
The working group has also prepared a table of “Proposed DiffServ Flow Classification and Corresponding DiffServ Code Points (DSCPs)/Class Selector Code Point (CSCP) Values” that identify traffic flow classes based upon nature of the flows and military traffic precedence levels within the flow classes. This proposal addresses the DoD enterprise’s need to standardize the methodology for describing IP traffic flow types and precedence levels, as well as, having consistent end-to-end treatment of DSCPs (assured delivery markings). DSCP values need to be preserved through the various networks from source to destination, to ensure the mission commander’s intent is known and can be properly complied with by all networks and systems.
Based on current technologies, implementation of an end-to-end QoS/CoS capability will depend upon adherence to the following general guidelines:
• End-to-end QoS/CoS support requires all network domains to adopt a common QoS/CoS architecture.
• Service level agreements (SLAs) will likely be needed between domains; however, the existence of SLAs does not eliminate the need for a common QoS/CoS architecture.
• An end-to-end QoS/CoS architecture must include support at the network layer, allowing traversal of heterogeneous networks providing a commonly understood set of network-layer technologies.
• The selected QoS/CoS architecture must be applicable to different types of domains ranging from vastly over provisioned, for example GIG-BE, to highly bandwidth-limited, such as mobile, tactical networks.
• Within individual domains, QoS/CoS support may be provided at the link layer. In these cases, network-layer technologies may utilize that support in order to efficiently accomplish QoS/CoS provision within that domain.
• A complete, end-to-end QoS architecture must include multiple, complementary mechanisms, such as admission control, traffic shaping, various queue management strategies, and application-layer aspects.
• Provisions must exist for existence and enforcement of QoS/CoS policy, as well as management of this policy across the GIG enterprise. [Source: DoD Transport Design Guidance Document, Version 0.97]
Additional details on the DoD end-to-end QoS/CoS planning can be found in TBD.
6.6 Interface Definition
To ensure interoperability, a consistent method to interface with GIG component networks will be defined. This interface definition must describe:
• Types of communication transport services provided across the interfaces (e.g., MLPP voice, real-time data, etc.)
• Type of networking relationships that exist between the two networks at the interface (e.g., peer, hierarchical peer, etc.)
• Traffic security classification levels, security associations and security procedure for both sides of each interface
• Security related attributes of the two networks (e.g., both networks are red, both networks are black, one network is black and other network is red, or traffic type dependent relationships)
• Types of routing protocol information and resource availability information needing to be transferred across the interface
• QoS/CoS features, guarantees, and applicable parameters offered on both sides of the interface
• Implementation of any Performance Enhancing Proxies (PEPs)
• Implementation details in terms of the user (or data), control, and management plane protocols, procedures, and exchanges.
A good joint interface agreement should be written in accord with the following prescriptions.
1. Provide a ‘network architecture’ picture showing all possible interfaces between two networks (with internal nodes and links depicted with enough detail to put the interface in context). Explicitly identify ‘gateway nodes’ from the perspective of the two networks. Also, identify the connection mechanism between the two gateways.
1. The default assumption is that the interface between the two networks will be at the link level. This means that links connecting gateways in one network with gateways in another network are the ‘physical interfaces’ for carrying user traffic.
2. Describe the types of user information transfer services (data or bearer plane services) provided across the interfaces (there could be more than one in that different traffic types may use different services).
3. Describe the networking relationships exist between networks at this interface.
4. Describe assumptions on traffic security classification levels, security associations and security procedure for both sides of each interface.
5. Describe the security related attributes of the two networks (e.g., both networks are red, both networks are black, one network is black and other network is red, or traffic type dependent relationships). Describe where the PlainText (PT)-CypherText (CT) boundaries occur, if the two networks have different attributes for traffic segments.
6. Describe the types of routing protocol information and resource availability information needing to be transferred across the interface.
7. Describe Quality of Service (QoS) features offered on both sides of the interface. For packet service, these may include: Differential Services (DiffServe), Integrated Services (IntServe), Resource Reservation Protocol (RSVP), RSVP-Traffic Engineering (RSVP-TE), etc. If there is a difference in the offerings in two networks, describe where ‘translation (aggregation, etc.) occurs. Also describe if there is any policing and Call Admission Control (CAC) function in one or both direction. Also describe what happens to traffic above acceptable value by the policing function and to the flows rejected by the CAC function.
8. For packet services, if one or both networks terminates a transport layer protocol (e.g. via Performance Enhancing Proxies), identify the termination and specify any requirements created on the other network. Also, specify if the network with will have a matching termination at the other end.
9. For each of the two networks, specify whether the Multi-Level Precedence and Preemption (MLPP) classification is supported. These include Routine (R), Priority (P), Immediate (I), Flash (F) and Flash Override (FO). Describe how MLPP is activated (indicators, fate of preempted traffic, etc.) and what interactions take place at the interface in relation to this capability.
10. For each network, describe if it can specify and provide QoS guarantees. Also, specify all QoS parameters that can be guaranteed in this fashion. QoS here should be interpreted in a broad sense: data rate, delay, loss, jitter, availability, recovery time, etc.
[Source: DoD Transport Design Guidance Document, Version 0.97]
7. Airborne Network Model Diagrams (SV-2)
Table 7-1 summarizes the key system functionality (described in section 5) that will be required at each network node type. Figures 7-1 through 7-6 depicts this information in an SV-2 graphic for each node.
Table 7-1. Summary of Node Types and System Functionality
|Node Type |On-Board Infrastructure |AN Equipment |Off-Board Transmission |
|Legacy |Platform Distribution |None |One or more legacy voice/data |
| |Sensor data buses (as needed) | |terminals (e.g., UHF SATCOM |
| |Digital audio & data buses | |terminals, HF/VHF/UHF LOS radios, |
| |IP-based LANs | |TDL terminals, CDL terminals, |
| | | |Commercial SATCOM, MILSATCOM |
| |Information Assurance | |terminals) |
| |TRANSEC | | |
| | | | |
| |Network Management | | |
| |None | | |
| | | | |
| |Gateways | | |
| |Data Link Gateway | | |
| |PEPs | | |
|Relay/ Gateway |Platform Distribution |None |Several legacy voice/data terminals |
| |Sensor data buses (as needed) | |(e.g., UHF SATCOM terminals, |
| |Digital audio & data buses | |HF/VHF/UHF LOS radios, |
| |IP-based LANs | |TDL terminals, CDL terminals, |
| | | |Commercial SATCOM, MILSATCOM |
| |Information Assurance | |terminals) |
| |TRANSEC | | |
| | | | |
| |Network Management | | |
| |None | | |
| | | | |
| |Gateways | | |
| |TDL Gateway | | |
| |Data Link Gateway | | |
| |PEPs | | |
|Network Access |Platform Distribution |Routing/Switching |One or more IP-capable |
| |Sensor data buses (as needed) |No AN routing |voice/data/video terminals (e.g., |
| |Digital audio buses | |MUOS SATCOM terminals, TC SATCOM |
| |IP-based LANs |QoS/CoS |terminals, Commercial SATCOM |
| | |QoS Application Interface |terminals, Network CDL terminals, |
| |Information Assurance |QoS Mechanisms |Tactical Subnet terminals, |
| |TBD |QoS Manager |Lasercom terminals) |
| | | | |
| |Network Management |Information Assurance | |
| |Local Network Management System (for |SM Agent | |
| |On-Board, AN, and Off-Board network |Policy Enforcement | |
| |components) |HAIPE | |
| |NM HMI (e.g., Console) |TRANSEC | |
| | |IDS & Virus Protection | |
| |Gateways |Vulnerability Assessment System | |
| |Legacy Infrastructure Gateway |Firewalls & Guards | |
| |PEPs | | |
| | |Link Management | |
| | |LM Agent | |
| | | | |
| | |Network Management | |
| | |Intelligent NM Agent | |
| | | | |
| | |Network Services | |
| | |Name Resolution Service: Naming | |
| | |Client (name resolver) | |
| | |. | |
|Network Capable |Platform Distribution |Routing/Switching |One or more IP-capable |
| |Sensor data buses (as needed) |Intra-area Routing |voice/data/video terminals (e.g., TC |
| |Digital audio buses | |SATCOM terminals, Commercial SATCOM |
| |IP-based LANs |QoS/CoS |terminals, Network CDL terminals, |
| | |QoS Application Interface |Tactical Subnet terminals) |
| |Information Assurance |QoS Mechanisms | |
| |TBD |QoS Manager | |
| | | | |
| |Network Management |Information Assurance | |
| |Local Network Management System (for |SM Agent | |
| |On-Board, AN, and Off-Board network |Policy Enforcement | |
| |components) |HAIPE | |
| |NM HMI (e.g., Console) |TRANSEC | |
| | |IDS & Virus Protection | |
| |Gateways |Vulnerability Assessment System | |
| |Legacy Infrastructure Gateway |Firewalls & Guards | |
| |PEPs | | |
| | |Link Management | |
| | |LM Agent | |
| | |LM Autonomous Manager | |
| | | | |
| | |Network Management | |
| | |Cluster Manager | |
| | |Intelligent NM Agent | |
| | |Cluster Policy Decision Point | |
| | | | |
| | |Network Services | |
| | |Name Resolution Service: Local Zone | |
| | |Database and Resource Records, Local | |
| | |Name Server, Naming Client (name | |
| | |resolver) | |
|Internetwork |Platform Distribution |Routing/Switching |Some legacy voice/data terminals |
| |Sensor data buses (as needed) |Intra-area & Inter-area Routing |(e.g., UHF SATCOM terminals, |
| |Digital audio buses | |HF/VHF/UHF LOS radios, |
| |IP-based LANs |QoS/CoS |CDL terminals) |
| | |QoS Application Interface | |
| |Information Assurance |QoS Mechanisms |Multiple IP-capable voice/data/video |
| |TBD |QoS Manager |terminals (e.g., MUOS SATCOM |
| | | |terminals, TC SATCOM terminals, |
| |Network Management |Information Assurance |Commercial SATCOM terminals, Network|
| |Local Network Management System (for |Security Manager |CDL terminals, Tactical Subnet |
| |On-Board, AN, and Off-Board network |Policy Distribution, & Enforcement |terminals, |
| |components and subnet management) |HAIPE |Lasercom terminals) |
| |NM and Policy Management HMI (e.g., |TRANSEC | |
| |Console) |IDS & Virus Protection | |
| | |Vulnerability Assessment System | |
| |Gateways |Firewalls & Guards | |
| |Data Link Gateway | | |
| |Legacy Infrastructure Gateway |Link Management | |
| |PEPs |LM Agent | |
| | |LM Autonomous Manager | |
| | |LM Executive | |
| | | | |
| | |Network Management | |
| | |AN Network Manager | |
| | |Intelligent NM Agent | |
| | |Cluster Manager | |
| | |Policy Server/Repository | |
| | |Policy Decision Point | |
| | |Cluster Policy Decision Point | |
| | | | |
| | |Network Services | |
| | |Name Resolution Service: Local Zone | |
| | |Database and Resource Records, Local | |
| | |Name Server, Naming Client (name | |
| | |resolver) | |
|Network Service |Platform Distribution |Routing/Switching |Some legacy voice/data terminals |
|Provider |Sensor data buses (as needed) |Intra-area, Inter-area, & Interdomain|(e.g., UHF SATCOM terminals, |
| |Digital audio buses |Routing |HF/VHF/UHF LOS radios, |
| |IP-based LANs | |CDL terminals) |
| | |QoS/CoS | |
| |Information Assurance |QoS Application Interface |Multiple IP-capable voice/data/video |
| |TBD |QoS Mechanisms |terminals (e.g., MUOS SATCOM |
| | |QoS Manager |terminals, TC SATCOM terminals, |
| |Network Management | |Commercial SATCOM terminals, Network|
| |Local Network Management System (for |Information Assurance |CDL terminals, Tactical Subnet |
| |On-Board, AN, and Off-Board network |Security Manager |terminals, |
| |components and AN/subnet management) |Policy Input, Distribution, & |Lasercom terminals) |
| |NM and Policy Management HMI (e.g., |Enforcement | |
| |Console) |HAIPE | |
| |Ground-based Resource Planning Tools |TRANSEC | |
| |Ground-based Modeling, Analysis, and |KLIF | |
| |Simulation Tools |IDS & Virus Protection | |
| | |Vulnerability Assessment System | |
| |Gateways |Firewalls & Guards | |
| |Data Link Gateway |Security M&S | |
| |Legacy Infrastructure Gateway | | |
| |PEPs |Link Management | |
| | |LM Agent | |
| | |LM Autonomous Manager | |
| | |LM Executive | |
| | | | |
| | |Network Management | |
| | |AN Network Manager | |
| | |Policy Server/Repository | |
| | |Policy Decision Point | |
| | | | |
| | |Network Services | |
| | |Name Resolution Service: Gateway to | |
| | |GIG DNS, Local Zone Database and | |
| | |Resource Records, Local Name Server, | |
| | |Naming Client (name resolver) | |
[pic]
Figure 7-1. Legacy Node Communications Diagram
[pic]
Figure 7-2. Relay/Gateway Node Communications Diagram
[pic]
Figure 7-3. Network Access Node Communications Diagram
[pic]
Figure 7-4. Network Capable Node Communications Diagram
[pic]
Figure 7-5. Internetwork Node Communications Diagram
[pic]
Figure 7-6. Network Service Provider Node Communications Diagram
8. Node and Link Configurations for Candidate Platform Types (SV-5)
8.1 Approach
In this section, a notional AN system configuration is presented for several candidate platform types. The notional system configuration should be considered the minimum set of system functionality needed to provide the network capabilities necessary to support the projected (time independent) platform mission operations discussed here. The notional configurations are only intended to depict the needed systems functions and their inter-relationships, which can be used as guidelines for where and when to implement different system functions or technologies. It is not intended to be a network design specifying the exact type, quantities, sizing or placement of system components for specific platforms.
This section begins with a notional highly mobile platform with minimal information exchange needs, referred to as an Airborne Fighter platform. The second notional platform is a relatively slow-moving platform with more intensive information exchange needs, referred to as an Airborne C4ISR platform. The third notional platform is a relatively slow-moving airborne platform that supports AN network range extension, internetworking, and gateway functions. This platform is referred to as an Airborne Communications Relay platform.
For each notional platform type, a brief operational profile is provided in terms of the operational characteristics that drive the AN implementation and employment. These characteristics include flight patterns, information exchange needs, and any physical constraints imposed by the platform. These drivers are used to determine the needed network capabilities (connectivity, network services and operations), the minimum airborne network functions, links and topologies, and finally the corresponding network node and system functions for each platform in an objective AN.
8.2 Fighter Platform
8.2.1 Operational Profile
An airborne fighter platform flight profile includes periods of stable flight patterns and dynamic maneuvers at high speeds. Its relatively small size limits the amount of space available for mounting antennas and installing equipment. It also limits the amount of prime power available to AN equipment and other on-board processing. It will host only one or two crew members, thus its mission applications, sensors, and munitions will be specialized for conducting one or two mission types (e.g., Close Air Support (CAS) or Suppression of Enemy Air Defenses (SEAD)).
It will be employed as part of a strike package or combat air patrol (CAP). The strike package or CAP includes groups of two to four airborne fighter platforms up to a total of 200 platforms. The strike package or CAP will have supporting airborne C2 and ISR platform(s), tanker (refueling) platform(s), and ground C2 platform(s). Each airborne fighter platform requires connectivity to all other strike package or CAP and supporting platforms; however, a majority of information will be exchanged between airborne fighter platforms. This is driven in large part because of the need for frequent (e.g., every 2 seconds) situational awareness and target sorting updates (e.g., position location on both friendlies and hostiles) in a highly mobile environment. The second largest information exchange is general background situational awareness exchanges between an airborne fighter platform and airborne C4ISR platform(s). The majority of information is exchanged as real-time (fixed format message) data and voice. Some imagery files and live video feeds may be forwarded to airborne fighter platforms from the supporting platforms. Networked munitions on-board the airborne fighter platform may also be exchanging information.
8.2.2 AN Capabilities, Links, and Topologies
Table 8-1 summarizes the network capabilities needed to support the operational profile described in section 8.2.1.
Table 8-1. Airborne Fighter Platform AN Capabilities
| |Network Capabilities |
| |Connectivity |Services |Operation |
|Airborne |Coverage: LOS, potentially BLOS |Real-time data |Managing: Legacy node: |
|Fighter Platform |Diversity: 2 or 3 links/2 or 3 |Voice |Manual planning, analyzing, |
| |waveforms |Interactive data |monitoring, and controlling of |
| |Throughput: Low speed to high speed| |legacy node resources locally. |
| |connections | |Network node: Monitoring and |
| |Type of connection: Pt-Pt, | |controlling of network capable node |
| |Pt-MultPt, Forwarding | |resources locally and from a remote |
| |Network interfaces: Legacy links | |network node, distribute network SA |
| |and tactical subnets | |data, match use of resources to |
| | | |operational objectives. |
| | | |Forming and Adapting: Legacy node: |
| | | |Manual provisioning, initialization |
| | | |and restoration of legacy node link |
| | | |resources. Network node: Automated|
| | | |provisioning, initialization and |
| | | |restoration of AN link resources. |
| | | |Accessing: Legacy Node:|
| | | |Link and tactical subnet protection,|
| | | |with limited manual detection and |
| | | |reaction for legacy node resources. |
| | | |Network node: Tactical subnet |
| | | |protection, with automated detection|
| | | |and reaction for network capable |
| | | |node resources. |
The minimum network capabilities needed to support the airborne fighter platform operational profile can be provided by legacy and network capable AN nodes with legacy and subnet links. Airborne fighter platforms will participate in both tethered and flat ad-hoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the airborne fighter platform and supporting elements. A flat ad-hoc topology would be used between airborne fighter platforms in a strike package or CAP for the more frequent information exchanges.
8.2.3 AN System Configuration
Figure 8-1 depicts the minimum system configuration to implement the AN node functions, links, and topologies to support airborne fighter platform operations.
[pic]
Figure 8-1. Fighter Platform AN System Configuration
8.2.4 Airborne Fighter Platform AN Issues and Risks
TBD
8.3 Airborne C4ISR Platform
8.3.1 Operational Profile
This operational profile applies to the mission crew (as opposed to the flight crew) on manned C4ISR platforms. A C4ISR platform flight profile includes periods of enroute flying and repeated, stable flight patterns. The relatively large size enables space available for mounting antennas and installing significant communications equipment to accommodate multiple mission crew functions. It also enables prime power available to AN equipment and other on-board processing. It will host up to three dozen mission crew members, including a communications operator. A C4ISR platform’s mission applications and sensors will support multiple capabilities and mission types. Mission durations for any single aircraft and crew could range up to 12 hours; with aerial refueling it could be extended to 24 hours. C4ISR platforms often operate beyond line-of-sight of ground infrastructure.
A C4ISR platform could be employed as a stand-alone or as part of a multiple sensor platform ISR constellation. Some will also be employed as airborne elements of the tactical air control system (AETACS) for support to strike package(s), CAP, etc. (refer to section 8.2.1 for description of fighter aircraft employment). These C4ISR platforms require a broad range of connectivity to simultaneously support ISR and battle management (for AETACS) functions for multiple mission types.
In stand-alone and ISR constellation missions, connectivity is primarily used to send/receive tasking and status and to distribute raw and processed (e.g., tracks) sensor data. Air Tasking Order (ATO) updates, theater and national imagery/video and other intel data must be received. The raw sensor data is collected and off-loaded in continuous streams. The volume of information and its distribution is dependent upon the type of sensor data. For example, Air Moving Target Indicator (AMTI) is relatively low volume, but is distributed to a comparatively greater number of platforms (including airborne and ground) than Ground Moving Target Indicator (GMTI) and Synthetic Aperture Radar (SAR) and other types of sensor data. The larger volumes of data are offloaded to one or more ground stations (up to 30), which may be located in theater (LOS or BLOS of platform operation) or in CONUS (reachback connectivity from platform). This data is offloaded in real time (as it is collected), and can include video. As more processing capability is fielded in airborne platforms to enable collaborative targeting, some of this large volume data may also be provided to other airborne C4ISR platforms.
For battle management functions, the C4ISR platform requires connectivity to all strike package or CAP aircraft and supporting (ground and airborne) platforms; however, a majority of information will be exchanged with the other airborne ISR and strike package or CAP platforms. This is driven in large part because of the need for frequent (e.g., every 2 seconds) situational awareness updates (e.g., position location) in a highly mobile environment. The second largest information exchange is command and control information between the C4ISR platform and the ground tactical air control system (GTACS) elements, including the Air and Space Operations Center (AOC). The C4ISR platform forwards information between networks and COIs involved in multiple mission types. The majority of information is exchanged as real-time (fixed format message) data, interactive data (files), and voice. Some imagery files may be forwarded between C4ISR platforms, GTACS elements, and strike package or CAP aircraft.
8.3.2 AN Capabilities, Links, and Topologies
Table 8-2 summarizes the network capabilities needed to support the operational profile described in section 8.3.1.
Table 8-2. C4ISR Platform AN Capabilities
| |Network Capabilities |
| |Connectivity |Services |Operation |
|C4ISR Platform |Coverage: LOS and BLOS |Real-time data |Managing: Legacy node: |
| |Diversity: >10 links/ waveforms |Voice |Manual planning, analyzing, |
| |Throughput: Low speed to high speed|Interactive data |monitoring, and controlling of |
| |connections |Video |legacy node resources locally. |
| |Type of connection: Pt-Pt, |Bulk transfer |Network node: Monitoring and |
| |Pt-MultPt, Forwarding | |controlling of network capable node |
| |Network interfaces: Legacy links, | |resources locally and from a remote |
| |tactical subnets, GIG | |network node, distribute network SA |
| | | |data, match use of resources to |
| | | |operational objectives. |
| | | |Forming and Adapting: Legacy node: |
| | | |Manual provisioning, initialization |
| | | |and restoration of legacy node link |
| | | |resources. Network node: Automated|
| | | |provisioning, initialization and |
| | | |restoration of AN link resources. |
| | | |Accessing: Legacy node:|
| | | |Link and tactical subnet protection,|
| | | |with limited manual detection and |
| | | |reaction for legacy node resources. |
| | | |Network node: Tactical subnet |
| | | |protection, with automated detection|
| | | |and reaction for network capable |
| | | |node resources. |
The minimum network capabilities needed to support the C4ISR platform operational profile can be provided by legacy and internetwork AN nodes with network access, subnet and legacy links. C4ISR platforms will participate in both tethered and tiered ad-hoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the C4ISR platform, GTACS, and strike package or CAP aircraft. A tiered ad-hoc topology would be used between the C4ISR platform and airborne fighter platforms in a strike package or CAP. Some operational concepts for collaborative targeting may also require airborne backbone links and topologies for timely distribution of high volume sensor data between C4ISR platforms. An airborne backbone could also be used in an extended theater to provide reachback capabilities between strike package, CAP aircraft, and GTACS elements.
8.3.3 AN System Configuration
Figure 8-2 depicts the minimum system configuration to implement the AN node functions, links, and topologies to support C4ISR platform operations.
[pic]
Figure 8-2. C4ISR Platform AN System Configuration
8.3.4 C4ISR Platform AN Issues and Risks
TBD
8.4 Airborne Communications Relay Platform
8.4.1 Operational Profile
This operational profile applies to airborne communications relay functions onboard a widebody platform or a UAV that may or may not be dedicated to the communications relay function. Airborne communications relay platform flight profile includes periods of enroute flying and repeated, stable flight patterns. The relatively large size of widebodies theoretically enables space available for mounting antennas and installing significant communications equipment; however this may be limited by the primary mission function for the platform (e.g., C4ISR). UAVs offer long endurance and high altitude, which give wide area air and surface coverage and good optical paths to satellites. Mission durations for any single aircraft and crew could range up to 12 hours or more for widebodies and longer for UAVs. Airborne communications relay platforms could operate within line-of-sight or beyond line-of-sight of ground infrastructure. They may or may not have a communications operator on-board.
The mission of an airborne communications relay platform is to be employed as part of and/or support to C4ISR constellation and/or strike package(s) or CAP. The communications relay platform provides connectivity between elements of a strike package, CAP aircraft, C4ISR platforms, and GTACS platforms that require range extension or internetworking and gateway functions between networks for information interoperability. For platforms that are beyond line of sight of ground infrastructure (and have no space infrastructure connection) the communications relay platform provides critical connectivity for C2 and situational awareness. The airborne communications relay platform must support all information exchange types and characteristics used within a theater.
8.4.2 AN Capabilities, Links, and Topologies
Table 8-3 summarizes the network capabilities needed to support the operational profile described in section 8.4.1.
Table 8-3. Airborne Communications Relay Platform AN Capabilities
| |Network Capabilities |
| |Connectivity |Services |Operation |
|Airborne |Coverage: LOS and BLOS |Real-time data |Managing: Legacy node: |
|Communications |Diversity: >10 links/ waveforms |Voice |Manual planning, analyzing, |
|Relay Platform |Throughput: Low speed to high speed|Interactive data |monitoring, and controlling of |
| |connections |Video |legacy node resources locally. |
| |Type of connection: Pt-Pt, |Bulk transfer |Network node: Monitoring and |
| |Pt-MultPt, Forwarding | |controlling of network capable node |
| |Network interfaces: Legacy links, | |resources locally and from a remote |
| |tactical subnets, GIG | |network node, distribute network SA |
| | | |data, match use of resources to |
| | | |operational objectives. |
| | | |Forming and Adapting: Legacy node: |
| | | |Manual provisioning, initialization |
| | | |and restoration of legacy node link |
| | | |resources. Network node: Automated|
| | | |provisioning, initialization and |
| | | |restoration of AN link resources. |
| | | |Accessing: Legacy node:|
| | | |Link and tactical subnet protection,|
| | | |with limited manual detection and |
| | | |reaction for legacy node resources. |
| | | |Network node: Tactical subnet |
| | | |protection, with automated detection|
| | | |and reaction for network capable |
| | | |node resources. |
The minimum network capabilities needed to support the airborne communications relay platform operational profile can be provided by legacy and internetwork AN nodes with network access, subnet and legacy links. Airborne communications relay platforms will participate in both tethered and tiered ad-hoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the C4ISR platform, GTACS, and strike package or CAP aircraft. A tiered ad-hoc topology would be used between the C4ISR platform and airborne fighter platforms in a strike package or CAP. Some operational concepts for collaborative targeting may also require airborne backbone links and topologies for timely distribution of high volume sensor data between C4ISR platforms. An airborne backbone could also be used in an extended theater to provide reachback capabilities between strike package or CAP and GTACS elements.
8.4.3 AN System Configuration
Figure 8-3 depicts the the minimum system configuration to implement the AN node functions, links, and topologies to support airborne communications relay platform operations.
Figure 8-3. Airborne Communications Relay Platform AN System Configuration
8.4.4 Airborne Communications Relay Platform AN Issues and Risks
TBD
9. Recommended Network Standards
9.1 Current Standards (TV-1)
Table 9-1 includes a list of the key technical standards that should be used in near-term and interim AN implementations to provide the AN functionality defined herein. This list is not all inclusive and many of the standards only provide a subset of the desired functionality. See section 9.2 for potential emerging standards that provide more of the desired functionality and section 9.3 for a list of areas for which widely accepted standards do not yet exist. Standards that are included in the Department of Defense (DoD) Information Technology Standards Registry (DISR) are noted.
Table 9-1. Applicable Technical Standards
|Standards Area |Description/Discussion |Applicable Standards |
|Connectivity |
|Routing |Open Shortest Path First (OSPF) |RFC 1584 (Multicast Extensions to OSPF) |
| | |(DISR) - RFC 2328/ IETF Standard 54 (OSPF Version 2) |
| | |(DISR) - RFC 2740 (OSPF for IPv6) |
| | |RFC 3630 (Traffic Engineering Extensions to OSPF v2) |
| | | |
| | | |
| | |(DISR) - RFC 1771, (Border Gateway Protocol 4 (BGP-4) |
| | |RFC 1997 (BGP Communities) |
| |Border Gateway Protocol (BGP) |RFC 2439 (Route Flap Dampening) |
| | |(DISR) - RFC 2545 (Extensions for IPv6 Inter-Domain |
| | |Routing) |
| | |RFC 2796 (Route Reflection) |
| | |(DISR) - RFC 2858 (Multiprotocol Extensions) |
| | |RFC 2918 (Route Refresh Capability) |
| | |RFC 3065 (AS Confederations) |
| | |RFC 3107 (Label Information) |
| | |RFC 3392 (Capabilities Advertisement) |
| | | |
| | | |
| | |RFC 1142 (IS-IS Intra-Domain Routing Protocol) |
| | |RFC 1195 (IS-IS in TCP/IP Environments) |
| | | |
| |Intermediate System to Intermediate System| |
| |(IS-IS) | |
|Quality of Service |Differentiated Services (DiffServ) |DiffServ: |
| | |(DISR) - RFC 2474 (DiffServ Field) |
| | |RFC 2475 (DiffServ Arch) |
| | |RFC 2597 (AF PHB) |
| | |RFC 2638 (Bandwidth Broker for Diffserv Arch) |
| | |RFC 3086 (Per Domain Behaviors) |
| | |RFC 3140 (PHB Coding) |
| | |RFC 3246 (EF PHB) |
| | | |
| | | |
| | | |
| |Multi-Protocol Label Switching (MPLS) |MPLS: |
| | |(DISR) - RFC 2702 (Requirements for Traffic Engineering |
| | |over MPLS) |
| | |(DISR)-RFC 2917 (Core MPLS IP VPN Arch) |
| | |(DISR) - RFCs 3031 (MPLS-Arch), |
| | |RFC 3032 (MPLS LSR Encoding) |
| | |RFC 3209 (RSVP-TE for MPLS LSPs) |
| | |RFC 3477 ((RSVP-TE for MPLS LSPs – Unnumbered Links) |
| | | |
| | |DiffServ & MPLS: |
| | |RFC 3270 (MPLS-DS, with Mapping Guide) |
| | | |
| | | |
| | |IntServ: |
| |Integrated Services (IntServ) |(DISR) - RFC 2205 (RSVP) |
| | |(DISR) - RFC 2207 (RSVP Extensions for IPSec) |
| | |RFC 2209 (rsvp Message Processing Rules) |
| | |(DISR) - RFC 2210 (RSVP and IntServ) |
| | |RFC 2211 (Controlled Load Service), |
| | |RFC 2212 (Guaranteed Service) |
| | |RFC 2215 (Characterization Parameters) |
| | |RFC 2688 (IntServ over Low Speed Networks) |
| | |RFC 2746 (RSVP over IP Tunnels) |
| | |RFC 2815 (IntServ over IEEE 802 Networks) |
| | |RFC 2961 (RSVP Overhead Reduction) |
| | |(DISR) - RFC 3175 (Aggregate RSVP) |
| | | |
| | |IntServ & DiffServ: |
| | |RFC 2996 (RSVP DCLASS Object) |
| | |RFC 2297 (RSVP Null Service Type) |
| | |RFC 2998 (Framework IntServ over DiffServ) |
| | | |
| | | |
| | |RFC 2750 (RSVP Extensions for Admission Control) |
| | |RFC 2753 (Framework for Policy-based Admission Control) |
| | |RFC 2814 (RSVP-Based Admission Control over IEEE 802 |
| |Admission Control and Policy |Networks) |
| | |RFC 3644 (Policy QoS Information Model) |
|Information Assurance |
|DoD IA |DoD IA Policy Framework |8500 - General |
| | |DoDD 8500.1, "Information Assurance (IA)," 10/24/2002 |
| | |DoDI 8500.2, "Information Assurance (IA) Implementation,"|
| | |02/06/2003 |
| | | |
| | |8510 - Certification and Accreditation |
| | | |
| | |8520 - Security Management (SMI, PKI, KMI, EKMS) |
| | |DoDD 8520.1, "Protection of Sensitive Compartmented |
| | |Information (SCI)," 12/20/2001 |
| | |DoDI 8520.2, "Public Key Infrastructure (PKI) and Public |
| | |Key (PK) Enabling," 04/01/2004 |
| | | |
| | |8530 - Computer Network Defense /Vulnerability Mgt |
| | |DoDD O-8530.1 “Computer Network Defense (CND),” 01/08/01 |
| | |DoDI O-8530.2 “Support to Computer Network Defense |
| | |(CND),” 03/09/01 |
| | | |
| | |8540 - Interconnectivity/Multi-Level Security (SABI) |
| | | |
| | |8550 - Network/Web (Access, Content, Privileges) |
| | |DoDI 8551.1, "Ports, Protocols, and Services Management |
| | |(PPSM)," 08/13/2004 |
| | | |
| | |8560 - Assessments (Red Team, TEMPEST Testing & |
| | |Monitoring) |
| | | |
| | |8570 - Education, Training, Awareness |
| | |DoDD 8570.1, "Information Assurance Training, |
| | |Certification, and Workforce Management," 08/15/04 |
| | | |
| | |8580 - Other (Mobile Code, IA OT&E, IA in Acquisition) |
| | |DoDI 8580.1, "Information Assurance (IA) in the Defense |
| | |Acquisition System," 07/09/2004 |
|Network Layer Security |IPSec |(DISR) - RFC2401 (Security Architecture for the Internet |
| | |Protocol) |
| | |(DISR) - RFC2402 (IP Authentication Header) |
| | |(DISR) - RFC2406 (IP Encapsulating Security Payload |
| | |(ESP)) |
|ASWR Respons | |DoDD 8500.1, DoDI 8500.2 |
|Authentication/ |DoD Certificate Policy |US DOD CP: “X.509 Certificate Policy (CP) for the U.S. |
|Identification | |Department of Defense (DOD)”, Version 5.0, 1 December |
| | |1999 |
| | | |
| |Online Certificate Status Protocol |RFC 2560 (X.509 Internet Public Key Infrastructure Online|
| | |Certificate Status Protocol –OCSP) |
| |X.509 | |
| | |RFC2510 (Internet X.509 Public Key Infrastructure |
| | |Certificate Management Protocols) |
| | |RFC2511 (Internet X.509 Certificate Request Message |
| | |Format) |
| | |RFC2585 (Internet X.509 Public Key Infrastructure |
| | |Operational Protocols: FTP and HTTP) |
| | |RFC2587 (Internet X.509 Public Key Infrastructure LDAPv2 |
| | |Schema) |
| | |RFC3161 (Internet X.509 Public Key Infrastructure |
| | |Time-Stamp Protocol (TSP)) |
| | |RFC3279 (Algorithms and Identifiers for the Internet |
| | |X.509 Public Key Infrastructure Certificate and |
| | |Certificate Revocation List (CRL) Profile) |
| | |RFC3280 (Internet X.509 Public Key Infrastructure |
| | |Certificate and Certificate Revocation List (CRL) |
| | |Profile) |
| |DoD Directive 8500 | |
| | |DoDD 8500.1, DoDI 8500.2 |
|Security Policy Management |SNMPv3 |RFC 3414 (User-based Security Model (USM) for version 3 |
| | |of the Simple Network Management Protocol (SNMPv3)) |
| | | |
| | |RFC3585 (IPsec Configuration Policy Information Model) |
| |IPSec | |
|Data Encryption |HAPIS |NSA HAIPIS Version 2, May 2004 |
| | | |
| |DoD Directive 8500 |DoDD 8500.1, DoDI 8500.2 |
|Key Distribution |Internet Key Exchange |RFC2409 (The Internet Key Exchange (IKE)) |
| | | |
| |Public-Key Cryptography Standards |(DISR) - RFC2315 (PKCS #7: Cryptographic Message Syntax |
| | |Version 1.5) |
| | |RFC2898 (PKCS #5: Password-Based Cryptography |
| | |Specification Version 2.0) |
| | |RFC2985 (PKCS #9: Selected Object Classes and Attribute |
| | |Types Version 2.0) |
| | |RFC2986 (PKCS #10: Certification Request Syntax |
| | |Specification Version 1.7) |
| | |RFC3447 (Public-Key Cryptography Standards (PKCS) #1: RSA|
| | |Cryptography Specifications Version 2.1) |
| | | |
| |Secure Socket Layer |RFC3207 (SMTP Service Extension for Secure SMTP over |
| | |Transport Layer Security) |
| | |(DISR) - Draft-freier-ssl-version3-01 |
| | | |
| |Transport Layer Security |(DISR) - RFC2246 (The TLS Protocol Version 1.0) |
| | |RFC2595 (Using TLS with IMAP, POP3 and ACAP) |
| | |RFC2712 (Addition of Kerberos Cipher Suites to Transport |
| | |Layer Security (TLS)) |
| | |RFC2830 (Lightweight Directory Access Protocol (v3): |
| | |Extension for Transport Layer Security) |
| | |RFC3268 (Advanced Encryption Standard (AES) Ciphersuites |
| | |for Transport Layer Security (TLS)) |
| | |RFC3436 (Transport Layer Security over Stream Control |
| | |Transmission Protocol) |
| | |RFC3546 (Transport Layer Security (TLS) Extensions) |
| | | |
| | |(DISR) - RFC2408 (Internet Security Association and Key |
| | |Management Protocol (ISAKMP)) |
| | | |
| |IPSec |DoDD 8500.1, DoDI 8500.2 |
| | | |
| | | |
| |DoD Directive 8500 | |
|Secure Directory |LDAP |RFC2649 (An LDAP Control and Schema for Holding Operation|
| | |Signatures) |
| | |RFC2829 (Authentication Methods for LDAP) |
| | |RFC3062 (LDAP Password Modify Extended Operation) |
| | |RFC3112 (LDAP Authentication Password Schema) |
|Secure Domain Name Services |DNS |(DISR) - RFC2535 (Domain Name System Security Extensions)|
| | |RFC3645 (Generic Security Service Algorithm for Secret |
| | |Key Transaction Authentication for DNS (GSS-TSIG)) |
|Network Management |
|Common Management Protocol | |IETF Standard 62: |
| | |RFC3411 (Architecture for SNMP Management Frameworks) |
| | |RFC 3412 (Message Processing & Dispatching for SNMP) |
| | |RFC 3413 (SNMP Applications) |
| | |RFC 3414 (User-Based Security Model for SNMPv3) |
| | |RFC 3415 (View-Based Access Control Model for SNMP) |
| | |RFC 3416 (Version 2 of the Protocol Operations for SNMP) |
| | |RFC 3417 (Transport Mappings for SNMP) |
| | |RFC 3418 (MIB for SNMP) |
|Common Structure of Management |Provides a common structure and format |(DISR) IETF Standard 16: |
|Information (SMI) |rules for representing management |RFC 1155 (Structure and Identification of management |
| |information; SMIv1 and SMIv2 |information for TCP/IP-based internets) |
| | |RFC 1212 (Concise MIB definitions) |
| | | |
| | |IETF Standard 58: |
| | |RFC 2578 (Structure of Management Information Version 2 |
| | |(SMIv2)) |
| | |RFC 2579 (Textual Conventions for SMIv2) |
| | |RFC 2580 (Conformance Statements for SMIv2) |
|Management Information Base |General |(DISR) IETF Standard 17: |
| | |RFC 1213 (Management Information Base for Network |
| | |Management of TCP/IP-based internets:MIB-II) |
| | |The following 3 RFCs update RFC 1213: |
| | |(DISR) RFC 2011 (SNMPv2 Management Information Base for |
| | |the Internet Protocol using SMIv2) |
| | |(DISR) RFC 2012 (SNMPv2 Management Information Base for |
| | |the Transmission Control Protocol using SMIv2) |
| | |(DISR) RFC 2013 (SNMPv2 Management Information Base for |
| | |the User Datagram Protocol using SMIv2) |
| | | |
| | |(DISR) IETF Standard 59: |
| | |RFC 2819 (Remote Network Monitoring Management |
| | |Information Base) |
| | | |
| | |(DISR) RFC 1657 (Definitions of Managed Objects for the |
| | |Fourth Version of the Border Gateway Protocol (BGP-4) |
| |Other MIBs |using SMIv2) |
| | |RFC 1724 (RIP Version 2 MIB Extension) |
| | |(DISR) RFC 1850 (OSPF Version 2 Management Information |
| | |Base) |
| | |(DISR) RFC 2021 (Remote Network Monitoring Management |
| | |Information Base Version 2 using SMIv2) |
| | |RFC 2096 (IP Forwarding Table MIB) |
| | |RFC 2206 (RSVP Management Information Base using SMIv2) |
| | |RFC 2213 (Integrated Services Management Information Base|
| | |using SMIv2) |
| | |RFC 2214 (Integrated Services Management Information Base|
| | |using SMIv2) |
| | |RFC 2564 (Application Management MIB) |
| | |(DISR) RFC 2605 (Directory Server Monitoring MIB) |
| | |RFC 2667 (IP Tunnel MIB) |
| | |RFC 2720 (Traffic Flow Measurement: Meter MIB) |
| | |(DISR) RFC 2788 (Network Services Monitoring MIB) |
| | |(DISR) RFC 2790 (Host Resources MIB) |
| | |RFC 2922 (Physical Topology MIB) |
| | |RFC 2932 (IPv4 Multicast Routing MIB) |
| | |RFC 2933 (Internet Group Management Protocol MIB) |
| | |RFC 2959 (Real-Time Transport Protocol Management |
| | |Information Base) |
| | |RFC 3273 (Remote Network Monitoring Management |
| | |Information Base for High Capacity Networks) |
| | |RFC 3287 (Remote Monitoring MIB Extensions for |
| | |Differentiated Services) |
| | |RFC 3289 (Management Information Base for the |
| | |Differentiated Services Architecture) |
| | |RFC 3559 (Multicast Address Allocation MIB) |
|Link Management |
|Location Management | |(DISR) RFC3261 (SIP: Session Initiation Protocol) |
| | |RFC3265 (Session Initiation Protocol (SIP)-Specific Event|
| | |Notification) |
|Registration | |RFC3326 (The Reason Header Field for the Session |
| | |Initiation Protocol (SIP)) |
| | |RFC3327 (Session Initiation Protocol (SIP) Extension |
| | |Header Field for Registering Non-Adjacent Contacts) |
| | |RFC3608 (Session Initiation Protocol (SIP) Extension |
| | |Header Field for Service Route Discovery During |
| | |Registration) |
| | |IETF Best Current Practice (BCP)0075, RFC3665 (Session |
| | |Initiation Protocol (SIP) Basic Call Flow Examples) |
|Service, Node and Path Discovery| |ITU-T G.7714/Y.1705 (Generalized automatic |
| | |discovery techniques), November 2001 |
| | |ITU-T G.7714.1/Y.1705.1 (Protocol for automatic |
| | |discovery in SDH and OTN networks), April 2003 |
| | |(DISR) RFC2461 (Neighbor Discovery for IP Version 6 |
| | |(IPv6)) |
| | |RFC3379 (Delegated Path Validation and Delegated Path |
| | |Discovery Protocol Requirements) |
| | |RFC3674 (Feature Discovery in Lightweight Directory |
| | |Access Protocol (LDAP)) |
|Network Services |
|Name Resolution Service | |(DISR) - IETF Standard 13 Domain Name System (RFC |
| | |1034/RFC 1035) |
|Configuration Management | |RFC 951, Bootstrap Protocol (BOOTSP) |
| | | |
| | |(DISR) - RFC 2131, Dynamic Host Configuration Protocol |
| | |RFC 3396 (Update of RFC 2131) |
|Network Time |Network Time Protocol |(DISR) - RFC 1305 Network Time Protocol (Version 3) |
9.2 Emerging Standards (TV-2)
Table 9-2. Applicable Emerging Technical Standards
|Standards Area |Description/Discussion |Applicable Standards |
|Connectivity |
|Routing |OSPF |Draft-ietf-ospf-scalability-08 (Prioritized Treatment |
| | |of OSPF Packets) |
| | |Draft-ietf-ospf-cap-03 (Advertising Optional Router |
| | |Capabilities), July 2004 |
| | | |
| | |Draft-ietf-isis-wg-multi-topology-07 (Multi-topology |
| | |Routing), June 2004 |
| |IS-IS |RFC 3784 (IS-IS Extensions for Traffic Engineering), |
| | |June 2004 |
| | |RFC 3787 (Recommendations for Networks Using IS-IS) |
| | | |
| | | |
| | |RFC 3561 (AODV Protocol) |
| | |RFC 3626 (OLSR Protocol) |
| | |draft-chandra-ospf-manet-ext-01 (OSPF Extensions), July|
| | |2004 |
| |Mobile Ad Hoc Routing |draft-ietf-manet-dsr-10 (The Dynamic Source Routing |
| | |Protocol for Mobile Ad Hoc Networks), July 2004 |
| | |draft-spagnolo-manet-ospf-wireless-interface-01 (OSPFv2|
| | |Wireless Interface Type), May 2004 |
| | |draft-spagnolo-manet-ospf-design (Design Considerations|
| | |for a Wireless OSPF Interface), April 2004 |
| | |draft-jeong-manet-maodv6-00 (Multicast Ad hoc On-Demand|
| | |Distance Vector Routing for IP version 6), July 2004 |
|Quality of Service |DiffServ and IntServ |RFC 3670 (Model for QoS Datapath Mechanisms), January |
| | |2004 |
| | |RFC 3754 (Multicast for DiffServ), April 2004 |
| | |ID draft-baker-diffserv-basic-classes-03 (DSCP PHB |
| | |Mapping Guide), July 2004 |
| | | |
| | | |
| | | |
| | | |
| | | |
| |QoS and Signaling |RFC 3726 (Requirements for Signaling Protocols), April |
| | |2004 |
| |IETF Next Steps in Signaling WG |draft-ietf-nsis-fw-06 (Next Steps in Signaling: |
| | |Framework), July 2004 |
| |The Next Steps in Signaling (NSIS) working|draft-ash-nsis-nslp-qspec-01 (QoS-NSLP QSpec Template),|
| |group is considering protocols for |July 2004 |
| |signaling information about a data flow |draft-tschofenig-nsis-qos-ext-authz-00 (Extended QoS |
| |along its path in the network. |Authorization for the QoS NSLP), July 2004 |
| | |draft-ietf-nsis-qos-nslp-04 (NSLP for |
| | |Quality-of-Service signaling), July 2004 |
| | | |
| | | |
| | | |
| | |RFC 2386 (Framework for QoS Routing), August 1998 |
| | | |
| | |RFC 2676 (QoS Routing), August 1999 |
| |QoS and Routing | |
| | | |
| | | |
| |Framework | |
| | |RFC 2330 (Framework for IP Performance Metrics) |
| | |RFC 3432 (Network performance measurement with periodic|
| | |streams) |
| |QoS Routing Mechanisms and OSPF Extensions| |
| |describes extensions to the OSPF protocol | |
| |to support QoS routes. | |
| | | |
| | | |
| | | |
| |QoS and Measurement | |
|Information Assurance |
|DoD IA |DoD IA Policy Framework |8510 - Certification and Accreditation |
| | |DoDD 8510.aa “DoD C&A” |
| | |DoD 8510.1-M “DITSCAP DoDI 8510.bb “DITSCAP |
| | |Implementation” |
| | | |
| | |8520 - Security Management (SMI, PKI, KMI, EKMS) |
| | |DoDI “Communications Security” (COMSEC)” |
| | | |
| | |8530 - Computer Network Defense /Vulnerability Mgt |
| | |DoDI O- “DoD Vulnerability Management” |
| | | |
| | |8540 - Interconnectivity/Multi-Level Security (SABI) |
| | |DoDI 8540.aa “Interconnection & Data Transfer Between |
| | |Security Domains” |
| | | |
| | |8550 - Network/Web (Access, Content, Privileges) |
| | |DoDD 8550.aa “Web Site Administration” |
| | |DoD 8550.bb-G “Firewall Configuration” |
| | |DoDI 8550.dd “DoD Biometrics” |
| | | |
| | |8560 - Assessments (Red Team, TEMPEST Testing & |
| | |Monitoring) |
| | |DoDD 8560.aa “Information Assurance Monitoring and |
| | |Readiness Testing of DoD Telecommunications and |
| | |Information Systems” |
|Authentication/ |X.509 |RFC3709 (Internet X.509 Public Key Infrastructure: |
|Identification | |Logotypes in X.509 Certificates), February 2004 |
| | |RFC3739 (Internet X.509 Public Key Infrastructure: |
| | |Qualified Certificates Profile), March 2004 |
| | |FC3779 (X.509 Extensions for IP Addresses and AS |
| | |Identifiers), June 2004 |
| | |RFC3850 (Secure/Multipurpose Internet Mail Extensions |
| | |(S/MIME) Version 3.1 Certificate Handling), July 2004 |
|Key Distribution |IKE |RFC3664 (The AES-XCBC-PRF-128 Algorithm for the |
| | |Internet Key Exchange Protocol (IKE)), January 2004 |
| | |RFC3706 (A Traffic-Based Method of Detecting Dead |
| | |Internet Key Exchange (IKE) Peers), February 2004 |
| | | |
| | |RFC3734 (Extensible Provisioning Protocol (EPP) |
| | |Transport Over TCP), March 2004 |
| |TLS |RFC3749 (Transport Layer Security Protocol Compression |
| | |Methods), May 2004 |
|Secure Mobility |IPSec |RFC3776 (Using IPsec to Protect Mobile IPv6 Signaling |
| | |Between Mobile Nodes and Home Agents), June 2004 |
|Secure Directory |LDAP |RFC3829 (Lightweight Directory Access Protocol (LDAP) |
| | |Authorization Identity Request and Response Controls), |
| | |July 2004 |
|Network Management |
|Common Structure of Management | |RFC 3780 (SMIng-Next Generation SMI), May 2004 |
|Information (SMI) | |RFC 3781 (SMIng-Mappings to SNMP), May 2004 |
|Management Information Base |IPv6 MIBs |(DISR) RFC 2452 (IP Version 6 Management Information |
| | |Base for the Transmission Control Protocol), December |
| | |1998 |
| | |(DISR) RFC 2454 (IP Version 6 Management Information |
| | |Base for the User Datagram Protocol), December 1998 |
| | |RFC 2465 (Management Information Base for IP Version 6:|
| | |Textual Conventions and General Group), December 1998 |
| | |(DISR) RFC 2466 (Management Information Base for IP |
| | |Version 6: ICMPv6 Group), December 1998 |
| | |RFC 3595 (Textual Conventions for IPv6 Flow Label), |
| | |September 2003 |
| | | |
| | |RFC 2940 (Definitions of Managed Objects for COPS |
| | |Protocol Clients), October 2000 |
| |Other MIBs |RFC 3747 (The Differentiated Services Configuration |
| | |MIB), April 2004 |
| | |RFC3812 (MPLS Traffic Engineering (TE) MIB), June 2004 |
| | |RFC 3813 (MPLS Label Switching Router (LSR) MIB), June |
| | |2004 |
| | |RFC 3814 (MPLS) Forwarding Equivalence Class To Next |
| | |Hop Label Forwarding Entry (FEC-To-NHLFE) MIB), June |
| | |2004 |
| | |RFC 3816 (Definitions of Managed Objects for RObust |
| | |Header Compression (ROHC)), June 2004 |
| | |RFC3873 (Stream Control Transmission Protocol (SCTP) |
| | |Management Information Base (MIB)), September 2004 |
|Policy-Based Network Management|Common Policy Protocol |RFC 2748 (COPS), January 2000 |
| | |RFC 3084 (COPS Usage for Policy Provisioning, COPS-PR),|
| | |March 2001 |
| | | |
| |Common Structure of Policy Provisioning |RFC 3159 (Structure of Policy Provisioning Information,|
| |Information (SPPI) |SPPI), August 2001 |
| | | |
| |Policy Information Schema and Models |RFC 3060 (Policy Core Information Model Specification –|
| | |Version 1), February 2001 |
| | |RFC 3460 (Policy Core Information Model Extensions), |
| | |January 2003 |
| | |RFC 3585 (IPsec Configuration Policy Information |
| | |Model), August 2003 |
| | |RFC 3644 (Policy QoS Information Model), November 2003 |
| | |RFC 3670 (Information Model for Describing Network |
| | |Device QoS Datapath Mechanisms), January 2004 |
| | | |
| |Policy Information Base |RFC 3317 (Differentiated Services Quality of Service |
| | |Policy Information Base), March 2003 |
| | |RFC 3318 (Framework Policy Information Base), March |
| | |2003 |
| | |RFC 3571 (Framework Policy Information Base for Usage |
| | |Feedback), August 2003 |
| | |draft-ietf-ipsp-ipsecpib-10 (IPSec Policy Information |
| | |Base), April 2004 |
|Link Management |
|Handoff Across Heterogeneous |Manage mobile nodes including fast handoff|Dynamic Mobility Agents (DMA) Protocol, AMPS Protocol |
|Links |for highly dynamic wireless networks and |Design Document, CECOM MOSAIC Project, Contract |
| |efficient location update for highly |DAAB07-01-C-L534, May 19, 2002 |
| |mobile nodes | |
| | |Domain Announcement Protocol (DAP) |
|Location Management | |RFC3680 (A Session Initiation Protocol (SIP) Event |
| | |Package for Registrations), March 2004 |
| | |RFC3825 (Dynamic Host Configuration Protocol Option for|
| | |Coordinate-based Location Configuration Information), |
| | |July 2004 |
|Registration | |RFC3840 (Indicating User Agent Capabilities in the |
| | |Session Initiation Protocol (SIP)), August 2004 |
|Establish and Maintain Channels|Signaling to establish, maintain and |Draft-ietf-ccamp-lmp-10 (Link Management Protocol |
| |recover paths; determination of route and |(LMP)), October 2003 |
| |properties of a path; link or node removal|Draft-ietf-ccamp-gmpls-g709-07 (Generalized MPLS |
| |from network |Signalling Extensions for G.709 Optical Transport |
| | |Networks Control), March 2004 |
| | |Draft-ietf-ccamp-gmpls-recovery-functional-02 |
| | |(Generalized MPLS Recovery Functional Specification), |
| | |April 2004 |
| | |Draft-ietf-ccamp-gmpls-segment-recovery-00 (GMPLS Based|
| | |Segment Recovery), April 2004 |
| | |Draft-ietf-ccamp-gmpls-recovery-analysis-03 (Analysis |
| | |of Generalized Multi-Protocol Label Switching |
| | |(GMPLS)-basedRecovery Mechanisms (including Protection |
| | |and Restoration)), April 2004 |
| | |Draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01 |
| | |(RSVP-TE Extensions in support of End-to-End |
| | |GMPLS-based Recovery), May 2004 |
| | |Draft-ali-ccamp-mpls-graceful-shutdown-00 (Graceful |
| | |Shutdown in MPLS Traffic Engineering Networks), June |
| | |2004 |
| | |Draft-rabbat-fault-notification-protocol-05 (Fault |
| | |Notification Protocol for GMPLS-Based Recovery), June |
| | |2004 |
| | |Draft-vasseur-ccamp-te-router-info-00 (Routing |
| | |extensions for discovery of TE router information), |
| | |July 2004 |
| | |Draft-huang-gmpls-recovery-resource-sharing-00 |
| | |(Generalized MPLS Recovery Resource Sharing), July 2004|
|Topology |Topology Dissemination |RFC 3684 (Topology Dissemination – Reverse Path |
| | |Forwarding), February 2004 |
| | | |
| |Dynamic Topology Changes |Draft-xushao-ipo-mplsovergmpls-02 (Requirements for |
| | |MPLS over GMPLS-based Optical Networks (MPLS over |
| | |GMPLS), May 2004 |
|Service, Node and Path | |RFC3810 (Multicast Listener Discovery Version 2 (MLDv2)|
|Discovery | |for IPv6), June 2004 |
| | |RFC3832 (Remote Service Discovery in the Service |
| | |Location Protocol (SLP) via DNS SRV), July 2004 |
| | |Draft-daigle-snaptr-01 (Domain-based Application |
| | |Service Location Using SRV RRs and the |
| | |DynamicDelegation Discovery Service (DDDS)), June 2004 |
| | |Draft-daniel-manet-dns-discovery-globalv6-00 (DNS |
| | |Discovery for global connectivity in IPv6 Mobile Ad Hoc|
| | |Networks), March 2004 |
| | |Draft-ietf-ipv6-2461bis-00 (Neighbor Discovery for IP |
| | |version 6 (IPv6)), July 2004 |
| | |Draft-ietf-eap-netsel-problem-01 (Network Discovery and|
| | |Selection Problem), July 2004 |
|Network Services |
|Name Resolution Service | |RFC 3363 (IPv6 Address Representation in DNS), August |
| | |2002 |
| | |(DISR)- RFC 3596 (DNS Extensions to Support IPv6), |
| | |October 2003 |
| | |draft-daniel-manet-dns-discovery-globalv6-00 (DNS |
| | |Discovery for global connectivity in IPv6 Mobile Ad Hoc|
| | |Networks), March 2004 |
|Configuration Management | |RFC 3646 (DHCP for IPv6), December 2003 |
| | |RFC 3736 (Stateless DHCP for IPv6), April 2004 |
| | |RFC 3825 (DHCP Option for Location-Based |
| | |Configuration), July 2004 |
|Automatic Configuration and |Distribute network configuration |Dynamic Registration and Configuration Protocol (DRCP),|
|Reconfiguration |information (e.g., IP addresses, DNS |AMPS Protocol Design Document, CECOM Multifunctional |
| |server) within a subnetwork; update |On-the-move Secure Adaptive Integrated Communications |
| |configuration database |(MOSAIC) Project, Contract DAAB07-01-C-L534, May 19, |
| | |2002 |
| | |Draft-boucadair-netconf-req-00 (Requirements for |
| | |Efficient and Automated Configuration Management), July|
| | |2004 |
| | |Draft-ietf-netconf-prot-03 (NETCONF Configuration |
| | |Protocol), June 2004 |
| | |draft-jelger-manet-gateway-autoconf-v6-02 (Gateway and |
| | |address autoconfiguration for IPv6 adhoc networks), |
| | |April 2004 |
| | |draft-jeong-manet-addr-autoconf-reqts-02 (Requirements |
| | |for Ad Hoc IP Address Autoconfiguration), July 2004 |
| |Distribute network configuration |Dynamic Configuration Distribution Protocol (DCDP), |
| |information to subnetworks |AMPS Protocol Design Document, CECOM MOSAIC Project, |
| | |Contract DAAB07-01-C-L534, May 19, 2002 |
| |Collect node configuration and capability |Configuration Database Update Protocol (YAP), AMPS |
| |information |Protocol Design Document, CECOM MOSAIC Project, |
| | |Contract DAAB07-01-C-L534, May 19, 2002 |
| |Select nodes to perform link management |Adaptive Configuration Manager (ACM) , AMPS Protocol |
| |and network services functions |Design Document, CECOM MOSAIC Project, Contract |
| | |DAAB07-01-C-L534, May 19, 2002 |
| | |Adaptive Configuration Agent (ACA), AMPS Protocol |
| | |Design Document, CECOM MOSAIC Project, Contract |
| | |DAAB07-01-C-L534, May 19, 2002 |
|Network Time | | |
3. Areas for Further Development
Table 9-3. AN Technical Standards Gaps
|Standards Area |Description/Discussion |Status |
|Connectivity |
|Routing Protocol for |By extending and building off a wired |Several draft RFCs have been prepared that describe |
|Heterogeneous (Wired and |routing protocol framework, the |potential wireless extension to OSPF |
|Wireless) Environments |probability of successful transition and | |
| |interoperability within heterogeneous | |
| |(fixed wired and ad hoc wireless) networks| |
| |may be greatly improved. | |
|Mobile Ad Hoc Routing |There is extensive work on mobile ad hoc |draft-ietf-manet-odmrp-04 (On-Demand Multicast Routing |
| |routing (shown in rightmost column) for |Protocol; Draft Expired-no subsequent RFC) |
| |which there are no immediate |draft-ietf-manet-maodv-00 (Multicast AODV Protocol; |
| |standardization plans. |Draft Expired; no subsequent RFC) |
| | |draft-ietf-manet-rdmar-00 (Relative Distance |
| | |Micro-discovery Ad Hoc Routing Protocol); Draft |
| | |Expired; no subsequent RFC) |
| | |draft-ietf-manet-tora-spec-04 (Temporally-Ordered |
| | |Routing Algorithm (TORA) Version 1; Draft Expired; no |
| | |subsequent RFC) |
| | |draft-ietf-manet-zone-zrp-04 (The Zone Routing Protocol|
| | |(ZRP) for Ad Hoc Networks; Draft Expired; no subsequent|
| | |RFC) |
| | |draft-ietf-manet-star-00 (Source Tree Adaptive Routing |
| | |(STAR) Protocol; Draft Expired; no subsequent RFC) |
| | |draft-ietf-manet-admr-00 (The Adaptive Demand-Driven |
| | |Multicast Routing Protocol for Mobile Ad Hoc Networks; |
| | |Draft Expired; no subsequent RFC) |
| | |draft-ietf-manet-cedar-spec-00 (Core Extraction |
| | |Distributed Ad hoc Routing Specification; Draft |
| | |Expired; no subsequent RFC) |
| | |draft-ietf-manet-cbrp-spec-01 (Cluster Based Routing |
| | |Protocol; Draft Expired; no subsequent RFC) |
| | |draft-ietf-manet-longlived-adhoc-routing-00 (Long-lived|
| | |Ad Hoc Routing based on the Concept of Associativity; |
| | |Draft Expired; no subsequent RFC) |
| | |draft-jeong-umr-manet-00 (Unicast Routing based |
| | |Multicast Routing Protocol for Mobile Ad Hoc Networks; |
| | |Draft Expired; no subsequent RFC) |
|Quality of Service |QoS and Routing |draft-perkins-manet-aodvqos-01 (Quality of Service for |
| | |Ad hoc On-Demand Distance Vector Routing; Draft |
| | |Expired; no subsequent RFC) |
| | | |
| | | |
| | | |
| |QoS and Resource Reservation |draft-pan-bgrp-framework-00 (Draft expired; no |
| | |subsequent RFC) |
| |BGRP: A Framework for Scalable Resource | |
| |Reservation. The Border Gateway | |
| |Reservation Protocol (BGRP) is used for | |
| |inter-domain resource reservation that can| |
| |scale in terms of message processing load,| |
| |state storage and control message | |
| |bandwidth. | |
| | |draft-nguyen-rap-cops-sls-03 |
| |QoS and Dynamic SLAs/SLSs |(Draft expired; no subsequent RFC) |
| | | |
| |COPS Usage for SLS negotiation (COPS-SLS) | |
| |is a protocol for supporting Service Level| |
| |Specification (SLS) negotiation. |draft-tequila-sls-03 |
| | |(Draft expired; no subsequent RFC) |
| | | |
| |Attributes of a Service Level | |
| |Specification (SLS) Template depicts a | |
| |standard set of information to be | |
| |dynamically negotiated between a customer | |
| |and an IP service provider or between | |
| |service providers, by means of |draft-somefolks-sls-00 |
| |instantiated Service Level Specifications |(Draft expired; no subsequent RFC) |
| |(SLS). | |
| | | |
| | | |
| |Service Level Specification for | |
| |Inter-domain QoS Negotiation describes a | |
| |structure for defining Service Level | |
| |Specifications for QoS negotiation over IP| |
| |networks. The high level schema described | |
| |in this document is intended for use |N. Schult, M. Mirhakkak |
| |during the process of QoS negotiation |and D. Thomson. A New Approach for Providing Quality of|
| |between a customer entity and a provider |Service in Dynamic Network Environment. |
| |entity. | |
| | |tech_papers99_00/thomson_mp_ |
| |QoS and Signaling: |dynamic/thomson_dynamic.pdf. |
| | | |
| |DRSVP aims to overcome the shortcomings of| |
| |RSVP in terms of QoS adaptation. By | |
| |treating a reservation as a request for | |
| |service somewhere within a range, | |
| |flexibility needed to deal with network |draft-ietf-manet-insignia-01 |
| |dynamics is gained. As available resources|(Draft expired; no subsequent RFC) |
| |change, the network can readjust | |
| |allocations within the reservation range. | |
| | | |
| | | |
| |INSIGNIA (protocol) is the first QoS | |
| |signaling protocol specifically designed | |
| |for resource reservation in ad hoc | |
| |environments. It supports in-band | |
| |signaling by adding a new option field in | |
| |IP header called INSIGNIA to carry the | |
| |signaling control information. The | |
| |INSIGNIA module is responsible for | |
| |establishing, restoring, adapting, and | |
| |tearing down real-time flows. It includes | |
| |fast flow reservation, restoration and | |
| |adaptation algorithms that are | |
| |specifically designed to deliver adaptive | |
| |real-time service in | |
| |MANETs. If the required resource is | |
| |unavailable, the flow will be degraded to |draft-salsano-bgrpp-arch-00 |
| |best-effort service. QoS reports are sent |(Draft expired; no subsequent RFC) |
| |to source node periodically to report | |
| |network topology changes, as well as QoS | |
| |statistics (loss rate, delay, and | |
| |throughput) | |
| | | |
| |Inter-domain QoS Signaling: the BGRP Plus | |
| |Architecture describes a scalable | |
| |inter-domain resource control architecture| |
| |for DiffServ networks. The architecture is| |
| |called BGRP Plus, as it extends the | |
| |previously proposed BGRP framework |G. Ahn, A. T. Campbell, A. Veres, and L.-H. Sun, “SWAN:|
| |(draft-pan-bgrp-framework-00.txt). |Service Differentiation in Stateless Wireless Ad-hoc |
| | |Networks”, Proc. IEEE Infocom, pp. 457-466, June 2002. |
| | | |
| |QoS and Frameworks for Wide-Area Ad-Hoc |draft-ahn-swan-manet-00 (Service Differentiation in |
| |Networks |Stateless Wireless Ad-hoc Networks; Draft Expired; no |
| | |subsequent RFC) |
| | | |
| | | |
| | | |
| |SWAN is a stateless network model | |
| |which uses distributed control algorithms | |
| |to deliver service differentiation in | |
| |mobile wireless ad hoc networks in a | |
| |simple, scalable and robust manner. SWAN | |
| |uses explicit congestion notification | |
| |(ECN) to dynamically regulate admitted | |
| |realtime traffic in the face of network | |
| |dynamics brought on by mobility or traffic| |
| |overload conditions. |H. Xiao, W. K.G. Seah, A. Lo, and K. Chaing “Flexible |
| | |QoS Model for Mobile Ad-hoc Networks”, IEEE Vehicular |
| | |Technology Conference, Vol. 1, pp 445-449, Tokyo, |
| |The Flexible QoS Model for MANET (FQMM) is|Japan, |
| |based both on |May 2000. |
| |IntServ and Diffserv. Applications with | |
| |high priority, use the per-flow QoS | |
| |guarantees of IntServ. Applications with | |
| |lower priorities achieve DiffServ | |
| |per-class differentiation. | |
| | |S. Lee, G. Ahn, X. Zhang, and A. T. Campbell, |
| | |“INSIGNIA: |
| |The INSIGNIA QoS framework supports |An IP-Based QoS framework for Mobile Ad-hoc Networks”, |
| |adaptive services that can provide base |Journal of Parallel & Distributed Computing, Vol. 60, |
| |QoS (i.e., minimum bandwidth) assurances |No. |
| |to real-time voice and video flows and |4, pp 374-406, April 2000. |
| |data, allowing for enhanced levels (i.e., | |
| |maximum bandwidth) of service to be | |
| |delivered when resources become available.| |
| |INSIGNIA is designed to adapt user | |
| |sessions to the available level of service| |
| |without explicit signaling between | |
| |source-destination pairs. | |
| | | |
| | | |
| |The PYLON framework views a mobile | |
| |multihop network as a network that needs |Y. L. Morgan and T. Kunz, |
| |to cling to a fixed access network in |“PYLON: An Architectural Framework for Ad-hoc QoS |
| |order to gain access to the rest of the |Interconnectivity with Access Domains”, Proceedings of |
| |world. The hosting access network is |the 36th Hawaii International Conference on System |
| |expected to provide the mobile multihop |Sciences (HICSS’03) |
| |network with suitable Service Level | |
| |Agreement (SLA), Traffic Conditioning | |
| |Agreement (TCA), and service provisioning | |
| |policies. This | |
| |framework uses aggregate RSVP signaling to| |
| |perform | |
| |inter-domain resource reservation. | |
| | | |
| |iMAQ is a cross-layer architecture to | |
| |support the transmission of multimedia | |
| |data over a mobile multihop network. Hard | |
| |QoS guarantees cannot be provided and |iMAQ: An integrated mobile ad hoc QoS framework. |
| |resources are not reserved. The framework |. |
| |involves the network layer (an ad hoc | |
| |routing layer) and a middleware service | |
| |layer. At each mobile node, these two | |
| |layers share information and collaborate | |
| |to provide QoS assurances to multimedia | |
| |traffic. |. |
| | | |
| |MMWN (Multimedia support for Mobile | |
| |Wireless Network) system consists of | |
| |adaptive link and network algorithms to | |
| |support quality of service in large, | |
| |multihop mobile wireless network. MMWN | |
| |consists of modular system of distributed,| |
| |adaptive algorithms at link and network |R. Ramanathan and M. Steenstrup. Hierarchically |
| |layer. The key features of the system are:|organized, multihop mobile wireless networks for |
| |adaptive control of link quality; |quality of service support. Mobile Networks and |
| |hierarchical organization; routing with |Applications, |
| |quality of service; and autonomous repair |3(1):110–119, 1996. |
| |of multipoint virtual circuit with | |
| |resource reservations. | |
| | | |
| |AQuaFWiN architecture has used several | |
| |concepts such as hierarchical | |
| |organization, adaptive power control from | |
| |existing architectures. The key | |
| |distinguishing feature of the proposed | |
| |architecture is the generic feedback | |
| |mechanism which can be used to achieve | |
| |adaptability at different layers of the | |
| |network. | |
| | |Bobby Vandalore, Raj Jain, Sonia Fahmy, Sudhir Dixit |
| | |AQuaFWiN: Adaptive QoS Framework for Multimedia in |
| | |Wireless Networks |
| | |and its Comparison with other QoS Frameworks, 1999 |
|Information Assurance |
|Security Architecture for |The AN must be able to operate when |A number of different security constructs exist that |
|Secure Management Transactions |disconnected from terrestrially-based |can be applied to today’s wire-line NM transactions, |
| |services making application of current |including public key technologies, security protocols |
| |security approaches difficult, if not |including IPSec enabled virtual private networks (VPN),|
| |impossible, to implement. The AN |Transport Layer Security (TLS), Secure Socket Layer |
| |architecture in general, and the NM |(SSL), as well as protocols with built-in security |
| |Architecture in particular, must be |features, such as the SNMPv3 User Security Module. |
| |capable of securing administrative |These approaches were designed upon the premise that |
| |transactions over a disconnected, |dedicated, terrestrial-based security resources would |
| |dynamically changing network. |be available to support these security services. |
|Network Management |
|Service Advertisement and |To support the spontaneous, self-forming |Proprietary and standards-based solutions for automated|
|Discovery Mechanisms |features of the AN, the network management|service discovery exist for fixed, wire-line networks |
| |architecture will require autonomous |(Service Location Protocol, Salutation Protocol, etc). |
| |election of cluster managers and |However, these most likely would not be appropriate for|
| |advertisement/discovery of those managers |dynamic topology networks. One issue is the problem of|
| |within the network. A service |broadcast flooding over dynamic topology networks with |
| |advertisement mechanism enables nodes with|bandwidth-constrained links. The selected service |
| |NM/PBNM services to announce themselves, |discovery methods would need to constrain the broadcast|
| |while a service discovery process enables |function in some fashion to avoid redundant flooding |
| |nodes seeking NM/PBNM services to locate |and inefficient use of bandwidth resources. Some |
| |NM/PBNM servers. Both of these features |potential options include use of MANET multicast and/or|
| |enable the NM Architecture to adapt to the|constrained (hop-limited) broadcasts. |
| |network’s dynamic topology changes. | |
|Clustering Protocol for |The main concept behind cluster management|Various recent research endeavors have proposed cluster|
|Management of Dynamic Topology |is to convert a traditionally centralized |management schemes. However, none of these have been |
|Networks |process into a semi-distributed process |formally implemented, nor evaluated against the |
| |that adapts to dynamic network challenges.|particular attributes (relative node speed, cluster |
| |The performance objective in selection of |density, mobility characteristics) of a military |
| |clusters is to minimize protocol overhead |airborne network. |
| |between client and server while maximizing| |
| |management service availability. | |
| |Selection of cluster size is an important | |
| |parameter in forming and maintaining | |
| |clusters. Clusters that are too large | |
| |suffer from an excess of (NM/PBNM) message| |
| |overhead due to collection of data from a | |
| |large number of clients. Networks with | |
| |clusters that are too small suffer from an| |
| |excess of overhead in cluster maintenance | |
| |traffic. Factors that impact selection of| |
| |clusters include, among others, relative | |
| |node speed, cluster density, mobility | |
| |characteristics, etc. | |
|Policy Based Network Management|Policy Information Base |draft-ietf-rap-acct-fr-pib-01 (Framework of COPS-PR |
| | |Policy Information Base for Accounting Usage; Draft |
| | |Expired; no subsequent RFC) |
| | |draft-rawlins-rsvppcc-pib-02 (RSVP Policy Control |
| | |Criteria PIB; Draft Expired; no subsequent RFC) |
| | |draft-jacquenet-fwd-pib-00 (An IP Forwarding Policy |
| | |Information Base; Draft Expired; no subsequent RFC) |
| | |draft-jacquenet-ip-te-pib-02 (An IP Traffic Engineering|
| | |Policy Information Base; Draft Expired; no subsequent |
| | |RFC) |
| | |draft-li-rap-mplspib-00 (MPLS Traffic Engineering |
| | |Policy Information Base; Draft Expired; no subsequent |
| | |RFC) |
| | |draft-otty-cops-pr-filter-pib-00 (A Filtering Policy |
| | |Information Base (PIB) for Edge Router Filtering |
| | |Service and Provisioning via COPS-PR; Draft Expired; no|
| | |subsequent RFC) |
|Link Management |
|Node Advertisement and | |The Ad-Hoc Mobility Protocol Suite (AMPS) consisting of|
|Discovery Mechanisms | |Dynamic Registration and Configuration Protocol (DRCP),|
| | |Dynamic Configuration Distribution Protocol (DCDP), |
| | |Configuration Database Update Protocol (YAP) and |
| | |Adaptive Configuration Agent (ACA) developed for the |
| | |CECOM Multifunctional On-the-move Secure Adaptive |
| | |Integrated Communications (MOSAIC) Project provides |
| | |many of the desired functionality. |
|Node Admission Control | | |
|Handoff Across Heterogeneous | |Dynamic Mobility Agents (DMA) Protocol and Domain |
|Links | |Announcement Protocol (DAP) developed for the MOSAIC |
| | |Project provide many of the desired functionality. |
|Link Resource Provisioning | | |
|Node and Link Real-Time | | |
|Performance Monitoring and | | |
|Evaluation | | |
|Network Topology Optimization | | |
|Link Management Architecture | | |
|and Transactions | | |
|Network Services |
|Name Resolution Service | |draft-engelstad-manet-name-resolution-01 (Name |
| | |Resolution in on-demand MANETS and over external IP |
| | |Networks; Draft Expired; no subsequent RFC) |
| | |draft-jeong-manet-dns-service-00 (DNS Service for |
| | |Mobile Ad Hoc Networks; Draft Expired; no subsequent |
| | |RFC) |
| | |draft-park-manet-dns-discovery-globalv6-00 (DNS |
| | |Discovery for global connectivity in IPv6 Mobile Ad Hoc|
| | |Networks; Draft Expired; no subsequent RFC) |
|Configuration Management | |draft-paakkonen-addressing-htr-manet-00 (IPv6 |
| | |addressing in a heterogeneous MANET-network; Draft |
| | |Expired; no subsequent RFC) |
| | |draft-perkins-manet-autoconf-01 (IP Address |
| | |Autoconfiguration for Ad Hoc Networks; Draft Expired; |
| | |no subsequent RFC) |
| | |draft-rantonen-manet-idaddress-dad-adhocnet-00 (IP |
| | |Address Autoconfiguration with DAD minimization for Ad |
| | |Hoc Networks; Draft Expired; no subsequent RFC) |
|Service Discovery | |draft-koodli-manet-servicediscovery-00 (Service |
| | |Discovery in On-Demand Ad Hoc Networks; Draft Expired; |
| | |no subsequent RFC) |
|Network Time | |RFC 2030 (Simple NTP version 4), October 1996 |
| | |Khoa To and James Sasitorn; N.A.M.E: The Network Time |
| | |Protocol for Ad Hoc Mobile Environments; Computer |
| | |Science Department Rice University Houston, Texas |
10. AN Architecture Issues
Table 10-1. AN Architecture Issues
|ID |Issue |Description/Discussion |Status |
|Connectivity |
|CN1 |Network and Link Stability |How much network stability is needed in terms of throughput, | |
| | |latency, loss, and error rates to support AF mission traffic and | |
| | |ensure needed performance guarantees? What functions are required| |
| | |to provided the needed stability? Are there any AF mission | |
| | |traffic types that should not be supported with an IP-based | |
| | |network, today, in the interim, in the target (consider efficiency| |
| | |as well as network performance)? How should application and | |
| | |networking protocols be adapted to accommodate link instability? | |
|CN2 |Directional Links |What channel access mechanisms are most appropriate for ad hoc | |
| | |networks that combine directional and omni directional elements | |
| | |(a.k.a. directional ad hoc networks)? How should one initiate and| |
| | |maintain a network topology in directional ad hoc networks? What | |
| | |routing algorithms are necessary for standard (unicast), | |
| | |high-assurance, and multipoint data delivery services in | |
| | |directional ad hoc networks? | |
|CN3 |Network and Link Handoffs |What functions are required to perform seamless/near seamless | |
| | |radio handoffs? What functions are required to ensure | |
| | |uninterrupted network connectivity as platforms move through | |
| | |several different subnets? | |
|CN4 |Routing |The Airborne Network must deliver a set of routing protocols that | |
| | |can be run on all platforms which are dynamic enough to | |
| | |accommodate rapid topological changes while maintaining efficiency| |
| | |with respect to bandwidth consumption from routing information | |
| | |exchanges. The routing protocols should be capable of intelligent| |
| | |routing decisions by taking into account such things as link | |
| | |characteristics (e.g. capacity and error rate of a particular | |
| | |radio subnet), number of hops, traffic requirements (e.g. | |
| | |delay-sensitivity, precedence levels), etc. | |
|CN5 |QoS |The Airborne Network must have a consistent approach to providing |DISA is defining a GIG |
| | |Quality of Service (QoS) across the AN constellation. It is |QoS architecture; |
| | |necessary to specify the protocols that will be employed, and |however, it is unknown if|
| | |describe the roles that various network elements are expected to |it will be suitable for |
| | |play. These roles include such things as initiating resource |the AN. |
| | |reservations, classifying and tagging IP packets, providing | |
| | |prioritized queuing mechanisms, responding to requests for | |
| | |resource reservations, etc. | |
|CN6 |Real-Time Traffic |What standards should be used for voice (VoIP), video (video over |DISA is defining a VoIP |
| | |IP), and circuit emulation? |standard implementation. |
|CN7 |GIG Integration |The Airborne Network must interface to and be integrated with | |
| | |other Service and Joint networks. An AN service delivery point | |
| | |(SDP) Interface definition is needed to indicate how the AN would | |
| | |interface with the GIG and other peer-networks? | |
|CN8 |IP Convergence |The most difficult part of implementing converged IP-based |Enterprise management in |
| | |networks will be addressing the performance management of |industry today focuses on|
| | |end-to-end flows which transit nodes in the infrastructure with |single enterprises, |
| | |extreme changes in bandwidth, heavy congestion, long latencies, |single technology groups,|
| | |and the inherent difficulties of mobile tactical environments. |and single communities of|
| | | |interest. There is an |
| | | |absence of tools and |
| | | |technologies for |
| | | |real-time management |
| | | |across networks, |
| | | |particularly in the area |
| | | |of real-time |
| | | |configuration and |
| | | |performance. |
|Information Assurance |
|IA1 |DoD and Service IA Policy |Existing policy doesn't adequately address operations in a | |
| | |wireless or wireless ad hoc network environment. | |
|IA2 |HAIPE Specification and |A core the High Assurance IP Interoperability Specification |GIG E2E Working Group and|
| |Interoperability |(HAIPIS) is being developed. However, a lightweight and |HAIPE Working Group is |
| | |potentially other variants of HAIPIS are also being developed to |baselining HAIPISv2 and |
| | |accommodate different operational environments. Lack of |defining modules that may|
| | |interoperability between HAIPE variants, including between |accompany HAIPISv2. NSA |
| | |wireless and wired HAIPE devices, will impact interoperability. |is working to baseline |
| | | |HAIPIS Lite requirements.|
|IA3 |Encryption Processing Speeds|HAIPE, TRANSEC, and other encryption device data processing speeds|NSA has seeded industry |
| | |may not keep pace with required network throughput speeds. |with funding to develop |
| | | |high speed HAIPE devices.|
|IA4 |Crypto Modernization |CMI may not deliver the high assurance algorithms, keys, and |DoD Research Area -- |
| |Initiative |hardware products when needed to support wireless and laser based |identify algorithms and |
| | |packet and/or circuit switched networks. |emcryption key products |
| | | |needed to support near, |
| | | |mid, and long term |
| | | |wireless IP capability. |
|IA5 |Protocol Security |Not all protocols have built-in security or have minimal built-in | |
| | |security. Many protocols [i.e., OSPF, SNMP, BGP] rely on | |
| | |ubiquitous shared secrets and/or only provide limited integrity or| |
| | |authentication checking. Few provide data confidentiality. | |
|IA6 |DoD PKI Integration |DoD PKI supports authenticating and identifying humans, devices, |Services collaborated and|
| | |and information. However, effective PKI use requires continuous |developed DoD Tactical |
| | |connectivity to the PKI. Current design is terrestrially based |Function Requirements |
| | |and has little support for the tactical environment and no support|Document (FRD) that |
| | |for the ad hoc network. Issues that must be resolved include |identifies delta between |
| | |certificate management and validation over bandwidth constrained |current PKI ORD needs and|
| | |networks and employment of PK services when disconnected from the |extending PKI to the |
| | |GIG infrastructure. Care must be taken to ensure that use of PK |tactical environment. |
| | |services for the AN doesn’t become a single point of failure. | |
| | | | |
| | |Other, related issues are the applicability of current certificate| |
| | |design to non fixed IP or domain name devices; usability of | |
| | |identity certificates to support implementation of role based | |
| | |access control systems; and adequacy of DoD PKI trust model. DoD | |
| | |and service timeline to develop tactical solutions are unknown. | |
|IA7 |Key Management |Current EKMS is predominately manual. Emerging EKMS capability is|HAIPE is working towards |
| | |moving towards increased automation. Large numbers of wireless |automated over-the-air |
| | |devices and [potentially] different subnets will drive EKMS |rekey. OTNK [Over the |
| | |solutions plus make manual key delivery impractical. Need to |Network Keying] is yet to|
| | |define AN EKMS requirements in terms of operational employment [ad|be developed; however, a |
| | |hoc, non-ad hoc and anchored, non-anchored networking] and need |OTNK pilot is underway. |
| | |timeline. | |
| | |AN entities will need to support OTAR, OTNK, OTAZ, and OTAT. | |
|IA8 |Access Control |Devices will be managed and maintained by entities that may be | |
| | |local or remote to the device itself. Level of entity access to a| |
| | |device will be based on the entity's role in relation to that | |
| | |device [can manage, can operate, can monitor, etc.] The security | |
| | |impacts of centralized versus distributed and unified versus | |
| | |federated management systems needs to determined. | |
|IA9 |Authentication |Nodes [AN, management, humans, etc.] will need to be authenticated| |
| | |by devices and/or networks [dependent on the activity to be | |
| | |accomplished.] The functional layer at which the authentication | |
| | |will occur, how it will be managed, and how the authentication | |
| | |state will transfer through the AN needs to determined. | |
|IA10 |Intrusion Detection System |How IDS and IPS will operate in the AN environment must be | |
| |(IDS) and Intrusion |determined, including whether these functions are distributed | |
| |Prevention Systems (IPS) |throughout all nodes or centralized at specific nodes. How data | |
| | |aggregation and response will be accomplished. What response time| |
| | |is needed and reasonable? What is the impact of operating in an | |
| | |ad hoc network? Should these functions be network centric and | |
| | |interoperate between devices or device centric? | |
|IA11 |Compromise and Compromise |How will device compromise be detected? Once detected, how will AN| |
| |Recovery |nodes be informed of the compromise and how will recovery be | |
| | |accomplished? What is anticipated operational impact during a | |
| | |recovery phase? | |
|IA12 |Covert Channel |Various protocols may be more or less susceptible to use as a path| |
| | |to carry covert data. | |
|IA13 |Black or Unclassified |Unmanned terminals [relay nodes, UAV, etc.] will need operational |JTRS is implementing an |
| |Terminals |TRANSEC keys and may be queried for status data. Software, |unmanned relay node. |
| | |wrapped keys, and other code may exist in the terminal, that if |TCM has requirement for a|
| | |compromised, may have significant security implications. How will|black terminal. |
| | |device be maintained "black" while operational? |NSA has expressed concern|
| | | |over how terminal can |
| | | |remain black |
| | | |w/operational keys. |
|IA14 |MSLS and MLS. |AN will initially support multiple single levels of security and |JTRS is implementing MSLS|
| | |eventually support multiple level security. How will this support|through use of |
| | |be implemented and supported? |independent channel per |
| | | |security domain. |
|IA15 |Allied/Coalition Security |Mixed U.S., coalition, and allied operations will require ability | |
| |Environment |to operate across multiple security domains, using mixed | |
| | |encryption and TRANSEC algorithms and keys, interacting with U.S. | |
| | |and non-U.S. public key infrastructures. | |
|IA16 |Interoperability with Other |AN security infrastructure and protocols must interoperate with | |
| |Networks |infrastructures and protocols implemented to support other | |
| | |networks [e.g., GIG, tactical ground, fixed terrestrial, etc.] | |
| | |Hierarchical or layered IA functions must interoperate with their | |
| | |logical peers on other networks. | |
|IA17 |Operations, Management, and |System configuration, link and network management data, device | |
| |Control Data Integrity and |code updates, etc. must have source and integrity validated before| |
| |Validity |receiving entities operationally employ it. | |
|IA18 |Operation over Wireless |Traffic flow security, as implemented by the High Assurance |The HAIPIS Working Group |
| |Links |Internet Protocol Encryptor, have a performance impact. In a low |is seeking technological |
| | |speed link, TFS support may significantly impact overall user data|solutions that can be |
| | |throughput. |applied to the next |
| | | |generation of HAIPE |
| | | |devices enabling them to |
| | | |provide TFS while |
| | | |decreasing their wireless|
| | | |operational impact. |
|Network Management |
|NM1 |Efficiency |What efficiency improvements (e.g., compression, aggregation) can | |
| | |be implemented to reduce NM traffic? Transaction-intensive NM | |
| | |exchanges must be minimized (in frequency and size) to prevent | |
| | |high overhead. | |
|NM2 |Management of Multiple |The Airborne Network must be capable of the management of multiple| |
| |Network Security Levels |network security levels -- i.e., management of multiple security | |
| | |levels of red networks and a black network. An integrated, | |
| | |efficient solution is needed. | |
|NM3 |Management of Ad-Hoc | | |
| |Networks | | |
|NM4 |Integrated Network |What needs to be done to develop a unified NM capability for the | |
| |Management |AN when separate acquisitions (FAB-T, JTRS, MP-CDL) are | |
| | |implementing different NM and administrative domains ? What are | |
| | |the interface and integration requirements for providing | |
| | |integrated, inter-domain NM? Should there be a top-level NM or | |
| | |"Services Manager" (over TC, JTRS, MP-CDL constituents) for AN | |
| | |policy management, E2E provisioning, and AN Situational Awareness?| |
|NM5 |Policy Management |How can QoS Provisioning and Policy Based Network Management | |
| | |(policy distribution, enforcement, provisioning) be performed in a| |
| | |dynamic network composed of multiple separately managed links and | |
| | |subnets? | |
|Link Management |
|LM1 |Cross-Layer Approach |Determine how link management functions (e.g., topology | |
| | |management, admission control, QoS/CoS) may be implemented via | |
| | |cross-layer approach. Determine relative benefits and tradeoffs | |
| | |of physical, MAC, network and application layer techniques in | |
| | |combination with one another. | |
|LM2 |Link Discovery Protocols |Efficient link discovery/establishment protocols needed. | |
|LM3 |Dynamic Link Configuration |Which radio/terminal (layer 1 and 2) parameters are dynamically | |
| | |changeable? To what extent can these parameters be changed? | |
|LM4 |Measurement and reporting of|Which conditions are measurable, measurement techniques, | |
| |link conditions |measurement frequency, establishment of acceptable ranges, | |
| | |reporting thresholds? What parameters should be reported for | |
| | |each link type? | |
|LM5 |Topology Management |Determine tradeoffs between factors such as computation | |
| | |overhead, levels of hierarchal organization, optimal node power, | |
| | |desired connectivity, maximum data rate for links, vulnerability | |
| | |to jamming, network survivability, graceful performance | |
| | |degradation under dynamic changes. | |
|LM6 |Dynamic Resource |What are the protocols, approaches, technologies for dynamically | |
| |Provisioning |provisioning link resources for the AN? | |
|LM7 |Dynamic Network |What are the protocols, approaches, technologies for dynamically | |
| |Configuration |configuring network parameters throughout the AN? | |
|LM8 |Link Management of Ad Hoc |What are the protocols, approaches, technologies to leverage for | |
| |Networks |LM of ad hoc networks? | |
|Network Services |
|NS1 |IP Address Management |The Airborne Network must have a well-defined address management | |
| | |plan in place in order to handle the distribution of IP addresses | |
| | |to network elements on airborne platforms. The address management| |
| | |plan must be consistent across the entire AN constellation, and | |
| | |roles and responsibilities for each platform must be well defined.| |
| | |The address management plan must clearly identify when and how | |
| | |network elements will be assigned IP addresses. This includes the| |
| | |renumbering of network elements during operation. | |
|NS2 |Domain Name System (DNS) |The Airborne Network must have a consistent and robust approach to| |
| | |providing DNS services for nodes in the constellation. In order | |
| | |to do this, an operations model must be established that details | |
| | |such things as the location of DNS servers, redundancy plans, and | |
| | |the responsibility of specific platforms with respect to whether | |
| | |or not they provide DNS services for others in the AN | |
| | |constellation. | |
|NS3 |Mobility Management |In the Airborne Network mobility management will be needed to | |
| | |ensure that platforms can be located quickly and that packet | |
| | |delivery operates properly and without interruption as platforms | |
| | |move throughout the network. An integrated muli-layer, | |
| | |multi-transport system solution is needed. | |
|NS4 |Network Time Protocol |Currently Network Time Service is not a ubiquitous service across | |
| | |the GIG. Security directives prevent IP-based time | |
| | |synchronization across firewall boundaries (AFI 33-115, 16). | |
|General |
|G1 |Airborne Network Service |What is the minimum set of services required on an airborne NSP | |
| |Providers |node? What is required to ensure that an airborne NSP node | |
| | |failure or loss will not impact mission operations? | |
|G2 |Proxies |The use of proxies can improve the performance of user | |
| | |applications running across the AN by countering wireless network | |
| | |impairments, such as limited bandwidth, long delays, high loss | |
| | |rates, and disruptions in network connections. However, proxies | |
| | |performance can be impacted by the security and data link | |
| | |mechanism. An integrated muli-layer, multi-transport system | |
| | |solution is needed. | |
11. List of Acronyms
ACA Adaptive Configuration Agent
ACM Adaptive Configuration Manager
AETACS Airborne Elements of the Tactical Air Control System
AMPS Ad-Hoc Mobility Protocol Suite
AMTI Air Moving Target Indicator
AN Airborne Network
AOC Air and Space Operations Center
AS Autonomous System
ASWR Attack Sensing, Warning, and Response
ATO Air Tasking Order
AWACS Airborne Warning and Control System
BGP Border Gateway Protocol
BLOS Beyond Line-of-Sight
CAP Combat Air Patrol
CAS Close Air Support
CITS Combat Information Transport System
CLIP Common Link Interface Processor
CND Computer Network Defense
COIs Communities of Interest
CONOPS Concept of Operations
CONUS Continental United States
CoS Class of Service
C2ERA Command and Control Enterprise Reference Architecture
DAA Designated Approving Authority
DAP Domain Announcement Protocol
DCDP Dynamic Configuration Distribution Protocol
DHS Department of Homeland Security
DISN Defense Information System Network
DMA Dynamic Mobility Agents
DNS Domain Name System
DoD Department of Defense
DRCP Dynamic Registration and Configuration Protocol
ECU End Cryptographic Unit
EGP Exterior Gateway Protocol
EKMS Electronic Key Management System
EMCON Emission Control
FCAPS Fault, Configuration, Accounting, Performance, Security
FEC Forward Error Correction
GIG Global Information Grid
GIG-BE GIG-Bandwidth Expansion
GIG ES GIG Enterprise Services
GMTI Ground Moving Target Indicator
GNOSC Global Network Operations and Security Center
GPS Global Positioning System
GTACS Ground Tactical Air Control System
HAIPE High Assurance Internet Protocol Encryptor
HAIPIS High Assurance IP Interoperability Specification
HI Horizontal Integration
I&A Identity and Authentication
IA Information Assurance
IDS Intrusion Detection System
IFGR Information for Global Reach
IGP Interior Gateway Protocol
IPS Intrusion Prevention System
ISR Intelligence Surveillance and Reconnaissance
IT Information Technology
JWICS Joint Worldwide Intelligence Communications System
JV Joint Vision
KLIF Key Loading and Initialization Facility
KMA Key Management Architecture
KMI Key Management Infrastructure
LDAP Lightweight Directory Access Protocol
LM Link Management
LMA LM Agent
LMAMs LM Autonomous Managers
LME LM Executive
LMP Link Management Protocol
LOS Line of Sight
LPDP Local Policy Decision Point
LPI/LPD Low Probability of Interception/Detection
MANs Metropolitan Area Networks
MIB Management Information Base
MILS Multiple Independent Levels of Security
MLPP Multi-Level Precedence and Preemption
MLS Multi-level Security
MOSAIC Multifunctional On-the-move Secure Adaptive Integrated Communications
MPLS Multi-Protocol Label Switching
MPLS-TE Multi-Protocol Label Switching--Traffic Engineering
NASA National Aeronautics and Space Agency
NCW Network Centric Warfare
NESI Net-Centric Enterprise Solutions for Interoperability
NIPRNET Unclassified-but-Sensitive Internet Protocol Router Network
NIST National Institute of Standards and Technology
NM Network Management
NM Network Manager
NOC Network Operations Center
NSA National Security Agency
NSS National Security Systems
NTP Network Time Protocol
NTS Network Time Server
OANs Operational Area networks
OTAR Over-The-Air Rekeying
OTAT Over-The-Air Transfer
OTAZ Over-The-Air Zeroize
OTNK Over-The-Network Keying
PBNM Policy Based Network Management
PBSM Policy Based Security Management
PDP Policy Decision Point
PEP Policy Enforcement Point
PEP Performance Enhancing Proxy
PIB Policy Information Base
PIM Programmable INFOSEC Module
PKI Public Key Infrastructure
QoS Quality of Service
RF Radio Frequency
ROE Rules of Engagement
RSVP-TE Resource Reservation Protocol--Tunneling Extensions
RSVP-TE Resource Reservation Protocol – Traffic Engineering
SAR Synthetic Aperture Radar
SATCOM Satellite Communications
SDN Service Delivery Node
SDP Service Delivery Point
SEAD Suppression of Enemy Air Defenses
SIP Session Initiation Protocol
SIPRNET Secret Internet Protocol Router Network
SLA Service Level Agreement
SLCS Senior Level Communications System
SMI Security Management Infrastructure
SoM Strength of Mechanism
SoMI Structure of Management Information
SPPI Structure of Policy Provisioning Information
SPS Standard Positioning System
SSL Secure Socket Layer
TAP Traffic Analysis Protection
TCP Transmission Control Protocol
TCT Time Critical Targeting
TDC Theater Deployable Communications
TDL Tactical Data Link
TFS Traffic Flow Security
TLS Transport Layer Security
TPED Task, Process, Exploit, and Disseminate
TPPU Task, Post, Process, and Use
TRANSEC Transmission Security
TSAT Transformational Communications Satellite System
TS/SCI Top Secret/Sensitive Compartmented Information
TWSTT Two-Way Satellite Time Transfer
UAV Unmanned Aerial Vehicle
UDOP User Defined Operational Picture
USNO U. S. Naval Observatory
UTC Coordinated Universal Time
VoIP Voice over IP
VPN Virtual Private Networks
WAN Wide Area Network
YAP Configuration Database Update Protocol
12. References
1. B. Braden et al., Developing a Next-Generation Internet Architecture, July 2000
2. Airborne Network Architecture Progress Summary Version 1.0, USAF Airborne Network Special Interest Group, May 2004
3. Airborne Network Architecture Roadmap (Draft)
4. Airborne Network Technical Requirements Document Version 0.4, USAF Airborne Network Special Interest Group, 11 September 2003
5. Alberts, D. S., J. J. Gartska, and F. P. Stein., Network Centric Warfare: Developing and Leveraging Information Superiority, DoD C4ISR Cooperative Research Program, Washington, DC., 1999
6. Airborne Network (AN) Prioritization Plan, Headquarters USAF (AF/XICA), 31 March 2004
7. Operating Concept for C2 ConstellationNet Network Centric Infostructure, AFC2ISRC/SCY, 1 April 2004
8. Understanding Enterprise Network Design Principles, Cisco Systems, Inc, 2001
9. U.S. Air Force Infostructure Enterprise Architecture, Version 1.3, Air Force Communications Agency, 27 February 2004
10. U. S. Air Force Network Management Platform Profile, Version 0.9, Air Force Communications Agency, 5 December 2002
11. U. S. Air Force Network and Infrastructure Defense Platform Profile, Version 0.9, Air Force Communications Agency, 27 November 2002
12. U. S. Air Force Domain Name Service Profile, Version 1.0, Electronic Systems Center
13. (ESC/NI2), 23 February 2004
14. U. S. Air Force Network Time Service Profile, Version 1.0, Electronic Systems Center
15. (ESC/NI2), 28 January 2004
16. Framework for QoS-based Routing in the Internet, RFC 2386, IETF Network Working Group, August 1998
17. “Quality of Service - Glossary of Terms”, , May 1999
18. Proposed Draft Strawman DSCP Mapping for GIG Enterprise IP Networks Version 11p, DoD GIG QoS/CoS Working Group, 22 March 2004
19. Guidelines for Improved Applications Performance over Networks, Defense Information Systems Agency, 11 April 2003
20. Blaine, D., DoD Global Information Grid (GIG) Quality of Service / Class of Service(QoS / CoS) Net-Centric Effective Assured Delivery of Information, Defense Information Systems Agency, 30 September 2003
21. DoD Transport Design Guidance Document, Version 0.97, The MITRE Corporation, April 2004
22. A Framework for Policy-based Admission Control, RFC 2753, IETF Network Working Group, January 2000
23. Terminology for Policy-Based Management, RFC 3198, IETF Network Working Group, November 2001
24. Kam, A., Trafton, R., Assessment of Mobile Routing Protocols for the Airborne Network, USAF Global Grid Technical Note Number 2003-04, Electronic Systems Center (ESC/NI1), October 2003
25. Trafton, R., Doane, J., Lam, L., Performance Enhancing Proxy Evaluation: Peribit SR-50, Mentat SkyX Gateway XR10, USAF Information Transport Technical Note Number 2004-01, Electronic Systems Center (ESC/NI1), February 2004
26. Kam, A., Morin, S., Trafton, R., Networking Over RF Links, USAF Global Grid Technical Note Number 2003-01, Electronic Systems Center (ESC/NI1), May 2003
27. Incremental Update -- AMPS Protocol Design Document, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Telcordia Technologies, Inc., 1 April 2003
28. Differentiated Services with Distributed Quality of Service Managers, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Rockwell Collins, August 2002
29. Incremental Update - DS/BB Protocol Design Document, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Telcordia Technologies, Inc., 1 April 2003
30. Global Information Grid Core Enterprise Services Strategy Version 1.1a, Office of the Assistant Secretary of Defense for Networks and Information Integration/DoD Chief Information Officer, July 2003
31. Global Information Grid Information Assurance Reference Capabilities Document, Volume I, Sections 2 and 3
32. Xukai Zou, Byrav Ramamurthy and Spyros Magliveras; Routing Techniques in Wireless Ad Hoc Networks-Classification and Comparison; International Conference on
33. Computing, Communications and Control Technologies: CCCT'04, August 2004
34. Shahrokh Valaee and Baochun Li, Distributed Call Admission Control for Ad Hoc
35. Networks, Proceedings of IEEE 56th Vehicular Technology Conference, Volume: 2, September 2002
36. Shigang Chen and Klara Nahrstedt, Distributed Quality-of-Service Routing in Ad Hoc Networks, August 1999
37. Jamal N. Al-Karaki and Ahmed E. Kamal, Quality of Service Routing in Mobile Ad hoc Networks: Current and Future Trends, Mobile Computing Handbook, M. Ilyas and I. Mahgoub (eds.), CRC Publishers, 2004
38. Prasant Mohapatra, Jian Li and Chao Gui; QoS in Mobile Ad Hoc Networks; June 2003
39. Imrich Chlamtac, Marco Conti and Jennifer J.-N. Liu; Mobile Ad Hoc Networking: Imperatives and Challenges; 2003
40. Khoa To and James Sasitorn; N.A.M.E: The Network Time Protocol for Ad Hoc Mobile Environments; Computer Science Department Rice University Houston, Texas
41. Chen, Wenli and Jain, Nitin, August 1999, ANMP: Ad Hoc Network Management Protocol, IEEE Journal on Selected Areas in Communications, Vol. 17, No. 8.
42. Shen, Chien-Chun, Srisathapornphat, Chavalit, and Jaikaeo, Chaiporn, February 2003, An Adaptive Management Architecture for Ad Hoc Networks, IEEE Communications Magazine.
43. Phanse, Kaustubh and DaSilva, Luiz A., Protocol Support for Policy-Based Management of Mobile Ad Hoc Networks, submitted for (conference) publication, 2003,
44. Toner,S. & O'Mahony,D., Self-Organising Node Address Management in Ad-hoc Networks, in Springer Verlag Lecture notes in Computer Science 2775, Springer Verlag, Berlin, 2003, pp 476-483, also at
45. Liotta, A., G. Knight, and G. Pavlou, On the Performance and Scalability of Decentralised Monitoring Using Mobile Agents, in Active Technologies for Network and Service Management, Proceedings of the 10th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM '99), Zurich, Switzerland, R. Stadler, B. Stiller, eds., pp. 3-18, Springer, October 1999,
46. Intel Labs, Simplifying Support of New Network Services Using COPS-PR,
47. Phanse, Kaustubh and DaSilva, Luiz A., Extending PBNM to Ad Hoc Networks,
[pic][pic][pic]
-----------------------
[1] ECU management categories are defined in the GIG IA Architecture and are still undergoing refinement as is the ECU management program. As a result, these categories should be considered notional at this time.
[2] It’s anticipated that some legacy EKMS functions will be operational past the 2012 timeframe. However, early transition to emerging KMI functionality will improve automated key delivery and should simplify key management processes.
[3] As part of the data labeling, an object will be associated with security properties and policies necessary for protecting it. Properties can include how to protect the object as it travels across the network (e.g., commercial grade vs Type 1 protection, as well as object and/or packet and/or link level data-in-transit protection requirements), how the object can be routed (e.g, must be contained within DoD controlled resources or can flow through networks external to the GIG), or how the data object must be protected at rest. Quality of Protection is different from metadata that describes the contents of the object. Metadata is designed to facilitate discovery and data sharing. QoP defines how a data object is protected while it is at rest and in transit.
[4] With asymmetric keys, a unique key is generated for each transaction through a public key exchange, while in a shared symmetric key operation, a single compromise leads to a system-wide compromise. Also, public key certificates allow for individual certificate revocation to selectively remove compromised individuals/devices without system wide rekeying.
[5] There are three common approaches to viral code detection. The first, signature matching, requires information about the virus. Specifically, a signature-based detector requires the virus’ code length and the location of its “contagious” segment. The second technique, code enumeration, involves examining known programs periodically to test whether any unknown segments of code have been added to the original file. It is most effective when applied before each execution of the program. Finally, checksum methods compare the current size of a file and the summed value of its bytes to the same attributes of a known uninfected version - an infection will often change these values.
-----------------------
= Cluster Manager
= Terrestrial-based Peer or Super-ordinate Manager
= Intelligent NM Agent
Cluster 2
Cluster 1
Cluster 3
= Network Manager
Cluster PEPs
Cluster PEPs
Cluster PEPs
Policy Accounting
§ð
Policy Server/Repository/PDP:
PDP
Cluster
PDP
Cluster
PDP
Cluster
Policy provisioning
Polic♣
Policy Server/Repository/PDP:
PDP
Cluster
PDP
Cluster
PDP
Cluster
Policy provisioning
Policy Decisions
♣
Policy Distribution
♣
Policy outsourcing
Modeling, Analysis & Simulation Tools
Policy formulation
1
•
Policy planning
•
Resource Planning Tool(s)
= Network Manager/Policy Server/PDP
Cluster 3
Cluster 1
Cluster 2
= Cluster PEPs
= Ground-based resource planning, and policy formulation, and modeling, analysis, and simulation
= Cluster Manager/LPDP
LM
Agent
LM
Agent
LM
Agent
LM
Agent
LM
Agent
LM
Agent
LM
Agent
LM
Executive
LM
Autonomous
Manager
LM
Autonomous
Manager
LM
Autonomous
Manager
LM
Autonomous
Manager
LM
Agent
= Logical Connectivity
Multiple Data Link and Physical Layers for varying environments and communications needs
Multiple security domains with Red side routing if necessary
Black Side routing and Common MANET services
Description
Other
HAIPE
Coalition
HAIPE
HAIPE
HAIPE
HAIPE
Confidential
NATO Secret
Red Side TS IP Routing
HAIPE
Red Side Secret IP Routing
Legacy or Future
Data Link
Legacy or Future
PHY
WNW
Data Link
NDL
Data Link
SRW
Data Link
Above 2GHz
SRW
NDL
WNW
Satcom Data Link
MANET Services
Black Side IP Routing
Notional JTRS Protocol Stack
Physical Layer
Data Link Layer
Network Layer
OSI Model
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- 82nd airborne advanced airborne school
- network architecture jobs
- bigelow aerospace llc
- bigelow aerospace station
- bigelow aerospace stock price
- bigelow aerospace ceo
- bigelow aerospace commercial space station
- bigelow aerospace news
- bigelow aerospace wikipedia
- bigelow aerospace las vegas nv
- bigelow aerospace stock symbol
- bigelow aerospace space station