Network-Centric Operations Industry Consortium (NCOIC ...mobile networking problem areas and the process for addressing them. MNWG is a living, distributed, collaborative forum providing

Approved for Public Release Distribution Unlimited NCOIC Oct 05-107-2

1

Network-Centric Operations Industry Consortium (NCOIC™)

Mobile Networking Overview (MNO)

Mobile Networking Overview (MNO) version 1.0 Document Number: NCOIC_MNO_0610

Published by the Network Centric Operations Industry Consortium, October 2006. http://www.ncoic.org/

Comments relating to the material contained in this document may be submitted to the

NCOIC Mobility Working Group through [email protected].

Copyright © 2006, Network Centric Operations Industry Consortium Inc. This document, or portions of it, may be copied and displayed for any purpose without charge, provided that this copyright notice and rights statement is included in any such

copy, and this document or excerpts from this document are reproduced without alteration.


2

Executive Summary The Network Centric Operations Industry Consortium (NCOIC) Mobile Networks Working Group (MNWG) is evaluating and recommending mobile networking solutions for network centric systems. This Mobile Networking Overview (MNO) document identifies the key mobile networking problem areas and the process for addressing them. MNWG is a living, distributed, collaborative forum providing recommendations for today’s mobility problems, and addressing new problems as they emerge. This MNO is an opportunity to inform the wider community of MNWG accomplishments to date. Wireline or wireless transmission links may be used to connect nodes in access and/or transport portions of a network. Nodes (i.e. devices on a network such as a computer, cell phone) and networks may be fixed, mobile, or transportable. In wireline networks, nodes are fixed and connected by wireline links. In wireless networks, the nodes may be fixed, transportable, or mobile and are connected by wireless links. Heterogeneous networks may be a mixture of wireline and wireless links, and mobile and fixed nodes. Network infrastructure includes physical hardware (e.g. fiber, satellites, and repeaters) and software that supports the interconnection of users and nodes. A cellular network is an example of a wireless network with fixed/transportable/mobile nodes that employs fixed network infrastructure. An ad hoc network is an example of wireline/wireless network in which nodes may be fixed, mobile or transportable with no assumed infrastructure. A Mobile Ad hoc Network (MANET) is an example of a wireless network in which mobile nodes create a self-forming and self-managing network without any assumed infrastructure. Issues with wireless links and issues with fixed, mobile and transportable nodes and networks both impact mobility. The MNWG has focused on issues with mobile and transportable nodes and networks, their interactions with fixed network infrastructure, and scenarios with mobile infrastructure. Impacts of wireless links including satellite links are considered. A wide range of use cases exist, including humanitarian disasters ranging from 9/11 to routine first aide level emergency events, Joint and coalition military actions, and Homeland Security Dept. events, demonstrating many levels of operational and technical interoperability effecting currently deployed systems. MNWG will work with the NCOIC Customer Requirements Working Group (CRWG) to define use cases. The emphasis of the MNWG, an international group, will be on emergency first responders and coalition military events. Ten mobility problem areas were identified by the MNWG to be addressed, based on the most pressing problems impacting first responders and a coalition military. Many of these problem areas are currently being addressed by commercial industry. Providing an interoperable solution, consistent with commercial industry, would be of most benefit for our target customers. The Mobile Networking Evaluation (MNE) concept provides guidelines and direction for evaluating the problem areas and their recommended solutions as part of the ensuing MNE effort. This common process aids coordination and discipline across all the problem areas, and


3

provides consistency between MNWG and other Working Groups (WGs) in the NCOIC. The MNE is the core product of the MNWG. The initial focus of the problem areas is primarily in the Communications Layer, specifically the Network and Transport layers. Interfaces to upper and lower layers are also addressed. The problem areas are the following: Network Planning and Management: In a mobile, ad hoc, environment with multiple administrative control authorities, Network Planning and Management must be responsive to topology changes, intermittent connectivity, and murky boundaries for administrative control authority, network congestion, and transition between domains. These domains may be associated with different first and second responders, government organizations, and private parties on site to address the emergency situation. Applications Interactions: This area evaluates the interactions between applications (IP Reference model Layer 5) and network transport (Layers 3-4). The study is limited to data abstractions, i.e., identification of types of information needed. Implementation details such as programming interfaces are not included. The data abstractions potentially allow the applications to better coordinate with network transport functions, (e.g. QoS, Routing, others), in responding to demands of the mobile environment. Quality of Service: IP QoS must be responsive to dynamics associated with mobility (path changes, demand, etc). In addition, mobile and/or ad hoc environments may have murky domain boundaries that need to be considered to enable satisfactory service across multiple heterogeneous networks. Information Assurance (IA): This area is responsible for ensuring that MNWG products are consistent with the NCOIC Information Assurance WG security framework in providing confidentiality, integrity, availability, non-repudiation, and authentication for mobile networks and nodes. Transport Layer Protocols: This area addresses transport (layer) session breakage resulting from network mobility. Network and Node Mobility: This area identifies the needs of 1) individual nodes moving within and between networks, subnetworks, and network infrastructure, 2) a network detaching from one part of a stable network and reattaching to another part of that network, and 3) functions associated with mobility management. Ad hoc Networks: This area addresses nodes forming a network with no core infrastructure. Routing: This area addresses layer 3 data and control planes, i.e. routing from IP upward, intra and inter domain routing, routing security, and routing performance in control and data planes (rate of topology change effects).


4

Multicast: This area identifies the multicast members’ needs as mobile nodes or networks traverse within the network infrastructure, including responsibility for handling branch distribution reconstruction within mobile network infrastructure. Physical and Data Link Layer Constraints: This area considers the impacts on network performance of physical and data link layers from both legacy and future systems, and suggests constraints and workarounds to compensate for those impacts, thereby improving network performance.

The MNO initiates a common process for identifying open standards that address mobility needs for the ten identified problem areas and also enable net-centricity within the overall

NCOIC concept. Working together with global customers and industry members, the framework is established to begin the detailed technical work of identifying candidate

standards and approaches and evaluating them for recommendation as NCOIC endorsed standards for interoperable mobility solutions.


5

Foreword

This document is being submitted as a deliverable of the MNWG, a charter working group of the NCOIC. The NCOIC has the following mission and vision that is supported by this workF-1: • Mission: The mission of the Consortium is to help accelerate the achievement of increased

levels of interoperability in a network-centric environment within, and amongst, all levels of government of the United States and its allies involved in Joint, Interagency and Multinational operations

• Vision: Industry working together with our customers to provide a network-centric environment where all classes of information systems interoperate by integrating existing and emerging open standards into a common evolving global framework that employs a common set of principles and processes.

The MNWG will use the net-centricity objectives proposed within the Net-Centric ChecklistF-2 as a starting guideline. The list will incorporate inputs from global organizations, such as NATO, to better reflect the international scope of the recommendations. The NCOIC process recommends NCO industry providers, adopters and users to collectively agree upon the objectives and how to achieve them. NCOIC’s Architectures, Standards, and Analysis (ASA) Steering Committee and the Engineering Process WG (EPWG) are responsible for developing this process which promises to deliver guidelines to the technical WGs to coordinate their work. The Net-Centric Checklist identifies the following objectives for the Communications area which will be used as the starting point for the MNWG: • IPv6 • Packet Switched Infrastructure • Layering, Modularity • Communications Area Goal • Network Connectivity • The Concurrent Transport of Information Flows • Differentiated Management of Quality-of-Service (QoS) • Inter-Network Connectivity • Defence Information Services Registry online (DISRonline) • RF Acquisition • Joint Net-Centric Capabilities • Operations and Management of Communications and Services The other checklist areas include Data, Services and IA which are addressed by NCOIC’s SII-WG, SOA forum and IA-WG, respectively. MNWG effort will support the NIF WG to design the NCO interoperability framework and help to ensure consistency and interoperability between WG deliverables. .


6

Table of Contents 1 Introduction...................................................................................................................... 7

1.1 Objective .................................................................................................................. 7 1.2 Scope........................................................................................................................ 7 1.3 Approach .................................................................................................................. 8

2 Background ...................................................................................................................... 9 2.1 Current Implementation of Mobile Networks ............................................................ 9 2.2 General Use Cases .................................................................................................. 10 2.3 Mobility Challenges................................................................................................ 10

3 Problem Areas Impacting Network-Centric Mobile Networks ........................................ 13 3.1 Network Planning and Management (NPM)............................................................ 13 3.2 Applications Interactions (AI) ................................................................................. 19 3.3 Quality of Service (QoS)......................................................................................... 22 3.4 Information Assurance ............................................................................................ 27 3.5 Transport Layer Protocols (TLP)............................................................................. 31 3.6 Network and Node Mobility (NNM) ....................................................................... 35 3.7 Ad Hoc Networks (AHN) ....................................................................................... 39 3.8 Routing................................................................................................................... 43 3.9 Multicast................................................................................................................. 46 3.10 Physical and Data Link Layer Constraints............................................................... 51

4 MNE Concept................................................................................................................. 55 5 Conclusion ..................................................................................................................... 61 6 Appendix........................................................................................................................ 63

6.1 Appendix A: Acronyms ......................................................................................... 63 6.2 Appendix B: Glossary............................................................................................ 66 6.3 Appendix C: Contributors ....................................................................................... 71 6.4 Appendix D: References ......................................................................................... 72

TABLE 6-1. FORWARD REFERENCES ............................................................................................................................... 72 TABLE 6-2. GENERAL USE CASES REFERENCES............................................................................................................ 72 TABLE 6-3. NETWORK PLANNING AND MANAGEMENT REFERENCES ........................................................................... 72 TABLE 6-4. APPLICATIONS INTERACTION REFERENCES................................................................................................. 73 TABLE 6-5. QOS REFERENCES......................................................................................................................................... 73 TABLE 6-6. INFORMATION ASSURANCE REFERENCES.................................................................................................... 74 TABLE 6-7. TRANSPORT LAYER PROTOCOLS REFERENCES ........................................................................................... 75 TABLE 6-8. NETWORK AND NODE MOBILITY REFERENCES ........................................................................................... 75 TABLE 6-9. AD HOC NETWORKS REFERENCES ............................................................................................................... 76 TABLE 6-10. ROUTING REFERENCES............................................................................................................................... 76 TABLE 6-11. MULTICAST REFERENCES........................................................................................................................... 77 TABLE 6-12. PHYSICAL AND DATA LINK LAYER CONSTRAINTS REFERENCES ............................................................. 78 FIGURE 3- 1 TIME SCALES OF NETWORK OPERATIONS.................................................................................................. 16 FIGURE 4- 1 MNE PROCESS ............................................................................................................................................ 56


7

1 Introduction

The MNO presents the key mobile networking problem areas that the MNWG will address to support the NCOIC mission. The WG will address these areas to help industry implement standards within their mobile networking products that satisfy the net-centricity objectives of their customers. The MNO is the initial deliverable for the ensuing Mobile Networking Evaluation (MNE) that will contain problem area evaluations. A process for evaluating mobile network net-centricity is provided in the MNE Concept section. The MNE will employ solutions in the current and emerging networking paradigms from industry consortia's and standards groups rather than develop new networking concepts or designs for Network Mobility. When those solutions do not exist or will not work, then MNWG will open a specific topic for discussion within the MNWG for resolution.

1.1 Objective

The MNO objectives are to: • Initiate the process for identifying the "open standards" for enabling network mobility to

meet criteria for net-centricity criteria supported by the overall NCOIC concept. • Facilitate interoperability among all classes of information systems by integrating

existing and emerging open standards into a common evolving global framework employing a common set of principles and processes.

The emphasis of this work is to clarify the mobile problem areas in the communication layers, as identified in Section 1.2, of mobile networking. This intent is to signify the importance of seamless mobile communications.

1.2 Scope

The MNO/MNE will focus on IP Communications Layers, specifically the Network and Transport layers. Interactions between these layers and lower layers (i.e. Physical and Data link layers) and higher layers (i.e. user applications) are also included in the evaluation. This activity will not evaluate the components within the applications and physical layers other than to appreciate the external interfaces they might extend to the two layers of focus. The MNO will focus on ten identified key problem areas where network functions directly interact with mobility. Generally the MNO will defer issues associated with fixed network infrastructure or wireless non-mobile network implementations. Header compression and link intermittency, for example, are primarily wireless issues. However, such issues may be investigated when they are closely related to the mobile experience.


8

1.3 Approach

The approach undertaken by the MNWG for documenting the overview of the mobile network evaluation process is as follows: • Document a list of identified key networking problem areas with enabling protocols and

mechanisms for mobile networking in an interoperable environment. • Identify and assign subject matter experts (SME) to address the specific problem areas

consistent with their expertise. Technical experts are responsible for developing the overview of the problems identified herein. Their support will be solicited during the NCOIC plenary and technical meetings.

• Develop and evaluate problem statements before writing the MNO document. This ensures that the focus is on the correct aspect of the collectively agreed upon problem areas and ensures consistent presentation across problem areas.

• MNO Document o Develop background information to support the discussion of mobile networking. This

includes reviews of characteristics and current technologies and implementations in mobile networking.

o Begin establishing use case for Net-centric Operations which bring out the operational shortcomings of the current implementations, described above, through “real-life” scenarios. The use cases will be further decomposed and tied to ten problem areas during the MNE.

o Capture the technical shortcomings for dealing with mobile networking which are captured in the Mobility Challenges. This provides an introduction to problem areas located in Section 3.

o Section 3 is the core section of the MNO, listing the mobile networking problem areas and how to address them as part of the MNE task. Each problem is supported with the following discussion: Problem Statement: Describes in clear terms why the function area has problems

dealing with mobile environments. Background: Defines the mobility area investigated. Identifies how it is addressed

in fixed networks. Summarizes why NCOIC should be interested in problem area. Related Work: Summarizes external forums doing work to address the problem. Interactions: Summarize interactions expected between identified problem areas,

other problem areas and external NCOIC WGs. Conclusions: Summarizes impact of mobility on problem area and potential

solutions to explore. o Identify a common process for evaluating problem area (MNE Concept section).


9

2 Background

2.1 Current Implementation of Mobile Networks

Networks generally fall into two categories, fixed or mobile. In fixed networks, both nodes and infrastructure are fixed, and the connections between them are usually permanent, either wireline or wireless. In mobile networks, the nodes can be transportable or mobile, but the infrastructure can only be fixed or transportable. Fixed infrastructure is typically existent in current cellular networks. Transportable networks are those typically employed by military organizations which are required to tear them down and reconstituting elsewhere. In future networks, the nodes will be self-managing; discovering their neighbors and reconfiguring themselves with little or no administrative oversight and without the necessity of a fixed infrastructure for support. They will be able to establish “Ad hoc Mobile Networks”. Current use of Ad hoc Mobile Networking is limited. Mobility is generally accommodated, but Ad hoc-ness is not. Current mobile networks are characterized by mobile nodes connected to a fixed network infrastructure via a wireless link. The wireless link typically connects the mobile node with the “access” node or base station which is connected to the fixed network infrastructure. Examples of such networks are cellular or satellite communication systems. Satellites are used as relays to extend the use of the wireless link for beyond line of sight connections. Often wireless links connect mobile nodes together in a pre-planned manner. Ad hoc mobility strives to enable wireless links to connect without pre-planning, e.g. in an ad hoc manner. Ad hoc networks have as a basic objective to evolve, augment, or supplement the standard “mobile-to-fixed-infrastructure” model. Ad hoc networks are formed dynamically by the mobile nodes that communicate with each other over a wireless channel. Each node has the ability to communicate directly with another node in its physical neighborhood. They operate in a self-organized and decentralized manner and are able to communicate beyond their immediate neighbor via multi-hop spreading of messages. Packets are sent to target nodes through a set of intermediate nodes that act as routers. Examples of Ad hoc network systems include packet radio networks, sensor networks, personal communication systems, rooftop networks, and wireless local area networks. Most currently deployed wireless systems can be categorized as commercial cell networks, DoD networks, Wireless Local Area Networks (WLAN), and current implementations of Ad hoc and mobile networks (e.g. Mesh networks and MANET). They were originally designed to address access and data or voice transport requirements. They are optimized for long duration connection-oriented applications. The concept of net-centricity is based on an IP-based packet switching infrastructure and higher transmission efficiency that is enabled by


10

interoperability and statistical multiplexing. The NCOIC MNWG seeks to identify net-centric alternatives to the currently available options.

2.2 General Use Cases

One phase of the MNWG’s MNE effort will be the development and analysis of Use Cases. Use Cases will be derived from a given systems’ mobility requirements as captured by the NCOIC’s Customer Requirements Team WG. Mobility requirements will be derived by functional decomposition of systems’ overall requirements. All mobility requirements must be identified. At present, the Customer Requirements Working Group (CRWG) has identified ten systems or initiatives for analysisGUC-1. Use Cases will be developed for military, first responder and homeland security systems. The emphasis of this international WG will refer to the first responder. Use cases will be developed to cover a range of situations, from large scale disasters such as 9/11, Hurricane Katrina and the recent South Asia tsunami, to more contained situations, such as local interagency emergency response to storms, fires or epidemics. The U.S. Department of Homeland Security (DHS), as part of its SafeCom program, has published the “Statement of Requirements (SoR) for Public Safety Wireless Communications and Interoperability”GUC-2. This document focuses on the functional needs of public safety first responders to communicate and share information; from it, Use Cases can be derived. This SoR addresses communications requirements and communications interoperability for the following scenarios, which contain varying degrees of mobility:

• Emergency Management System (EMS) -Heart Attack Scenario • Residential Fire Scenario • Multi-Discipline/Multi-Jurisdictionnel Explosion Scenario • Law Enforcement Traffic Stop • College Football Game • Terrorist Car Bomb • Hurricane • Earthquake Working with the CRWG Team, the MNWG will develop families of Use Cases from scenarios such as those listed, as well as other initiatives being evaluated by the NCOIC.

2.3 Mobility Challenges

The intent of this section is written for several reasons. One reason is to provide a common thread of the document's background section to the problem area sections found in Section 3. Another reason is to reiterate the scope of this document as it relates to mobility in perspective of seamless internetworking communications. Lastly, a reason to provide the reader clarification of mobility challenges as properties that commonly associate to mobile issues (i.e. interoperability) that don't change over time. For example, a customer’s demand


11

for “fast Internet access”, this can be interpreted in many different ways, yet the capability expectations remain continuous, such as information access must be available anywhere, anytime, uninterrupted, secured, managed, and immediate. These are important elements that need to be continuously reviewed as mobile IP network technology evolves. The challenges that exist with mobility is the task to send and/or receive data (i.e. IP datagrams containing voice, video, or data) with accuracy so that a user or software contained device can make decisions without the need to be physically attached to a fixed infrastructure. Increasingly, we are dependent on information that is available when accessing a network (i.e. content from internetworking services). This dependency implies that users would need access to this information while roaming. Therefore, mobility is an additional parameter that needs to be considered in the design of networks, network protocols and information services. Mobility implies that networks need to adapt with roaming nodes/devices. During a single session, users may connect from different network attachment points or use different networks or even more than one network simultaneously. So, next generation networks will have to support movement of users, servers, routers, services and even infrastructures to support mobile computing. In a Network Centric perspective, the following are examples of important research challenges in the genre of network support for mobile computing. Solving these research challenges will lead to interesting new services for first responders and tactical missions. • Mobility protocols to support routing to and from mobile nodes: When mobility becomes

the norm rather than exception, it is imperative for interoperability between implementations i.e. dealing with large scale mobile delivery, discovery management, and security. Examples are authentication and access control schemes for mobile users. Current access control schemes allow the specification of who can do what. (e.g. Send, receive). With mobility, we need to address the issue of who can do what, where, and when.

• Logical location or position information of current mobile node’s state might impact a communication session in relation to service delivery and end-route functionality: Proposed protocols with knowledge awareness, movement detection, and discovery capabilities might need further considerations for a better approach when logical changes frequently occur to a mobile node (due to physical movement) and its role (i.e. forwarding traffic) in the network. Research is being explored to determine if maintaining logical state information of a mobile node’s existence in a network topology is relevant for new accommodating solutions. It is also unsure if providing support for querying services (possibly in a distributed environment) would be available within a given proximity and providing services to entities with a specific geographic scope. This is an example of an application running on a mobile device that is discovering a requested service and the service availability is restricted (local service capability compared to far-back reaching global service) due to its geographic scope from a logical perspective

• End-to-end QoS to roaming users: Quality of traffic affects the behavior of the network as it attempts to optimize or provide priority to traffic flow sessions. QoS mechanisms deal


12

with policing and shaping of network traffic with the challenge to adaptively change when congestion occurs or an instance of a contract dictates traffic priority. This is very difficult to achieve when IP QoS functions in a hop-by-hop manner and with mobility the packet's path may change with each move, thus end-to-end latency will be impacted from mobility when making adjustments or corrections after a roaming occurrence. Therefore QoS mechanisms won’t know about spatial resource demands until it is too late. Any contract that the network is willing to offer (for a user application or service) must maintain compliance in spite of its mobility. IP traffic schemes in mobile networks may imply considerations of spatial capacity demands in all possible locations that a user node may roam during a given communication session, yet the demands are not entirely predictable.

• Security: Technology, under development for Ad hoc mobile networks, is making important steps toward possible goals of securing mobile computing and communications However, the security concerns remain a serious impediment to widespread adoption. The wireless communication medium for mobile network is inherently exposed to attacks or other security related concerns. Mobility presents problems to Security mechanisms such as rights and privileges management, maintaining security associations (particularly session-level security and cryptographic associations), and perhaps adds a "location-specific" attribute to RPM concerns. The emerging "Ad Hoc" nature of mobile, wireless networks amplifies many of these problems particularly for the identification and authentication of mobile nodes, for the distribution and management of cryptographic keys, and for credentials management.

• Data and functionality migration: In mobile environments, the traditional client/server model may break down, for example the capability of the client or server and the type of network access available vary widely. Support for controlling the amount of data and reducing the dependence on a fixed infrastructure is absolutely critical in mobile environment. Network abstractions for data and functionality migration to and from the mobile host are needed. Data should be able to ``follow" the mobile host. This should be balanced against the cost of migration. We are still very distant from the goal of seamless wireless operation where any wireless device would be able to connect to any other wireline/wireless device at any time, in any place, and while satisfying the requirements of the user of the device.

As these important challenges are studied and become a focus for improvements, mobile challenges may subside as we become acquainted with the limitations and tolerate the mobile conditions. This section intentionally describes mobility challenges from a broader perspective and remains as a discussion topic for future analysis. It is necessary to identify and investigate the mobile network limitations as described in the next section so we have an appreciation for the evaluation work that extends after this current overview document.


13

3 Problem Areas Impacting Network-Centric Mobile Networks

The MNWG addresses Mobility Challenges by first focusing on ten key problem areas identified below with overviews of their problem space. A common process for evaluating the problem areas is provided after the problem area overviews. This is a living process. The problem areas and process are expected to evolve over time as the WG learns from experience gained working these problems.

3.1 Network Planning and Management (NPM)

PROBLEM STATEMENT Traditional Network Planning focuses on preplanning resources while traditional Network Management concentrates on single fixed domain environments with clearly delineated management boundaries with little or no regard to net-centricity. Neither of them addresses network or node mobility. Mobility impacts Network Planning and Management through the following challenges: • Responsiveness to:

o Higher rate of topology change o Intermittent connectivity

• Murky domain boundaries and responsibilities, i.e., perimeters are vague or non-existent at least physically due to mobility.

• Moving among domains Mobility of networks and nodes requires network planners to provision resources impacted by mobility such as location awareness; frequency allocations, spacing, and conflict; and network security to maintain a desired level of network performance with minimal impact to wireless channel capacity. Location awareness and update is an issue that needs to be solved. Introduction of wireless capabilities imposes a Spectrum Management function in network management. Mobility complicates spectrum management because of the spatial nature of spectrum allocations, and the no preplanning goal of ad hoc-ness is in direct conflict with current regulatory and administrative requirements associated with spectrum management. Security will be evaluated within MNWG’s IA task.

Network Management is responsible for the management needs of the many network elements impacted by mobility including:

• Contractual/SLAs


14

• Routing • Scheduling

• Congestion control • Admission control

Most current Network Management Systems (NMSs) are Manager of Manager (MOM) products that are strictly hierarchical in nature - lower tier element managers integrated by higher level managers, and so on. Simple Network Management Protocol (SNMP) and Common Open Policy Server (COPS) protocols are commonly used to facilitate communication among managers. The product development generally focused on the integration across separate maintenance centers that evolved over time, particularly in the Telco world. In the emerging mobile Ad hoc environment, things have to be flatter - a manager has responsibility for all devices/technologies/services in his domain - there are no subordinate managers. Also additional capabilities such as those indicated below (more examples) are needed:

• Specification of long-term, network-wide configuration objectives via directories, as an example

• Automated feedback loop so that information reported by monitoring agents can be used to tweak configurations based on policies to react to reported conditions

• Dynamic changing the role of a network node • Setting up network-wide values for auto-configuration parameters. Traditionally management is in charge of fixed domain but now domain is no longer fixed. How do we deal with this? How will the devices/resources in a manager's domain change in a mobile environment -- especially if management responsibilities are sliced and diced along geographic and/or organizational boundaries, as they generally are? Another discussion point relates to ad hoc which does not mean zero configurations. There's a need for network initialization in mobile networks. The various network mechanisms (QoS, congestion management, routing, etc.) need to be "adaptable", but they still need to be initialized, thresholds set, etc. A network centric framework for managing fully distributed and, again, changing, authentication/authorization infrastructures are also needed. People and devices can attach to the network and/or log on from anywhere. So how do you authenticate and authorize Private Jones when he drives up and tries to access the network? The responsibility of network planning and management has always been domain specific as it should remain. Network Planning usually involves long term, network-wide configuration related objectives such as connectivity, bandwidth, security, addressing, and modeling. Network Management usually involves network monitoring and reconfiguration based on feedback from monitoring agents. Mobility of or within wireless mobile networks requires network planners to address frequency allocations with respect to network scaling to maintain


15

a desired level of network performance. Network management needs to focus on efficiently managing frequency space, location awareness, network security, and frequency conflict resolution with minimal impact to wireless channel capacity. BACKGROUND Any discussion about Network Management must answer two basic questions:

• What exactly is being managed? • What is manageable about it?

Answers generally include not only discrete network devices (e.g. routers, switches, etc.), but the interconnections/relationships between those devices as well, including both physical entities (transmission links) and logical/virtual constructs like routes, tunnels, and VLANs. Finally, even higher level abstractions composed of identifiable, related collections of functions/capabilities provided by cooperative interactions among multiple and physically distributed sets of these entities themselves become manageable entities. Various services examples are virtual circuits, sessions, directories, etc. The manageable attributes of these entities include their operational state, operating/configuration parameters, and the relationships (e.g. connectivity, dependencies, etc.) used to construct the higher level of abstraction entities.

The myriad of functions and capabilities that have been identified and defined over the years have led to common architectures and designs for the network management systems needed to plan, design, and operate networks. The challenge for the work capture herein is to identify network-centric Network Planning and Management practices. Generally, there are three high-level groupings of functional requirements for these systems:

• Planning and Design • Administration

• Monitoring and Control These functional groupings target different operational timeframes as illustrated in Figure 3- 1


16

Figure 3- 1 Time Scales of Network Operations

Network Planning involves resource planning activities conducted before deployment and periodic replanning. Network Management involves policy-based management, resource management and network monitoring and (re)configuration. It is identified in standards bodies as Fault, Configuration, Accounting, Performance, and Security (FCAPS). A mature industry delivers tools for fixed networks supporting various aspects of planning and management needs. The tools include network and node level management, performance monitoring, domain and/or vendor-specific resource management, help desk products, change management systems, etc. Mobility, wireless, ad hoc behaviours, multi domain environments and the larger net-centricity requirements impose additional requirements on these solutions. How will the core resources and end node responsibilities in a manager's domain change in a mobile environment where the traditional clear management perimeters disappear at many levels? This will be especially challenging if management responsibilities are organized along geographic and/or organizational boundaries, as they generally are. Ad hoc does not mean zero configurations. There's a need for network auto configuration in mobile networks also. Various network management mechanisms (e.g. Policy-based Management, Congestion management, Traffic Management, etc.) need to be not only adaptable, but also configurable. This is the responsibility of Network Planning and Management. Management will also be required of a fully distributed and again, changing authentication/authorization infrastructure. People and devices can attach to the network and/or log-on from anywhere. How do you authenticate and authorize Private Jones/resource when he/it drives up and tries to access/or participate in the network?


17

RELATED WORK A number of communities contribute to Network Planning and Management of existing communication systems. They all potentially contribute to NCO being promoted by NCOIC. The Internet Engineering Task Force (IETF), Operations and Management Group (OMG), and Simple Network Management Protocol (SNMP) community focuses on simple IP-based client server management variable oriented tools. The tools are based on SNMP which uses unreliable information exchange. The ISO [(ISO-IEC/JTC 1/WG 4, OSI, Common Management Information Protocol (CMIP)-Common Management Information Service (CMIS)] community, true to its Telco roots, believe in powerful object oriented management approaches relying on reliable information exchange. The ITU-T [(SG IV, Telecommunications Management Network (TMN)] community only defines a management architecture using the OSI protocols and out-of-band measurement. The other potential contributors to addressing this problem area include Distributed Management Task Force (DMTF), Telecommunications Management (TM) Forum, OMG, and IEEE. This work will also monitor Management work available on public Defence Information Services Registry online (DISRonline). INTERACTIONS NPM problem area will interact with all of the other problem areas. Specifically the NPM problem area has potential interactions with the following problem areas and NCOIC WGs:

Problem Areas-interaction YES/NO: • Applications Interactions-YES: Network Planning and Management and Applications

Interactions will interact to evaluate network planning and management solutions for applications interactions which are generally focused on improving application operation over wireless and/or mobile networks.

• QoS-YES: Network Planning and Management and QoS will interact to evaluate planning and management needs for QoS.

• Information Assurance-YES: Network Planning and Management and Information Assurance will interact to evaluate network planning and management’s responsibility for managing security.

• Transport Layer Protocols-YES: Network Planning and Management and Transport Layer Protocols will interact to evaluate network planning and management responsibility for managing transport control protocols.


18

• Network and Node Mobility-YES: Network Planning and Management and Network and Node Mobility will interact to evaluate options for addressing mobility management.

• Ad hoc Network-YES: Network Planning and Management and Ad hoc Networks will interact to evaluate solutions for planning and managing Ad hoc networks which are “human-in-the-loop” before deployment and self planned and managed during deployment or operations.

• Routing-YES: Network Planning and Management and Routing will interact to evaluate options for net-centric enabling management of routing for wireless and/or mobile scenarios.

• Multicast-YES: Multicast and Network Planning and Management will interact to evaluate different options for managing multicast routing and group membership over mobile and/or wireless networks in net-centric manner.

• Physical and Data link Constraints-YES: Network Planning and Management and Physical and Data link Constraints will interact to evaluate network planning and management needs relating to physical and data link constraints.

NCOIC WGs • Building Blocks-YES: Network Planning and Management will recommend standards to

help Building Block (BB) evaluate products ability to support network planning and management in net-centric enabling manner.

• Customer Requirements-YES: Network Planning and Management requirements will be driven by Mission Thread/Use Case Analysis from Customer Requirements WG.

• Engineering Processes-YES: Network Planning and Management will provide terms to Engineering Process’ lexicon. The effort may also motivate modeling and simulation.

• Information Assurance-NO: Network Planning and Management security requirements will be evaluated through MNE Information Assurance (IA) problem area.

• Lexicon-YES: Network Planning and Management will provide terms to this activity. • NCAT-YES: Network Planning and Management will provide net-centric enabling

management criteria to Network Centric Assessment Tool (NCAT). • NIF-YES: Network Planning and Management will help develop those portions within

Network Interoperability Framework (NIF) and Protocol Functional Collection PFCs pertaining to Ad hoc networking.

• SII-YES: Network Planning and Management will use Services Interoperability Infrastructure (SII) WG’s SCOPE model to help bound problem space and evaluate alternatives.

CONCLUSIONS Mobility networks, wireless communications, ad hoc behaviors, multi domain environments and broader net centricity requirements impose additional requirements over and above traditional management. In a mobile, ad hoc, multi-domain environment Network Planning and Management must be responsive to topology changes, intermittent connectivity, murky domain boundaries and transition between domains. There's a need for network auto configuration in Ad hoc mobile networks. Network management mechanisms (e.g. policy-based Management, congestion management, traffic management, etc.) need to be not only


19

adaptable, but also configurable. The manageable attributes of entities include their operational state, operating/configuration parameters, and the relationships (e.g. connectivity, dependencies, etc.) used to construct the higher level of abstraction entities.

3.2 Applications Interactions (AI)

PROBLEM STATEMENT The applications interactions may be used to define control and management plane mechanisms between the Communications Layers (layers 1-4) and the Information and Application layers. In a fixed infrastructure, this interface is provided via mechanisms such as sockets. In contrast to a fixed environment, a mobile environment may require additional information to be communicated between applications and communications layers (e.g., link dynamics, changes in network topology, etc). The expanded interactions beyond those originally provided for the fixed networks and the management of them potentially impacts interoperability. Traditional user applications are transparent to mobility completely. Mobility is maintained by mobility routing protocol enhancements for IPv4 and IPv6 within the nodes communications layers. BACKGROUND Above Layer 4 in the IP Reference Model, Layer 5 is defined as the Applications Layer. The Applications Layer is top heavy within the IP Reference Model and can support direct programming to the communications layers or be a complete layered set of services plane interfaces, implemented within a Services Oriented Architecture within Layer 5. The programming interfaces from Layer 5 to the Communications Layers will not be addressed by MNWG at this time. We will address the data abstractions that may be required to be passed down or up between the Communications Layers and Layer 5. The data abstractions required will be provided from the technical analysis and evaluations performed within the Mobile Communications Layers. Application interactions between the IP Reference model Layers 1-3, provided by the NIF (https://global.ncoic.org/apps/org/workgroup/approved_documents/documents.php ), and Layer 4 will be an important technology analysis for mobile networking, as they support the Services Layers and Planes for applications to interact with QoS, Routing, Security, Provisioning, Network Congestion, and Network Management. The MNWG will investigate emerging protocols that contribute to reducing latency and congestion at the application layer. Example of optimisations schemes include: Multiplexing many voice flows in a same IP flow in order to increase system efficiency; Taking into account the broadcast capabilities of the radio networks (integrate protocols such as PMUL - ACP142); Building efficient protocols (e.g. use of HMTP in place of SMTP), in order to avoid a waste of resources by the application layers


20

RELATED WORK Related work on Application Interactions for NCOIC has several forms and data points for which the NCOIC Mobility Working Group will be required to determine as it is not well understood from an interoperability perspective. • De jure Standards forums like IETF www.ietf.org, ITU www.itu.int/ITU-T/, 3GPP

www.3gpp.org, and 3GPP2 www.3gpp2.org. • Industry Networking Consortia forums like WIMAX www.wimaxforum.org, IPsphere

www.ipsphereforum.org, IPv6 Forum www.ipv6forum.com, ATIS www.atis.org, W2COG www.w2cog.org, Open Group www.opengroup.org, NDIA www.ndia.org, AFCEA www.afeca.org, and AFEI/NCOIF www.afei.org.

• Industry Systems Integration and IT hardware and software vendors providing MANET solutions today in the market.

• International government organizations and departments working on MANET as important network technology for their deployment models and implementations.

INTERACTIONS Applications Interaction is responsible for evaluating proposals for adding interactions between application and any of the underlying communication layers to improve performance over wireless and/or mobile environment. This broad charter means it potentially touches on all the problem areas. Applications Interaction work will need to interact with other NCOIC WGs to identify configuration parameters that may be required for Services Layers and Planes. Specifically the AI problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas-interaction YES/NO: • Network Planning and Management -YES: Applications Interactions and Network

Planning and Management will interact to evaluate network planning and management options for managing applications interactions.

• QoS-YES: Applications Interactions and QoS will interact to evaluate how applications initiate QoS.

• Information and Assurance-YES: Applications Interactions and Information Assurance will interact to evaluate solutions for securing this edge of the network

• Transport Layer Protocols-YES: Applications will interact with Transport Layer Protocol to evaluate solutions enabling applications to tune transport layer settings to optimize operation over mobile and/or wireless environment.


21

• Network and Node Mobility-YES: Applications Interactions and Network and Node Mobility will interact to evaluate options using application interactions to improve performance for mobile network and node scenarios.

• Ad hoc Network-YES: Applications Interactions and Ad hoc Networks will interact to evaluate how applications increase interaction with Communication layers to optimize operations over Ad hoc networks.

• Routing-YES: Applications Interaction and Routing will interact to evaluate solutions enabling applications to optimize routing.

• Multicast-YES: Applications Interactions and Multicast will interact to evaluate solutions enabling applications to optimize multicast routing and group membership over mobile and/or wireless networks.

• Physical and Data link Constraints-YES: Applications Interaction and Physical and Data Link Constraints will interact to evaluate solutions enabling applications to optimize physical and data link resource allocation through increased fidelity interactions.

NCOIC WGs • BB-YES: Applications Interactions will recommend standards to help Building Block

evaluate products’ ability to support applications interactions capabilities in net-centric enabling manner.

• CR-YES: Applications Interactions requirements will be driven by input from Mission Thread/Use Case Analysis from Customer Requirements WG

• EP-YES: Applications Interactions will provide terms to EPWG’s lexicon. The effort may also motivate modeling and simulation.

• IA-NO: Applications Interactions security requirements will be evaluated through the IA problem area.

• Lexicon-YES: Applications Interaction will feed terms to this effort. • NCAT-YES: Applications Interactions will provide NCAT related net-centric enabling

criteria. • NIF-YES: Applications Interactions will provide content to NIF WG’s framework and

PFCs. • SII-YES: Applications Interactions is expecting SII-SCOPE to define and/or bound the

problem.

CONCLUSIONS This problem area evaluates the interactions between applications (IP Reference model Layer 5) and network transport (Layers 1-4). The study is limited to data abstractions, do not include programming interfaces. The data abstractions potentially allow the Services Layers to better coordinate with QoS, Routing, Security, Provisioning, Network Congestion, and Network Management as they respond to demands of mobile environment discussed within other problem areas.


22

3.3 Quality of Service (QoS)

PROBLEM STATEMENT Fixed networks typically have access to abundant inexpensive capacity, allowing them to maintain satisfactory network service characteristics through over provisioning - that is, providing significantly more resources than are expected to be needed by applications. This gives the system adequate reserves to overcome the assorted problems that may arise affecting the network service characteristics experienced by the user. In addition, the commercial internet business model has evolved around the notion of a flat rate subscription-based service, which doesn't support the price differentiation that the wide-spread deployment of differentiated IP QoS Services would require. The success of over provisioning in fixed networks has meant that IP Quality of Service (QoS) has largely defaulted to the Best Effort model, where the network makes no effort to consider the priorities of the applications when the traffic load exceeds capacity. Within a mobile environment, one does not typically have the luxury of being able to plan for localized demand changes and deploy resources such as equipment in a timely manner owing to dynamic environment and constrained capacity. It is potentially difficult for IP QoS to respond robustly to dynamic demand and resource availability in view of constrained capacity within mobile environments. In mobile infrastructures, IP QoS must be responsive to dynamics associated with mobility (e.g. path changes, demand, etc). In addition, mobile and/or ad hoc environments may have murky (a.k.a. indistinct or fluid) administrative boundaries. IP QoS must allow nodes belonging to different organizations, such as administrative domains, to work together to support end-to-end QoS. Supporting end-to-end QoS services within heterogeneous subnets consisting of mobile and fixed networks will be part of this challenge. An IP QoS solution should also be capable of adapting to changing link characteristics caused by mobility

BACKGROUND IP QoS refers to differentiating techniques, beyond simple, undifferentiated Best Effort, for allocating limited resources across applications and users to satisfy their different network service requirements. This emerging capability provides for resource assurances and service differentiation in an IP network. It focuses on Transport and Network layer mechanisms. IP QoS has interactions with services/application layer as well as physical and data link layers. The objective of IP QoS is to enable higher traffic loads while supporting a larger range of applications over scarce network resources than is possible with Best Effort operations. IP QoS increases the level of assurance that applications and users are provided the resources they need to perform adequately. IP QoS is a major driving force in the evolution of IP Networks. A network, in its simplest form, consists of shared resources such as bandwidth and buffers, serving traffic (e.g. packets) from competing users. Fundamentally, most QoS problems come down to the issue of resource allocation - packets get dropped or delayed because the resources in the network cannot meet all the traffic demands.


23

The most important performance measures for packet networks are delay, jitter (standard error, or variance, of delay), loss, and overflow. These are statistical quantities, so they are addressed in terms of their means and variances, or their probability distributions. • Delay is the time from packet transmission until its servicing/delivery is complete.

• Jitter is the variation of delay, and is important measure to services that can cope with consistent delay, but not very well with fluctuating delays.

• Loss Ratio is the ratio between the total number of packets lost and the total number of packets sent. The underlying assumption is that buffers are finite, and packets arriving when buffers are full are lost.

• Overflow Probability is the probability that the number of packets in a buffer exceeds a certain threshold.

Out of the above four, overflow probability is the most amenable to mathematical analysis, and is used as an approximation for loss ratio. These measures may not directly represent the subjective QoS perceived by users, but they are relatively simple to monitor and measure, and therefore are used in practice. Applications tend to express their performance requirements in terms such as throughput and response time. In addition, Timeliness of Delivery and Speed of Service are common measures used by applications providing one-way message delivery.

These application-level QoS measures need to be translated into appropriate packet-delivery service-level metrics in order to design the network and provision those services. This requires characterization of acceptable/desired application behavior (e.g. transaction rates and sizes, message sizes and speed of delivery requirements, etc.) in order to facilitate that translation. QoS in Mobile Networks - How do we get there from here? Mobile and wireless networks exacerbate QoS design issues for several reasons - these types of networks tend to be more resource limited, the availability and quality of the resources (particularly bandwidth) tend to be highly variable, and the topology of the network itself can change, affecting packet forwarding/delivery as well as connection/session state.

Mobility also tends to perturb the state of in-progress sessions (addressed in other sections such as the application [3.2] and transport [3.5] areas), IA issues such as security (identification/authentication) and cryptographic associations (addressed in the IA Section 3.4), and Multicast delivery (addressed in the Multicast Section 3.9)

Most currently deployed IP networks do not support any form of active resource allocation, nor do they differentiate between the applications and users competing for the resources. The network treats all packets the same, and simply services packets on a first-come, first-served basis. This is referred to as a Single Best Effort Service Model. In addition, there is no admission control; users simply inject packets into the network as fast as they can. Admission control is a major aspect of IP QoS. Admission Control may be implicit or explicit, as detailed below:


24

• Explicit Admission Control: This approach is based on signaled resource reservation. Applications must send a request to use the network through the resource reservation signaling mechanism. The request that contains QoS parameters is forwarded to the admission control mechanism. The admission control mechanism decides to accept or reject the application based on the application's QoS requirements, available resources, performance criteria, and network policy.

• Implicit Admission Control: There is no explicit resource reservation signaling. The admission control mechanism relies on a priori bandwidth provisioning and traffic conditioning mechanisms, such as traffic shaping and policing, at the network edge to control the admission of packets to the network.

Note that the connectionless and stateless architecture of IP networks means most networking applications do not employ signaling to establish communications sessions. Virtually all existing IP-based applications (e.g., Web/HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), e-mail, etc.) do not employ signaling, and must rely on implicit mechanisms within the network to enforce their QoS requirements. The only applications that will or can employ signaling are newer real time applications (such as Voice over IP (VoIP)) that are designed to utilize signaling (e.g., H.323 or Session Initiation Protocol (SIP)) to initiate a session.

An alternative to adding complex admission control elements and signaling overhead traffic to an already resource-constrained environment, such as the mobile wireless networks under discussion, would be to design these emerging applications to be rate adaptive, responsive to congestion indications from the network, and more robust in the face of impairments such as packet loss and delay. For example, modern voice codecs (such as Internet Low Bitrate Codec (iLBC)) can both rate adapt and tolerate significant levels of packet losses before the voice signal is significantly degraded. In addition, new transport protocols for these data types, such as Datagram Congestion Control Protocol (DCCP), which is intended to replace the currently used User Datagram Protocol (UDP) have been developed and are now being deployed to enable network friendly and responsive application behavior.

The lack of predictable performance is also an issue which needs addressing. Another is service differentiation. The current Best Effort approach is a quarter of a century old. Because of the emergence of Real-Time and Multimedia applications such as VoIP, streaming and conversational video, time-sensitive data (e.g. Sensor networks, alerts, etc.), and transactional business-oriented applications, a whole new area of networking is developing. Since different applications have different resource requirements, a new Multi-Service Model vs. the old Single Best Effort Model for IP networks is required. New real-time applications utilize the UDP, compared to Transmission Control Protocol (TCP) transport protocol due to their stream versus block orientation and delay sensitivities. Therefore, the traditional “80+% of Internet traffic is TCP-based” view is changing. This raises new congestion control issues and concerns. Finally, some real-time services may require strict bounds on performance parameters such as delay and jitter that is usually accomplished via End-to-End (E2E) resource reservation. This type of service is known as “Guaranteed Services”.


25

The key overarching issue is that a network that supports QoS needs to take an active role in the resource allocation process and decide who gets which resources, and how much. This added intelligence will be particularly challenging in mobile networks. RELATED WORK There are few implementations in the industry today applying IP QoS specifically to mobile applications. However, the IETF has developed a significant body of IP QoS work focused on fixed network applications. The work can be organized into four technology areas which have emerged in the last few years as the core building blocks for implementing QoS in fixed IP networks; Integrated Services (IntServ), Differentiated Services (DiffServ), Resource ReSerVation Protocol/Next Steps in Signalling (RSVP/NSIS) and Traffic Engineering/Multi-Protocol Label Switching (MPLS).

IntServ (RFC 1633) and DiffServ (RFC 2475) are two resource allocation architectures for the Internet. The new service models proposed in them make possible resource assurances and service differentiation for different traffic flows and users. The Integrated Services approach provides strict performance assurances through resource reservations for individual application flows, whereas the Differentiated Services model uses a combination of edge policing, provisioning, and traffic prioritization to allocate resources across multiple service classes (e.g. aggregates of flows). Packet flows from applications are then mapped into the service class that best matches each application's requirements.

A number of signalling protocols for reserving resources on the Internet has been developed. RSVP (RFC 2205) was developed first and has seen many extensions due to its comprehensive capabilities. Aggregate RSVP (ARSVP) (RFC 3175) has been developed to alleviate RSVP’s scaling limitations. NSIS (RFC 4080) is a second generation attempt at building a lighter weight version of RSVP while hopefully retaining much of its capabilities. RSVP is a core component of IntServ but is also an independent capability which may be used outside of IntServ (MPLS, etc.). RSVP and ARSVP are candidate signalling protocols for guaranteed services.

Traffic Engineering and MPLS (RFC 3031) give network providers a set of management tools supporting IP QoS provisioning on a large scale and at reasonable cost. The process of optimizing the performance of networks through efficient provisioning and more optimal control of network flows is often referred to as traffic engineering. MPLS was originally intended as a way of improving the forwarding speed of routers, but is now emerging as a standard technology that offers new traffic engineering capabilities for very large scale IP networks. The effect/requirements imposed by E2E QoS and traffic engineering on routing protocols are being addressed in Section 3.8.

Finally, E2E IP QoS is primarily an issue of managing congested queues during periods of peak loads and simultaneous demands. Effective congestion control mechanisms are needed to provided assured throughput and delay/loss bounds for E2E traffic. INTERACTIONS


26

QoS will interact with all of the other problem areas to help match overlying demand with underlying resource reality. QoS will be initiated from both the upper layers through Applications Interactions and the lower layers through Routing and Physical and Data link Layer Constraints. A broader breadth of interaction with other NCOIC WGs is expected with a problem area such as QoS that is E2E. Specifically, the QoS problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas-interaction YES/No: • Network Planning and Management-YES: QoS and Network Planning and Management

will interact to evaluate planning and management needs for QoS. • Application Interactions-YES: QoS and Applications Interactions will interact to evaluate

how applications initiate QoS. • Information Assurance-YES: QoS and Information Assurance will interact to evaluate

solutions for securing QoS functions. • Transport Layer Protocols-YES: QoS and Transport Layer Protocol will interact to

evaluate transport layer protocol solutions QoS quality and its interaction with larger E2E QoS.

• Network and Node Mobility-YES: QoS and Network and Node Mobility will interact to evaluate mobility enabling solutions’ ability to support QoS during hand-offs.

• Ad hoc Networks-YES: QoS and Ad hoc networks will interact to evaluate solutions’ ability to support QoS over Ad hoc networks.

• Routing-YES: QoS and Routing will interact to evaluate techniques for making routing QoS-aware. QoS will interact with Traffic Engineering and MPLS that give network providers a set of management tools for bandwidth provisioning and performance optimization

• Multicast-YES: QoS and Multicast will interact to evaluate multicast (routing and group membership) solutions ability to support QoS.

• Physical and Data link Layer Constraints-YES: QoS and Physical and Data link Constraints will interact to evaluate constraints physical and data link resources impose on QoS.

NCOIC WGs • BB-YES: QoS will recommend standards to help Building Block evaluate products’

ability to support QoS in net-centric enabling manner. • CR-YES: QoS requirements will be driven by input from Mission Thread/Use Case

Analysis from Customer Requirements WG. • EP-YES: QoS will provide terms to Engineering Process’ lexicon. The effort may also

motivate modeling and simulation. • IA-NO: QoS security requirements will be evaluated through MNE IA problem area. • Lexicon-YES: QoS evaluation will forward terms to Lexicon WG.


27

• NCAT-YES: QoS evaluation will interact with NCAT to develop interoperability criteria for QoS environments. NCAT has a number of performance related characteristics that interact with the QoS problem area.

• NIF-YES: QoS evaluation will interact with NIF to develop NCO framework and PFCs. • SII-YES: QoS will use SII’s SCOPE model to help evaluate alternatives. The SII WG is

expected to have a role initiating QoS from its service oriented architecture perspective. This interaction is expected to be mostly managed through the Applications Interactions problem area.

CONCLUSIONS IP QoS focuses on Transport, Network and Data link differentiating techniques, beyond simple undifferentiated Best Effort, for allocating limited resources across applications and users to satisfy their different network service requirements. IP QoS increases the level of assurance that applications and users are provided the resources they need to perform adequately. In mobile infrastructures, IP QoS must be responsive to dynamics associated with mobility described as path changes, demand, etc. In addition, mobile and/or ad hoc environments may have murky administrative boundaries. IP QoS must allow nodes belonging to different national and international organizations to work together to support end-to-end QoS. Supporting end to end QoS services within a heterogeneous subnets consisting of mobile and fixed networks will be part of this challenge. This work will start from IETF significant body of IP QoS work focused on fixed network applications; IntServ, DiffServ, RSVP/NSIS and Traffic Engineering/MPLS.

3.4 Information Assurance

PROBLEM STATEMENT Security measures for fixed wired networks involve availability, integrity, authentication, confidentiality and non-repudiation. Security domains with secured boundaries are used to isolate internal resources, including networks, from external attacks in order to maintain high service availability to users. Integrity refers to mitigating the impact of denial of service events. Reliability is ensured through resource redundancy and avoidance of single point of failure points in the network. Authentication is achieved through biometrics, Common Access Card, or passwords. Encryption, extra headers, hashes, key negotiations are used to implement data confidentiality. Within a fixed network, smart cards, PKI, and data signatures are used to ensure the receipt of messages or confirm who the sender. All security concepts are included for MNWG because they all have potential for interaction with the other problem areas. A number of situations make it difficult to implement similar information assurance solutions over mobile/wireless networks.


28

• Availability- It is difficult to ensure availability of given resources with changing boundaries. Security boundaries are difficult to maintain with mobile network infrastructure and users due to uncertainty of location, connectivity, etc.

• Integrity- It is more difficult to maintain resource redundancy and avoidance of single point of failures due to uncertainty of location, connectivity, etc., associated with mobile network infrastructure and users.

• Authentication- o It is more difficult to authenticate users crossing service domains due to mobility. o Limited network capacity and quality will make overhead of authentication

costlier than for fixed wired network. • Confidentiality: The overhead associated with encryption will be harder to maintain due

to lower communications capacity and quality associated with mobile and/or wireless networks. The cost is higher and the impact of lost header information due to data loss is potentially worse. Key distribution is more difficult for similar reasons.

• Non-repudiation: The fixed non-repudiation implementation is too heavy t for wireless/mobile applications.

BACKGROUND The IAS Core Enterprise Services (CES) are a framework and family of services that provide a foundation to implement uniform, consistent and effective IA methodology. The IAS CES contributes to, but is not sufficient to ensure the security level of each service. Service providers and users invoke it as needed to satisfy business and policy requirements and reduce cost. IAS is defined as: measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection and reaction capabilities. IAS is to provide both physical and logical security services. The logical security services include the following: • Availability-is the "state where information is in the place needed by the user, at the time

the user needs it, and in the form needed. The issues that most directly affect availability are information system reliability (e.g. is it up and running?), the informational level of importance (some information is more critical than others), and timely information delivery (delay of some information has a greater impact than other information).

• Integrity- System integrity looks at the overall architecture of the system and how it is implemented. The design has to follow best practices and considers how various devices affect the overall design. It would be counterproductive to place a chokepoint into a network that would become a prime target for an enemy to hit, or that could bring down the network if it became inoperable. Not only are we concerned with how the system is designed, but also how it will be maintained. We do not want to make it more costly to maintain than what the information is worth. Therefore, contingency plans need to be in place so we can continue our operations during these types of events.

• Authentication- the two elements often associated with authentication are logins and passwords. Not only do people need to be authenticated, so do devices. The network might need to confirm where it is getting its information. This authentication process is often called a network protocol. Authentication also ensures that the needed information is


29

not altered between the time it is generated and the time it is received. Network operations personnel who are looking for unusual activities on the network.

• Confidentiality- is the assurance that information is not disclosed to unauthorized entities, services or processes. The idea behind Information Assurance is to protect against modification or destruction of information, service or resources. In other words, Information Assurance is the method to keep information across the wireless medium from being disclosed to unauthorized entities, services or processes.

• Non Repudiation- assurance that the originator of and action (e.g., information process) and the recipient of a reaction are known so that neither can deny having processed that action. There are three types of services in non-repudiation: non-repudiation of origin, non-repudiation of submission, and non-repudiation of delivery. Non-repudiation of origin protects against any attempt by the message originator to deny sending a message. Non-repudiation of submission protects against any attempt by message transit point to deny that a message was submitted for delivery. Non-repudiation of delivery protects against any attempt by a message recipient to deny receiving a message. Two of the services that support non-repudiation are data signature and encryption.

RELATED WORK Much of the work list below may not available to an international audience, i.e., NCOIC-global. It is hoped that over time country-specific organizations supporting NCOIC-global will evaluate and help make publicly available those aspects impacting net-centric behaviors and interoperability. This knowledge would be reflected in the IA component of the NCO reference model helping promote interoperability across international organizations. The following organizations have developed publicly available work relevant to IA: • IETF’s Security Architecture for the Internet Protocol. IPsec

http://www.ietf.org/html.charters/OLD/ipsec-charter.html • Net-Centric Checklist, www.defenselink.mil/nii/org/cio/doc/NetCentric_Checklist_v2-1-

3_May12.doc • Net-Centric Operations Warfare Reference Model, Version 1.0,

http://iase.disa.mil/newtoia.html • DoD 8500 Information Assurance - www.dtic.mil/whs/directives/corres/html/85001.htm • DoD Net-Centric Information Assurance Strategy-

http://akss.dau.mil/dag/Guidebook/IG_c7.2.4.6.asp INTERACTIONS The technical subjects associated with managing intermittent connectivity and wide capacity range of resources will be addressed in other sections of the MNO such as routing, QOS and network planning. The IA goal is to develop a framework to support the wireless and mobile standard that is incorporated into the proposed MNE architecture. Based on MNO architecture, an Information Assurance risk management program will be developed to incorporate a CONOPS & COOP program along with the proposed mobile network solution. The IAS framework will provide the policies to protect and defend the MNO mobile/wireless


30

architecture, ensuring the solution’s availability, integrity, authentication, confidentiality and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection and reaction capabilities. Information Assurance will impose requirements and/or expectations on all problem areas. It will provide the domain security model(s) requiring support from all MNE options under consideration. The model(s) include requirements or at least the basis for requirements for dealing with security enclaves, trust, secure handoffs, AAA, etc. Specifically, the IA problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas-interactions YES/NO: • Network Planning and Management-YES: Information Assurance and Network Planning

and Management will interact to evaluate network planning and management’s responsibility for managing security.

• Application Interactions-YES: Applications Interactions and Information Assurance will interact to evaluate solutions for securing this edge of the network.

• QoS-YES: Information Assurance and QoS will interact to evaluate solutions for securing QoS functions.

• Transport Layer Protocols-YES: Information Assurance and Transport Layer Protocols will interact to evaluate solutions for securing transport layer protocols. (no encryption, dependence on network or Data link layer encryption or Transport Layer Security, etc)

• Network and Node Mobility-YES: Information and Assurance and Network and Node Mobility will interact to evaluate how options support IA requirements including security models, secure handoffs, and AAA over mobile network and node scenarios.

• Ad hoc Network-YES: Information Assurance and Ad hoc Networks will interact to evaluate how options support IA requirements including security models, secure handoffs, and AAA over Ad hoc networks.

• Routing-YES: Information Assurance and Routing will interact to evaluate options for securing routing.

• Multicast-YES: Information Assurance and Multicast will interact to evaluate options for securing multicast (routing and group membership).

• Physical & Data link Constraints-YES: Information Assurance and Physical and Data link Layer Constraints will interact to evaluate options for securing physical and Data link resources.

NCOIC WGs • BB-NO: No direct interaction. MNE’s Information Assurance effort will indirectly affect

BBWG through orchestration of other problem areas security concerns. Those problem areas will then feed to Building Block WG requirements and/or expectations to help them


31

select secure net-centric friendly products. The IAWG will be responsible for providing IA-specific criteria to Building Block WG for their selection process.

• CR-NO: No direct interaction. MNE’s Information Assurance problem area will obtain motivating guidance from Information Assurance WG which may, or may not, receive guidance from CRWG.

• EP-NO: Information Assurance will depend on other problem areas it is supporting to forward terms to Engineering Process’ lexicon.

• IA-YES: Information Assurance problem area will interact with Information Assurance WG to ensure that all problem areas adhere to net-centric enabling security requirements.

• Lexicon-NO: Information Assurance will depend on problem areas it is supporting to forward terms to Lexicon WG.

• NCAT-NO: Information Assurance evaluation will depend on problem areas it is supporting to interact with NCAT to develop interoperability criteria for network and node mobility environments.

• NIF-NO: No direct interaction. MNE’s Information Assurance problem area effort will indirectly contribute to framework and PFCs through other problem areas and IAWG.

• SII-NO: No direct interaction. IAWG is expected to coordinate the security concerns in the SII-SCOPE model and forward relevant portions to the other problem areas.

CONCLUSIONS The IA goal is to develop a framework to support the MNE wireless and mobile standard that is incorporated into the proposed MNE architecture. Based on MNO architecture, an Information Assurance risk management program will be developed to incorporate a CONOPS and COOP program with the proposed mobile network solution. An IA framework will be developed to provide the policies to protect and defend the MNO mobile/wireless architecture ensuring the solution’s availability, integrity, authentication, confidentiality and non-repudiation. This includes restoration of information systems by incorporating protection, detection and reaction capabilities.

3.5 Transport Layer Protocols (TLP)

PROBLEM STATEMENT Transport layer protocols are a set of rules used to send data in the form of message units from a source to a destination. This work will focus on TCP, UDP, Real Time Transport Protocol (RTP), DCCP and Stream Control Transport Protocol (SCTP). These protocols were optimized for a wired Internet, where paths are stable relative to routing convergence times, packet reordering is at a minimum and virtually all packet losses are due to congestion drops at routers. The transport layer protocol should not only focus on the classical Internet defined protocols. It should also take into account the optimization required in a context of scarce wireless resources. Within context of mobile environment it may be desirable to adjust protocol timers to operate more efficiently. These implementations have problems responding to the unique sources of


32

packet loss associated with mobile infrastructure such as Bit Errors and Burst errors, as well as relatively dynamic routes and capacity. In addition, the propagation delay issue historically associated with Satellite Communications (Satcom) links may also adversely affect transport protocols over longer range and/or low and/or intermittent link capacity mobile networks. Also, problems such as link congestion or failure cause the transport Round Trip Time (RTT) to expire and retransmit causing an overall network performance problem, adding to the intermittent link problem. A number of advanced transport capabilities are being developed by various IETF working groups (TSVWG, TCPM...) to deal with the link problems. This problem area will evaluate how the modifications affect interoperability between fixed and mobile transport. BACKGROUND The Transport Protocols operate within the IP Reference Model at layer 4 and provide the end-to-end connections between two nodes over IP. There are different transport protocols to provide different guarantees. The dominant ones for today are: TCP, UDP, SCTP, RTP and DCCP, which is work in progress. These protocols were architected and defined for fixed wired networks not wireless and/or mobile networks. The IETF has developed many extensions to these protocols to improve operation over wireless and/or mobile networks. The MNE must identify the extensions that address the problem at hand for Mobile Networks. Specifications for TCP over 2.5 and 3G Wireless Networks did not deal with many of the issues faced with NCO. For example the MANET routing protocols for Mobile Ad Hoc Networks did not add enhancements or guidance to deal with connectivity to external networks like Satcom or Microwave Towers. They also did not deal with congestion and latency occurring because of Multi-hop communications within a mobile ad hoc network. The congestion and latency problems are not really in the scope of bodies that work on Mobility or MANET. The problems require the expertise of transport layer protocol designers and practitioners. The MNWG will perform technical analysis and evaluation of the transport protocols and their extensions to ascertain their support of network mobility and their support as net-centric enabling capabilities. This work will provide suggestions and a set of recommendations. The transport layer also significantly impacts the ability for QoS to be maintained once defined on a network, and often the transport layer requires monitoring to identify changes in the QoS rates and best-routing-paths between networks or end nodes. Each Transport Protocol approximates and identifies methods to improve transport scalability, performance and flow of transport packets over a link. MNWG will need to perform additional technical analysis and evaluation regarding the relationship of QoS to Transport Protocol operations on a mobile network. There is constant work on going to improve congestion and latency on networks in general and NCOIC will need to interact with that related work. The objective of this interaction for the MNWG will be to identify where such R&D improvements assist with the network mobility problem space defined. An emerging problem for networks relying on deep packet inspection (transport layer


33

protocol payload) involves the movement towards the end-to-end security model. The entire packet will be encrypted below the IP header, which means that intermediate nodes will not be able to view the transport layer to fine-tune congestion response or QoS on a network. This is critical for mobile networks and will require analysis to determine deployment ramifications as part of the model to view the transport layer for mobile networks. Transport Protocols are critical to mobile networks. The combination of Seamless Mobility, Wireless and Satcom communications puts a stress on the current model and implementation of transport layer methods. It is mandatory for the MNWG to perform technical analysis and evaluation of current and emerging Transport Layer protocols. RELATED WORK • De jure Standards forum is the IETF www.ietf.org, and no other body develops any

standards for the IP Reference Model Transport Layer for the general industry today, but see SCPS reference below. Most work is done within the Transport Area of the IETF http://ietf.org/html.charters/wg-dir.html#Transport%20Area.

• Industry Systems Integration and IT hardware and software vendors providing custom solutions today in the market to support wireless networks.

• Research and Development work to perform studies on transport layer congestion in networks, such as the Delay Tolerant Networking Research Group www.dtnrg.org or research projects on this problem within DARPA

• International government organizations and departments working on transport extensions to resolve latency and congestion on networks.

• Space Communications Protocol Standards (SCPS) www.scps.org • Interplanetary Internet Project www.ipnsig.org.

INTERACTIONS Transport Protocol work will interact with the all the entities listed above under the section Related Work for Transport Protocols. Specifically, the TLP problem area has interactions with the following problem areas and NCOIC working groups:

Problem Areas-interactions YES/NO: • Network Planning and Management-YES: Transport Layer Protocols and Network

Planning and Management and will interact to evaluate network planning and management responsibility for transport control protocols.

• Application Interactions-YES: Transport Layer Protocol and Applications Interaction will interact to evaluate solutions enabling applications to tune transport layer settings to optimize operation over mobile and/or wireless environment.


34

• QoS-YES: Transport Layer Protocol and QoS will interact to evaluate transport layer protocol solutions QoS quality and its interaction with larger E2E QoS.

• Information Assurance-YES: Transport Layer Protocols and Information Assurance will interact to evaluate solutions for securing transport layer protocols (no encryption, dependence on network or Data link layer encryption or Transport Layer Security, etc).

• Network and Node Mobility-YES: Transport Layer Protocol and Network and Node Mobility will interact to evaluate transport control protocol(s) for optimizing operations over mobile network and node scenarios.

• Ad hoc Network- YES: Transport Layer Protocol and Ad hoc Network will interact to evaluate transport control protocol(s) for optimizing operations over Ad hoc networks.

• Routing-NO: No direct interaction. Routing should be transparent to Transport Layer protocols.

• Multicast-YES: Transport Layer protocol and Multicast will interact to evaluate transport layer protocols support for multicast sessions over wireless and/or mobile network.

• Physical & Data link Constraints-YES: Transport Layer Protocol and Multicast will interact to evaluate options for improving transport layer performance through interaction with physical and data link resources.

NCOIC WGs • BB-YES: The Transport Layer Protocol evaluation effort is responsible for providing

transport layer-specific criteria to Building Block WG for their selection process. • CR-YES: The Transport Layer Protocol evaluation will identify requirements through

Mission Thread/Use Case Analysis. • EP-YES: The Transport Layer Protocol evaluation will synchronize its contribution to

MNE lexicon with EPWG’s lexicon and also coordinate with EPWG’s modeling and simulation effort to develop next steps for evaluating impact of transport layer protocol options on network mobility.

• IA-NO: Transport Layer Protocol security requirements will be addressed through MNE IA problem area.

• Lexicon-YES: Transport Layer Protocol effort feeds terms to this effort. • NCAT-YES: The Transport Layer Protocol effort will review Nat’s evaluation criteria

and build on them based on MNE experience. • NIF-YES: The Transport Layer Protocol effort will contribute transport layer content to

the NIF and PFCs. • SII-YES: SII’s SCOPE is expected to help define the problem-space and domains to be

evaluated by Transport Layer Protocols. CONCLUSIONS Transport layer protocols are a set of rules used to send data in the form of message units from a source to destination. This work will focus on TCP, UDP, RTP, DCCP and SCTP. These protocols are designed for a wired Internet, where paths are stable, packet reordering is at a minimum, and virtually all packet losses are due to congestion drops at routers. Transport Protocols are critical to mobile networks, and the combination of Seamless Mobility, Wireless


35

and Satcom communications puts a stress on the current model and implementation of transport layer methods. User or application has to restart the session when "break" occurs due to mobility. The focus of this work is on mobility's impact on end hosts and network proxies’ ability to optimize transport over RF environments. The added challenge is IP encryption rendering transport header transparent to these capabilities.

3.6 Network and Node Mobility (NNM)

PROBLEM STATEMENT Network and Node Mobility deals with 1) individual nodes moving within and between networks and sub networks, 2) a network detaching from one part of a stable network and reattaching to another part of that same network, 3) individual nodes detaching from one network element and connecting to another network element, and 4) functions associated with mobility management. It is desirable to maintain network services for mobile nodes and networks as they change their access points without administrative action. Current fixed network architectures do not support such mobility easily. These fixed architectures and their attendant services are based upon a static network and service configuration that can only be altered with administrative action, usually requiring considerable planning and service disruption. This section will identify and discuss networking architectural components and functions of Network and Node mobility with respect to a stable network. Problems associated with networks that have no intrinsically stable components are discussed in the ad hoc section. Mobility management, an industry standard term, includes location update, registration, handover control, and session continuity. Problems addressed in this section include mobility management, interaction with legacy equipment, mobile access to network services, and efficient identification and addressing for mobile nodes and networks within a stable infrastructure. BACKGROUND A mobile node is a simple or complex device whose location and point of attachment to the network may change. This node may be a cell phone, handheld device, radio, or laptop computer, and additionally may function as a router. Because traditional commercial Internet routing was developed for stationary and terrestrial devices, special routing and addressing support is required to maintain network connections and prevent packet loss for a mobile node as it moves. Various working groups within the Internet Engineering Task Force (IETF) have addressed the needs of mobile nodes through the development of several standards, proposed standards, or Internet drafts, including Mobile IP version 4 (MIPv4), Mobile IP version 6 (MIPv6), Hierarchical Mobile IP version 6 (MHIPv6), and Mobile Ad Hoc Network (MANET) routing protocols. Note: MANET routing protocols are covered in the Routing section of this document. Network mobility occurs when an entire network changes its point of attachment to a serving network such as the global internetwork. A mobile network can have fixed nodes, such as a modern computer based automobile or airplane travelling to its destination, or the nodes


36

themselves can be mobile, such as a local MANET of disaster recovery workers changing its point of attachment to a Tier 1 transit network to the Disaster Command Center. Network mobility has only recently been addressed, starting in 2002 with the Mobile Network (MONET) working group in the IETF, with continuing work being done by the Network Mobility (NEMO) working group. Current technologies are still in their infancy, and are derivations of commercial technologies for mobile nodes. For example, NEMO Basic Support Protocol, a proposed standard from the NEMO working group, is an extension to MIPv6. Use of Virtual Private Networks (VPNs) is another option to address network mobility. Designing an approach to support mobile networks from the outset should be considered. The link by which a mobile node or network is connected may often be a wireless link. Consequently, this link probably has a substantially lower bandwidth and higher error rate than traditional wired networks, and is most likely battery powered. Therefore, the number and size of control and management plane messages sent over the link to the mobile node or network should be minimized. Besides the previously mentioned physical link limitations, the essential problem of mobility management is efficiently getting data to/from a mobile entity which can be anywhere or nowhere. The first part of getting data to a mobile entity is identifying the entity’s location. This is the location component of mobility management. One problem of importance to interoperability in mobility management is technology convergence. For different radio systems to communicate, a mobile node will need multiple wireless interfaces. For example, a handheld device may have both cellular and 802.11 capability. Mobility management of the mobile node that can select the interface applicable for the situation is of crucial importance, especially for handoffs between different wireless networks. Mobility management must address three types of handoffs with the goal of minimizing disruption for the mobile node or network: link-level handoff, intra-domain (subnet-level) handoff, and inter-domain handoff. Registration or authorization, authentication, and accounting (AAA) is the third area of importance for mobility management. As nodes and networks move, security associations (SAs) need to be set up among multiple entities. Research work is in progress to combine Mobile IP messages and AAA protocol messages to reduce message overhead. Efficient addressing and routing for mobile nodes and networks is also important. RELATED WORK European Telecommunications Standards Institute (ETSI), Internet Engineering Task Force (IETF), Institute of Electrical and Electronics Engineers (IEEE), Third Generations Partnership Project (3GPP), Third Generation Partnership Project 2 (3GPP2), and the International Telecommunications Union (ITU) are the organizations performing related work in Network and Node Mobility. Applicable working groups in these organizations are cited in the paragraphs below.


37

Work in network and node mobility is being done by various working groups (WGs) in the IETF such as NEMO, Mobility for IP version 4 (mip4), Mobility for IP version 6 (mip6), and Mobile Nodes and Multiple Interfaces in IPv6 (monami6). . For mobility management, the MIPv6 Signalling and Handoff Optimization (mipshop) WG in the IETF is developing two approaches for addressing handoff issues for mobile nodes, HMIPv6 and Fast Handovers for Mobile IPv6 (FMIPv6). These are considered to be localized mobility management (LMM) approaches. The mip6 WG in the IETF is working on various mobility management issues including management of dual stack nodes. Netlmm WG is developing approaches for network-based localized mobility management. In the Third Generation Partnership Project 2 (3GPP2), the Technical Specifications Group (TSG) Access Network Interfaces (TSG-A) technical specification group is doing work on access network mobility and the TSG Core Networks (TSG-X) technical specification group is doing work in mobility management. The International Telecommunications Union – Telecommunications (ITU-T) Study Group 19 (Mobile Telecommunications Networks) is doing work on mobility management and convergence of fixed and mobile networks. In the Third Generation Partnership Project (3GPP), the Technical Specification Group (TSG) Core Network and Terminals Working Group 4 (WG4) (TSG CT WG4) is doing work on mobility management. In the IEEE, the IEEE 802 LAN/MAN Standards Committee is doing standards work on handoffs (802.21). Other aspects of this committee seem to be more applicable to the physical and link layers. This information can be used to provide physical and link layer constraints. The mipshop WG in the IETF is working in conjunction with IEEE 802.21 group on mobility services. Example mobility services include the Media Independent Information Service, and the Media Independent Command and Event Services. Mobility services specify signalling approaches to allow information exchange across a network. INTERACTIONS NNM problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas- interaction YES/NO: • Network Planning and Management-YES: Network and Node Mobility and Network

Planning and Management will interact to evaluate options for addressing mobility management.


38

• Applications Interactions-YES: Network and Node Mobility and Applications Interactions will interact to evaluate options increasing interaction to improve performance for mobile network and node scenarios.

• QoS-YES: QoS and Network and Node Mobility will interact to evaluate mobility enabling solutions’ ability to support QoS during hand-offs.

• Information Assurance-YES: Network and Node Mobility and Information Assurance will interact to evaluate how options support IA requirements including security models, secure handoffs, and AAA over mobile network and node scenarios.

• Transport Layer Protocol- YES: Network and Node Mobility and Transport Layer Protocol will interact to evaluate transport control protocol(s) for optimizing operations over mobile network and node scenarios.

• Ad hoc Network-YES: Network and Node Mobility and Ad hoc Networks will interact to evaluate how mobility is supported by Ad hoc networking options. Mobility scenarios include moving network and infrastructure, and moving network, nodes and infrastructure.

• Routing-YES: Network and Node Mobility and Routing will interact to evaluate how routing supports mobile nodes and networks.

• Multicast-YES: Network and Node Mobility and Multicast will interact to evaluate multicast solutions for mobile nodes and networks. The solutions have to address both the maintenance of routing paths and group membership.

• Physical and Data link Constraints-YES: Network and Node Mobility and Physical and Data Link Constraints will interact to evaluate the options for improving support of network and node mobility scenario over physical and data link resources.

NCOIC WGs • BB-YES: Network and Node Mobility will recommend standards to help Building Block

evaluate products’ ability to support Ad hoc operations in net-centric enabling manner. • CR-YES: Network and Node Mobility requirements will be driven by input from Mission

Thread/Use Case Analysis from Customer Requirements WG. • EP-YES: Network and Node Mobility will provide terms to Engineering Process’

lexicon. The effort may also motivate modeling and simulation. • IA-NO: Network and Node Mobility security requirements will be evaluated through

MNE IA problem area. • Lexicon-YES: Network and Node Mobility evaluation will forward terms to Lexicon

WG. • NCAT-YES: Network and Node Mobility evaluation will interact with NCAT to develop

interoperability criteria for network and node mobility environments. • NIF-YES: Network and Node Mobility evaluation will interact with NIF to develop

NCO framework and PFCs. • SII-YES: Network and Node Mobility will use SII WG’s SCOPE model to help bound

problem space and evaluate alternatives. CONCLUSIONS Network and node mobility solutions address the needs of 1) individual nodes moving within and between networks, 2) a network detaching from one part of a stable network and


39

reattaching to another part of that same network, and 3) functions associated with mobility management. This includes addressing, security, NEMO, MobileIP and mobility management (with infrastructure) – location update, registration, DNS / DHCP, handover, autonomous behaviour.

3.7 Ad Hoc Networks (AHN)

PROBLEM STATEMENT Ad hoc networks are those networks that are capable of forming and operating without any fixed infrastructure. Ad hoc networks may consist of nodes from different domains or the same domain, forming a network for a temporary time to achieve specific objectives. These networks may communicate with fixed infrastructure networks, either public or private. The members of an ad hoc network should be capable of starting in arbitrary order with an indefinite build up time, i.e., nodes could arrive to participate days or weeks after initial network start-up. The members of an ad hoc network should not generally be dependent upon the existence of a particular node in the network for operation, and generally are formed without extensive planning on the part of the users. Ad hoc networks may be composed of fixed and/or mobile nodes. If the nodes are mobile, the network is considered a mobile ad hoc network or MANET. Fixed networks are normally built with significant planning. However, in certain situations, such as disaster relief, it is desirable to quickly form a communication network with the pieces immediately available on location where the established infrastructure is severely damaged or non existent. This problem falls within the context of mobility in the sense that while the components may or may not be active while mobile, the components are moved to an arbitrary location and expected to operate in the new location without significant effort on the part of the users. There is also the issue of coupling the ad hoc network to the enterprise network since few ad hoc networks are truly self-contained. Usually there is a desire/need to interact with those entities that are outside the ad hoc network as well as those inside the network. In addition, it is often desired to identify all the users on an ad hoc network devoted to a specific task such as all the Red Cross workers, as well as identify the network to which a particular user belongs such as the leader of the Red Cross team. This problem area deals with mobility management of ad hoc networks, which includes location, registration, session continuity, and handoff. It also deals with network set-up, and efficient identification, addressing, and routing for ad hoc networks. BACKGROUND With recent performance advancements in computer and wireless communications technologies and the need for users to form temporary networks to achieve a specific purpose, ad hoc wireless networking is expected to see increasingly widespread use and application, much of which will involve the use of the Internet Protocol (IP) suite. Such networks are envisioned to have dynamic, sometimes rapidly-changing, random, multi-hop topologies


40

which are likely composed of relatively bandwidth-constrained wireless links. A node may be connected through various means to the Internet and to other nodes, except to the well known fixed-address domain space. The host may be directly connected physically to the fixed network on a foreign subnet, or be connected via a wireless link, dial-up line, etc. Supporting this form of node mobility (or nomadicity) requires address management, protocol interoperability enhancements and the like, but core network functions such as hop-by-hop routing still presently rely upon pre-existing routing protocols operating within the fixed network. In contrast, the goal of ad hoc networking is to extend connectivity into the realm of autonomous, wireless and perhaps mobile domains, where a set of nodes may combine routers and hosts form the network routing infrastructure in an ad hoc fashion. There is current and future need for dynamic ad hoc networking technology. The emerging field of mobile and nomadic computing, with its current emphasis on IP capability, should gradually broaden and require highly-adaptive mobile networking technology. This allows it to effectively manage multi-hop, ad hoc network clusters which can operate autonomously or be attached at some point(s) to a fixed network infrastructure. Some applications of mobile ad hoc network technology could include industrial and commercial applications involving cooperative mobile data exchange. In addition, mesh-based mobile networks can be operated as robust, inexpensive alternatives or enhancements to cell-based mobile network infrastructures. There are also existing and current military networking requirements for robust, IP-compliant data services within mobile wireless communication networks. Many of these networks consist of highly-dynamic autonomous topology segments. In addition, the developing technologies of "wearable" computing and communications may provide applications for mobile ad hoc network technology. When properly combined with satellite-based information delivery, mobile ad hoc network technology can provide an extremely flexible method for establishing communications for fire/safety/rescue operations or other scenarios requiring rapidly-deployable communications with survivable, efficient dynamic networking. There are likely other applications for mobile ad hoc network technology which are not presently realized or envisioned by industry. Simply put, improved IP-based networking technology for dynamic, autonomous wireless networks. A mobile ad hoc network consists of mobile platforms (e.g., a router with multiple hosts and wireless communications devices), simply referred to as "nodes", which are free to move about arbitrarily. The nodes may be located in or on airplanes, ships, trucks, cars, perhaps even on people or very small devices, and there may be multiple hosts per router. A mobile ad hoc network is an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to interface with a fixed network. In the latter operational mode, it is typically envisioned to operate as a "stub" network connecting to a fixed Internet network work. Stub networks carry traffic originating at and/or destined for internal nodes, but do not permit exogenous traffic to “transit" through the stub network. Ad hoc nodes are equipped with wireless transmitters and receivers using antennas which may be omnidirectional (broadcast), highly-directional (point-to-point), possibly steer able, or some combination thereof. At a given point in time, depending on the nodes' positions,


41

transmitter and receiver coverage patterns, transmission power levels and co-channel interference levels, a wireless connectivity in the form of a random, multi-hop graph or ad hoc network exists between the nodes. This ad hoc topology may change with time as the nodes move or adjust their transmission and reception parameters. Mobile Ad Hoc Networks have several salient characteristics: • Dynamic topologies: Nodes are free to move arbitrarily; thus, the network topology which

is typically multi-hop may change randomly and rapidly at unpredictable times, and may consist of both bidirectional and unidirectional links.

• Bandwidth-constrained, variable capacity links: Wireless links will continue to have significantly lower capacity than their hardwired counterparts. In addition, the realized throughput of wireless communications--after accounting for the effects of multiple access, fading, noise, and interference conditions, etc., is often much less than a radio's maximum transmission rate.

• Energy-constrained operation: Some or all of the nodes in a MANET may rely on batteries or other exhaustible means for their energy. For these nodes, the most important system design criteria for optimization may be energy conservation.

• Limited physical security: Mobile wireless networks are generally more prone to physical security threats than are fixed- cable nets. The increased possibility of eavesdropping, spoofing, and denial-of-service attacks should be carefully considered. Existing link security techniques are often applied within wireless networks to reduce security threats. As a benefit, the decentralized nature of network control in MANETs provides additional robustness against the single points of failure of more centralized approaches.

One effect of the relatively low to moderate link capacities is congestion which is typically the norm rather than the exception, i.e. aggregate application demand will likely approach or exceed network capacity frequently. As the mobile network is often simply an extension of the fixed network infrastructure, mobile ad hoc users will demand similar services. These demands will continue to increase as multimedia computing and collaborative networking applications rise. In addition, some envisioned networks (e.g. mobile military networks or highway networks) may be relatively large (e.g. tens or hundreds of nodes per routing area). The need for scalability is not unique to MANETs. However, in light of the preceding characteristics, the mechanisms required to achieve scalability likely are unique to MANETs. These characteristics create a set of underlying assumptions and performance concerns for protocol design which extend beyond those guiding the design of routing within the higher-speed, semi-static topology of the fixed Internet. This introduction was adapted entirely from IETF RFC 2501 (ftp://ftp.rfc-editor.org/in-notes/rfc2501.txt). MANET is a critical network technology component for Mobile Networks and important for NCOIC to understand the technology options regarding the communications layer model,


42

architecture, standards, best current practice, and deployment options today and in the future. The NOCIC Mobility Working Group will perform the technology analysis on MANET to identify and report the technology options. RELATED WORK Related work on MANET for NCOIC has several forms and data points for which the NCOIC Mobility Working Group will be required to understand regarding in other industry efforts. • De jure Standards forums, such as IETF www.ietf.org, ITU www.itu.int, 3GPP

www.3gpp.org, and 3GPP2 www.3gpp2.org. • Industry Networking Consortia forums, such as WIMAX www.wimaxforum.org, IPsphere

www.ipsphereforum.org, IPv6 Forum www.ipv6forum.com, ATIS www.atis.org, W2COG www.w2cog.org, Open Group www.opengroup.org, NDIA www.ndia.org, AFCEA www.afeca.org, and AFEI/NCOIF www.afei.org.

• Industry Systems Integration and IT hardware and software vendors providing MANET solutions today in the market. Research and Development work to perform studies on MANET networks in progress today.

• International government organizations and departments working on MANET as important network technology for their deployment models and implementations.

INTERACTIONS Ad hoc Networks work will interact with all the entities listed above under the section Related Work for MANET. Specifically AHN problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas- interaction YES/NO: • Network Planning and Management-YES: Ad hoc Network and Network Planning and

Management will interact to evaluate solutions for planning and managing Ad hoc networks which are “human-in-the-loop” before deployment and self planned and managed during deployment or operations.

• Applications Interactions-YES: Applications Interactions and Ad hoc Networks will interact to evaluate how applications increase interaction with Communication layers to optimize operations over Ad hoc networks.

• QoS-YES: Ad hoc networks and QoS will interact to evaluate solutions ability to support QoS over Ad hoc networks.

• Information Assurance-YES: Ad hoc Networks and Information Assurance will interact to evaluate how options support IA requirements including security models, secure handoffs, and AAA over Ad hoc networks.


43

• Transport Layer Protocol- YES: Ad hoc Network and Transport Layer Protocol will interact to evaluate transport control protocol(s) for optimizing operations over Ad hoc networks.

• Network and Node Mobility-YES: Ad hoc Networks will interact with Network and Node Mobility to evaluate how Ad hoc networks will support scenarios where the nodes, network and infrastructure are moving.

• Routing-NO: Routing, to first order, is independent of network being Ad hoc (mostly self managed) vs. general network (mostly human-in-the-loop managed operation).

• Multicast-NO: Multicast (routing and group membership), to first order, is independent of network being Ad hoc (mostly self managed) vs. general network (more human-in-the-loop managed) operation.

• Physical and Data link Constraints-NO: Physical and Data link Constraints, to first order, is not impacted by Ad hoc vs. managed operations.

NCOIC WGs • BB-YES: Ad hoc Networks will recommend standards to help Building Block evaluate

products ability to support Ad hoc operations in net-centric enabling manner. • CR-YES: Ad hoc Networks requirements will be driven by Mission Thread/Use Case

Analysis from Customer Requirements WG. • EP-YES: Ad hoc Networks will provide terms to Engineering Process’ lexicon. The

effort may also motivate modeling and simulation. • IA-NO: Ad hoc Network security requirements will be evaluated through the IA problem

area. • Lexicon-YES: Ad hoc Network evaluation will provide terms to Lexicon WG. • NCAT-YES: Ad hoc Network evaluation will interact with NCAT to develop

interoperability criteria for Ad hoc networking options. • NIF-YES: Ad hoc Network evaluation will help develop those portions within the NIF

and PFCs pertaining to Ad hoc networking. • SII-YES: Ad hoc network will use SII WG’s SCOPE model to help bound problem space

and evaluate alternatives. CONCLUSIONS This problem area addresses nodes networking with no infrastructure. This includes the evaluation of MANET routing protocols and other approaches such as extensions to OSPF to support MANET and Open Group's Secure Mobile Architecture. Specifically the effects of OSI layers 1 and 2 on routing and interacts with layer 3 for data and control planes for the mobile nodes only. This work will address addressing, security, mobility management (e.g. location update, DNS / DHCP, handover, registration, autonomous behaviour, etc) and ad hoc network interactions with fixed infrastructure.

3.8 Routing

PROBLEM STATEMENT


44

Routing is the means by which the network determines the path data will take through the network from the source to its destination. In the commercial internet, three protocols are predominantly used: Routing Information Protocol (RIP), Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP). These are robust protocols with the ability to detect topology changes in the internet and take appropriate action. Within the context of mobility, two main problems arise:

1) The rate of topology change is greater in a mobile network, creating more overhead as routers report changes to the rest of the network. This problem is exacerbated by the tendency of wireless links frequently used in mobile networks to change channel capacity as environmental conditions change.

2) The mobile nature of the network means that groups of contiguous addresses are no

longer likely to be logically collocated, which in turn, means that more information must be passed between routers to maintain correct routing. On a large scale, traditional routing area boundaries can become blurred, potentially creating larger problems for network planning and management in addition to the larger routing overhead.

Both of these problems are, in essence, performance/scalability issues. That is, the existing mechanisms work fine, but take an increasing share of the available bearer communications capacity, effectively reducing the communications capacity available to user applications. In addition, mobile networks often do not have as much capacity as fixed networks of similar size, making problems of performance and scalability more difficult. Additional overhead may need be consumed if IP Routing overlays such as Multi Protocol Label Switching (MPLS), Policy Based Routing or Quality of Service Routing are used on the network since these mechanisms tend to assume a stable network able to handle the additional overhead for the additional signalling these protocols need. Some nodes in a mobile environment will be more capable than others, whether due to special communications media (e.g. satellite communication link), or better equipment (e.g. higher power transmitter). When facing performance issues, it may be desirable to take advantage of these more capable nodes if they can be identified.

RELATED WORKS The challenges of mobility in a routing context are well known and extensive research and development has been conducted to resolve these issues. The IETF Mobile Ad Hoc Networking (MANET) Working Group has considered a variety of solutions and has published three experimental RFCs (AODV - RFC 3561, OLSR – RFC 3626, TBRPF – RFC 3864). In addition, the IETF OSPF Working Group has begun work on extensions to support Mobile Ad Hoc Networking to help OSPF scale better in a mobile environment. It is important to differentiate between ad hoc networks and mobile networks. Ad hoc networks set up with minimal management and are generally self contained entities that may


45

attach to the larger internet as a stub network. In contrast, mobile networks may have/use significant support resources and interact heavily with a larger internet. This section will not deal with ad hoc issues (see Ad hoc Networks for further discussion), but will deal with mobile networks. In addition to these efforts, one body of thought suggests that one might minimize the burden on routing systems by an address change or ‘care of’ address when a node moves to another part of the network with forwarding functions to maintain connectivity. This is, in essence, the idea behind Mobile IP. See the Mobile Nodes and Networks for further discussion.

INTERACTIONS This problem area interacts with the other problem areas. Specifically, Routing problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas- interaction YES/NO: • Network Planning and Management-YES: Network Management and Planning will need

to interact with routing to ensure that routing areas are established in a manner that readily supports network mobility. Routing and Network Planning and Management will interact to evaluate options for net-centric enabling management of routing for wireless and/or mobile scenarios.

• Applications Interactions-YES: Routing and Applications Interactions will interact to evaluate solutions enabling applications to optimize routing.

• QoS-YES: Routing and QoS will interact to evaluate techniques for making routing QoS-aware. Routing will interact with Quality of Service to the extent that certain Quality of Service functions take advantage of reserved network resources and routing must understand which resources are available to all users and which resources have restricted access.

• Information Assurance-YES: Routing and Information Assurance will interact to evaluate

options for securing routing. Information Assurance will need to recognize the need for routing protocols to exchange information in a timely manner to maintain network availability. Therefore, when designing security architecture, one must be careful not to draw security boundaries through routing functions which would prevent the network from learning the locations of mobile nodes. It is further desirable for routing protocols to have some level of security to prevent route spoofing and other denial of service attacks on the network infrastructure itself.

• Transport Layer Protocol-NO: No direct interaction. Routing should be transparent to Transport Layer protocols.

• Network and Node Mobility-YES: Routing and Network and Node Mobility will interact to evaluate how routing supports mobile nodes and networks.

• Ad hoc Network-NO: Routing, to first order, is independent of network being Ad hoc (mostly self managed) vs. general network (mostly human-in-the-loop managed operation).


46

• Multicast-YES: Routing and Multicast will interact to evaluate multicast routing solutions over mobile nodes and networks. Routing will provide support to multicast, recognizing that multicast uses routing information for its decision making process.

• Physical and Data link Constraints-YES: Routing and Physical and Data link Constraints

will interact to evaluate solutions optimizing routing using higher fidelity information from underlying link resources.

NCOIC WGs • BB-YES: Routing will recommend standards to help Building Blocks Functional Team

evaluate products’ ability to support ad hoc operations in net-centric enabling manner. • CR-YES: Routing requirements will be driven by input from mission thread/use case

analysis from Customer Requirements WG. • EP-YES: Routing will provide terms to Engineering Process’ lexicon. The effort may

also motivate modeling and simulation. • IA-NO: Routing security requirements will be evaluated through IA problem area. • Lexicon-YES: Routing evaluation will forward terms to Lexicon WG. • NCAT-YES: Routing evaluation will interact with NCAT to develop interoperability

criteria for network and node mobility environments. • NIF-YES: Routing evaluation will interact with NIF to develop NCO framework and

PFCs. • SII-YES: Routing will use SCOPE model to help evaluate alternatives. • SII-YES: Routing will use SII WG’s SCOPE model to help bound problem space and

evaluate alternatives. CONCLUSIONS Numerous solutions have been devised for routing in a mobile environment. What is not clear is where the various solutions are appropriate and under which conditions they function poorly or not at all. The analysis of the MNE will attempt to differentiate between the solutions in a readily accessible manner to provide system designers the means to select the best solution for their system. Specifically this work will address layer 3 data and control planes, i.e. routing from IP upward, intra and inter domain routing, routing security, routing performance in control and data planes (rate of topology change effects) and routing of mobile entities with fixed networks.

3.9 Multicast

PROBLEM STATEMENT Multicast in mobile environments expands on multiple layers of the IP reference model. Many developments apply to mobile extensions of the current IP layer multicast such as forwarding decisions (e.g. routing), node memberships (e.g. multicast addresses), as well as cross-layer


47

specifications/implementations such as Multicast Security, and Reliable Multicast, plus multicast applications that are scoped for either mobile or fixed environment group listeners. This Problem statement will address the above developments except Multicast Security and Multicast Applications. Multicast problems exist in fixed networks and they are also inherent in mobile networks. Guidelines for efficient interoperability among multiple independent multicast routing domains, where specific instantiations of these are given in standard multicast routing protocols, as well as other industry proposals. Future versions of these protocols, may describe their interoperability procedure by stating how the specifications apply to them. This section will focus on source mobility even though group member mobility (i.e. receivers) might also impact multicast sessions. Multicast has distinct functions such as Source Specific Multicast (SSM) and Any Source Multicast (ASM) yet each could be mobile. Additionally, multicast routing is not seamless and it is slow, such as branch reconstruction, real-time communications requirements and handoffs MUL-1. ASM implementation, in particular, focuses on this problem area, where several approaches have been considered such as remote subscription, bi-directional tunneling and Agent-Based, yet each have technical issues attributed to mobile communications.

A. Remote Subscription

In remote subscription, the mobile node is forced to re-initiate multicast distribution subsequent to handover, using its current Care-of AddressMUL-4. Each mobile node (source) has functional issues to face. A few problems are briefly listed:

• Distribution tree is somehow rooted at source node and collapses after movement where reconstruction (up rooted tree) could take minutes.

• Multicast address problem is based on source address (logical and topological ID), where the address assumes a dual role that may be ineffective in a mobile scenario. during a binding update may not be valid

• Source activation problem is based on the new source being discovered by inter-domains. This implies overhead costs.

The decoupling problem is based on the source node having no feedback from receivers where in the event of an inter-tree handover, a mobile multicast source can be vulnerable to losing receivers without taking notice. For example, an originator of a conference call is not given an audible sound if a receiver (i.e. mobile node) is moving and becomes detached from the network. B. Bi-directional Tunneling This approach guides the mobile node to tunnel all multicast data via its home agent MUL-4. Tunneling can contribute to inefficient overhead. For example, when a home agent receives a Multicast datagram destined for a mobile host, it encapsulates the datagram twice (with the mobile host address and the care-of address of the mobile host) and then transmits the datagram to the mobile host as a unicast datagram. The home agent must build a tunnel from


48

itself to the mobile host. In this scenario, reconstruction of the multicast tree is typically safeguarded from issues as designed for fixed infrastructure intent, but when there are many mobile hosts moving (and discovering) to the same foreign agent, there are many tree copies sent which could likely collapse the foreign agent. This is considered a tunnel convergence problem. C. Agent-Based Agent-based solutions attempt to balance between the previous two mechanisms. Static agents typically act as local tunneling proxies, allowing for some inter-agent handover while the mobile node moves away MUL-4. The requirements for use of current Care-of-Address for routing and use of Home-Address in the Destination option at the receiver where routers maintain Source Specific States and receivers need to subscribe to a source address respectively. The problem occurs when the source can not control receiver updates, which may lose receivers on handover during mobile detachment and reattachments. This might cause “tree walking”. From a cellular perspective, cellular operators interpret multicast differently, such as multicast semantics requiring re-examination in the presence of host mobility. Their interpretation is based on practitioner experience for multicast and usually Cell-limited, not IP-based Multicast envisioned for Beyond 3G Internet. Design implications of IP-based multicast and multipoint mobile links have their obstacles when deciding optimal solutions. For example IGMP was designed with Ethernet in mind. It’s not really suitable for routers with point-to-point links, where IGMP queries have to be issued to each one of these links causing more state information needed at the router. BACKGROUND Multicast delivers data from one source to multiple destination nodes. It uses internet Group Management Protocol (IGMP) to maintain the group memberships between the hosts and Multicast routers. Whenever and wherever, any multicast group member can join or leave the group, without the limitation of the total number of the members in the group. Multicast uses special multicast routing protocol to establish and maintain the multicast routing table, to construct the Multicast distribution tree, ensuring that multicast packets can reach each member of the group. The multicast in mobile environments deal with not only dynamic group memberships (member joining or leaving multicast group), but also dynamic member locations. Each time a member’s location changes, the Multicast distribution tree may need to be reconstructed, resulting in uncircumvented overhead Multicast service on the Internet is currently supported for fixed hosts through IP Multicast. With the great progress of wireless networking coupled with the rapid growth of mobile communication, it is desired to extend multicast service to the mobile hosts. Multicast services, such as news, weather reports, travel information, live video, real-time streaming


49

content, and inclusive services in network centric operations, are popular for mobile users. Providing multicast service for mobile hosts in an IP internetwork is a challenging problem. The addition of mobility to the host group model of IP Multicast implies that multicast routing algorithm must deal with not only dynamic group membership, but also dynamic member location. Unfortunately, current widely used multicast routing protocols, such as PIM, DVMRP, and MOSPF, assume static hosts when building multicast distribution trees, without considering the dynamic member location. Reconstructing the distribution tree each time a member moves will involve pervasive overhead, yet leaving the tree unchanged can result in inefficiency, or possibly failure of multicast packet delivery MUL-2. On the other hand, the mechanisms in Mobile IP of mobility support are primarily for unicast communication, and the mechanisms to support mobile Multicast are not efficient enough for most applications. RELATED WORK A number of communities contribute to multicast developments and analysis. Such communities are the IETF, IEEE Computer Society, Communications Society, and Internet Society, ITU-T, Internet Research Task Force. Historically, the E2E Research Group (RG) has monitored and expedited the development of IP multicasting, VMTP, and congestion avoidance/control mechanisms. It also evolved the planning for DARTnet, the DARPA Research Testbed network. Other academic circles that feed research developments into the IEEE include extensions of IETF approach, including support protocol mechanisms such as Mobile Multicast (MoM) Protocol, Mobile Multicast with Routing Optimization (MMROP), Constraint Tree Migration Scheme (CTMS), and Multicast Scheme for Wireless Networks (MobiCast). INTERACTIONS Multicast will interact with most, if not all, of the other problem areas. It will have a larger number of interactions with other NCOIC WGs to help identify network-centric management and routing practices. Specifically, the Multicast problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas- interaction YES/NO: • Network Planning and Management-YES: Multicast and Network Planning and

Management will interact to evaluate different options for managing multicast routing and group membership over mobile and/or wireless networks in net-centric manner.

• Applications Interactions-YES: Multicast routing capabilities will be initiated through Applications Interactions problem area. Multicast and Applications Interactions will interact to evaluate solutions enabling applications to optimize multicast routing and group membership over mobile and/or wireless networks.


50

• QoS-YES: Multicast and QoS will interact to evaluate multicast (routing and group membership) solutions ability to support QoS.

• Information Assurance-YES: Multicast and Information Assurance will interact to evaluate options for securing multicast (routing and group membership).

• Transport Layer Protocol-YES: Multicast and Transport Layer Protocol will interact to evaluate transport layer protocols support for multicast sessions over wireless and/or mobile network.

• Network and Node Mobility-YES: Multicast and Network and Node Mobility will interact to evaluate multicast solutions for mobile nodes and networks. The solutions have to address both the maintenance of routing paths and group membership.

• Ad hoc Network-NO: Multicast (routing and group membership), to first order, is independent of network being Ad hoc (mostly self managed) vs. general network (more human-in-the-loop managed) operation.

• Routing-YES: Multicast routing capabilities will be initiated through Routing problem area. Multicast and Routing will interact to evaluate multicast routing solutions over mobile nodes and networks. Specifically, as other considerations are identified, Multicast should be recognized that the problem faced by routing is one of performance and scalability. Therefore, any other issue that also has performance and scalability issues has a potential interaction with routing in that they may be competing for the same limited resources.

• Physical and Data link Constraints-YES: Multicast and Physical and Data link

Constraints will interact to evaluate solutions optimizing routing using higher fidelity information from underlying link resources.

NCOIC WGs • BB-YES: Multicast will recommend standards to help Building Block evaluate products’

ability to support Ad hoc operations in net-centric enabling manner. • CR-YES: Multicast requirements will be driven by input from Mission Thread/Use Case

Analysis from Customer Requirements WG. • EP-YES: Multicast will provide terms to Engineering Process’ lexicon. The effort may

also motivate modeling and simulation. • IA-NO: Multicast security requirements will be addressed through MNE IA problem

area. • Lexicon-YES: Multicast evaluation will forward terms to Lexicon WG. • NCAT-YES: Multicast evaluation will interact with NCAT to develop interoperability

criteria for network and node mobility environments. • NIF-YES: Multicast evaluation will interact with NIF to develop NCO framework and

PFCs. • SII-YES: Multicast will use SCOPE model to help evaluate alternatives. CONCLUSIONS This problem area briefly identifies the issues associated with mobile multicast. It is believed that the provision of multicast services to mobile nodes is a challenging problem, and several


51

issues emerged with a large number of proposed solutions due to the problems introduced by the mobile handover MUL-3. Most of the proposed solutions attempt to enhance the support of multicast with either mobile receivers or mobile sources by combining the advantages of the home subscription and remote subscription approaches without providing a global architecture. These solutions seem not to be deployable in very large networks since they rely on newly introduced architectural agents/mechanisms for mobile multicast and they should satisfy the following: scalability, robustness, access technology independence, mobility transparency, mobility independence, compatibility, and security.

3.10 Physical and Data Link Layer Constraints

PROBLEM STATEMENT The Physical and Data Link Layer characteristics, needs, or limitations of cellular and Satcom wireless networks may affect the network layer performance, and even the performance of higher layers. Mobility especially is considered due to its dynamic nature and higher dependence on the physical layer. Arising physical issues are: • Link Closure (e.g. from a node’s perspective, “is there connectivity to another node?”). • Link quality (once there is a connection between nodes, what is the Bit Error Rate (BER)

and furthermore, what are the statistical characteristics of the errors?). • Link outages (blockage, going in and out of link closure range, falling in/out of beam

pattern or frequency range, etc.) that could range from milliseconds to seconds to minutes. • Link delays, jitter, and latency (how long it takes for a link connection to be established,

and once established, the resultant latency). Satellite links, for example, can have a significant latency thus affecting TCP throughput.

• Duty cycle (% time on, % time receive/transmit, half/full duplex, etc.). • Dynamic adjustments of link resources independently controlled at the physical link layer,

e.g. power control, bandwidth allocation and management, etc. that could impact the latency and BER of a link.

• Link Diversity (especially spatial diversity) that can support multiple network routes or paths.

• Overall efficiency (Information throughput or “Good put” to channel bandwidth ratio).

The physical layer issues outlined above can affect protocol performance, e.g. TCP/IP latency and TCP/IP over satellite bandwidth. These issues relate to or are driven by physical effects, or mitigation of physical effects, that communications engineers and technologists have been working with for decades in efforts to optimize link performance. Such physical effects include: • Power availability/amount/life (e.g. battery). • Antenna patterns (e.g. directivity nulls, etc.) and tracking needs, that are especially

important for Communications on the Move (COTM). • High dynamics, e.g. fast flying aircraft, LEO satellites, etc.


52

• Frequency usage restrictions (e.g. spectrum availability, internal or external interference, international or domestic regulations).

• Other operational needs that may introduce specialized requirements for the waveform. Often, physical and data link issues are characteristic of available, legacy radio technologies, or waveforms, (e.g. frequencies used, modulation, error correction coding, framing, messaging, etc.) that networks use or need for backward compatibility with existing networks. There is a plethora of legacy waveforms that will play a role in future, IP-based network mobility. Often users can not afford to discard old radios. However, new efforts in radio development specify waveforms that are much better suited for the future net-centric and mobile environment, and promise backward compatibility to existing waveform technologies. BACKGROUND The physical and data link layers exhibit behaviours that may affect the layers above due to their physical limitations, needs, regulations, or established practices. These properties generally fall into the following categories: Frequency spectrum and who owns it, how it is regulated, how it is managed/allocated, and its propagation properties; Waveform (usually encompassing both the physical and data link layers) design, including multiple access scheme, modulation, coding, and the associated performance and efficiency; Link diversity and the ability to connect, bridge, and route; Security properties, physical and electronic; and host platform physical dynamic properties, e.g. location, velocity, acceleration, Line of Sight (LOS) or Beyond Line of Sight (BLOS) capability, which includes Satcom, that influence connectivity and drive waveform performance for acquisition and lock. This section explores the physical and data link layer constraints and limitations and points to work generally done in the design of various waveforms to make node mobility possible and the use of TCP/IP more tractable. It also addresses waveform features and efficiencies, as well as cross-layer interactions that are necessary for mobility in net-centric systems. The physical and data link layers provide limitations and capabilities which layers above need to be aware for optimum system design. Mobility, especially, is dependent on what the physical layer can do because of its nature, i.e. nodes will be physically mobile thus causing network reconfiguration. Thus any selection of mobility protocols needs to be cognizant of physical and data link layer characteristics. RELATED WORK Some waveforms are better suited for IP than others, while others may be completely incapable of carrying IP. The cellular phone waveform standards, e.g. GSM, CDMA, W-CDMA and CDMA2000, as well as the 802.X series of radio standards are fully capable of supporting IP networking and mobility to various degrees. 802.11x (WiFi), originally designed for a LAN environment, is making its way to wider areas, e.g. airports and city sections (“hot zones”), thus supporting some form of mobility. The upcoming 802.16x (WiMax) is raising capability by fully


53

supporting a MAN environment and some mobility. And the future 802.20x is expected to fully support mobility, including platforms at high speeds. Commercial standards, however, make a distinction between "Access" and "Core" transmission links, which have different requirements and characteristics. So while 802.11x may be deployed in a way that affords wider coverage areas, it is still an Access technology. The upcoming new waveforms promise to provide higher performance, e.g. higher bandwidth for lower resource demands, but the fundamental issue of backward compatibility with legacy systems will persist for many years, until the new radio technologies completely take over and old radios are phased out. To help the phasing out of old with the introduction of the new, one of the most interesting technologies that is also being developed is “bridges” or “gateways” for bridging legacy to legacy waveforms, and legacy waveforms (that can carry IP) to new waveforms (capable of carrying IP). These bridges vary in complexity based on the “from-to” specifics, as various waveforms can operate in multiple IP Reference Model layers from physical all the way to application messaging. INTERACTIONS The Physical and Data link Constraints problem area has interactions with the following problem areas and NCOIC WGs:

Problem Areas- interaction YES/NO: • Network Planning and Management-YES: Physical and Data link Constraints and

Network Planning and Management will interact to evaluate network planning and management needs relating to physical and data link constraints.

• Applications Interactions-YES: Physical and Data link Constraints and Applications Interaction and will interact to evaluate solutions enabling applications to optimize physical and data link resource allocation through increased fidelity interactions.

• QoS-YES: Physical and Data link Constraints and QoS will interact to evaluate constraints physical and data link resources impose on QoS.

• IA-YES: Physical and Data link Layer Constraints and Information Assurance will interact to evaluate options for securing physical and data link resources.

• Transport Layer Protocol-YES: Transport Layer Protocol and Physical and Data link Constraints will interact to evaluate options for improving transport layer performance through interaction with physical and data link resources.

• Network and Node Mobility-YES: Physical and Data Link Constraints and Network and Node Mobility will interact to evaluate the options for improving support of network and node mobility scenario over physical and data link resources.

• Ad hoc Network-YES: Physical and Data link Constraints and Ad hoc Network will interact to evaluate solutions using interactions with Physical and Data link layer to improve Ad hoc networking operation.


54

• Routing—YES: Physical and Data link Constraints and Routing will interact to evaluate solutions optimizing routing using higher fidelity information from underlying link resources.

• Multicast-YES: Physical and Data link Constraints and Multicast (routing) will interact to evaluate solutions optimizing multicast routing using higher fidelity information from underlying link resources.

NCOIC WGs • BB-YES: Physical and Data link Constraints will recommend standards to help Building

Block evaluate products’ ability to support Ad hoc operations in net-centric enabling manner.

• CR-YES: Physical and Data link Constraints requirements will be driven by input from Mission Thread/Use Case Analysis from Customer Requirements WG.

• EP-YES: Physical and Data link Constraints will provide terms to Engineering Process’ lexicon. The effort may also motivate modeling and simulation.

• IA-NO: Physical and Data link Constraints security requirements will be evaluated through MNE IA problem area.

• Lexicon-YES: Physical and Data link Constraints evaluation will forward terms to Lexicon WG.

• NCAT-YES: Physical and Data link Constraints evaluation will interact with NCAT to develop interoperability criteria for network and node mobility environments.

• NIF-YES: Physical and Data link Constraints evaluation will interact with NIF to develop NCO framework and PFCs.

• SII-YES: Physical and Data link Constraints will use SCOPE model to help evaluate alternatives.

CONCLUSIONS Physical and data link layer characteristics, needs, or limitations due to power availability, antenna patterns, high dynamics and frequency usage restrictions may affect the network layer performance, and even the performance of higher layers. Mobility especially is considered due to its dynamic nature and higher dependence on the physical layer. Arising physical issues are link closure, link quality, link outages, link delays, duty cycle, dynamic resource management, link diversity and link efficiency. This section explores the physical and data link layer constraints and limitations and points to work generally done in the design of various waveforms to make node mobility possible and the use of TCP/IP more tractable. It also addresses waveform features and efficiencies, as well as cross-layer interactions that are necessary for mobility in net-centric systems.


55

4 MNE Concept

MOTIVATION This section documents the WG’s conceptual framework for evaluating ten (10) key mobility problem areas identified by the MNWG in this document for advancing NCO. The objective of this section is to initiate development of the MNE process common across all problem areas and to achieve consistent expectations regarding external interactions, content and presentation across all problem areas. This will assist the NCO customer interested in comparing the results of the MNE across problem areas and more importantly help ensure the larger success of NCOIC. The process provides a baseline for further discussion on how we, working a particular problem area, will identify and evaluate standards and PFCs important to Network Mobility. The feedback is expected to be used early during MNE to help MNWG collectively agree upon the final process. The process identifies the interactions with other WGs required to help NCOIC address the objectives identified in its vision: • Identify existing and emerging open standards • Identify global framework • Identify common set of principles and processes. These objectives help the consortium and its customers develop and field network-centric systems. It is important to develop and formalize the NCOIC processes for achieving these objectives. A common process that enforces a discipline in developing individual problem areas is especially important across highly distributed team efforts like MNWG. Figure 4- 1 captures the baseline approach for MNE including identification of potential interactions and “products”. The nature of the “products” will be defined during final MNE development, planning and scheduling. PROCESS The proposed process applies to each MNWG problem area. Each problem area (QoS, routing, etc) conducts its own pass through the process. First at the top level the MNE is organized into three main evaluation areas: • Technical Area • Net-centric Area • Standards Development Area


56

Phase 3 – Develop Net -Centricity Filter and

Evaluate Net -Centricity

Phase 4 – Develop End Products

Phase 5 – Motivate New /Enhanced Standards

Phase 1 – Develop Mobility Functional

Requirements and Domains

Phase 2 – Develop Mobility Functional Model (s),

Technology and Standards Survey , and Mapping

MNE – Problem Areas

Use cases

Driving Requirements

Operating Regions

Standards to Mobility

Functional Decomposition

Mapping

Standards of Interest

FilterMetric/

Criteria

Net-Centric

Checklist

NCAT

WG

SII WG

IA WG

New

Requirement

?

NCOIC Mobility Functional

Decomposition

Building

CodePFCs

Next

StepsFramework Ontology

EP WG NIF WG SII WG

Gap Identification

Gap Justification

External

Forum

?

External

Development

Internal

Development

Standard

(New or

Enhanced )

CR WG

SII WG

Map

?

Y N

Y N

N

Y

IA WG

BB WG

Fails Net -

Centricity

CompliantNon-

CompliantConditionalA

Mobility Functional

Decomposition (s)

Technology and Standards

Survey

A

Lessons Learnt

In Phase 3

Lessons Learnt

In Phase 2

Lessons Learnt

In Phase 1

A

Standards Development AreaNet-Centric Area

Technical Area

NIF WG

Figure 4- 1 MNE Process

Broadly speaking, Technical Area is responsible for evaluating requirements and constructing the standards-space to be worked by MNE. Net-centric Area is responsible for evaluating net-centric qualities of identified standards and Standards Development Area is responsible for evaluating the best way to develop new standards or enhance existing standards to address requirements that cannot be addressed with identified standard(s). The Technical Area is processed with minimal or no net-centricity constraint. It includes phases 1 (Develop Mobility Functional Requirements & Domains) and 2 (Develop Mobility


57

Functional Model(s), Technology and Standard Survey, and Mapping). Phases 1 and 2 together complete the scoping of the problem area initiated during the MNO development. They, respectively, identify the driving requirements and construct the resulting alternative solution/standard-spaces to be addressed by the MNE. The outputs of phase 1 are the Driving Requirements. First the problem area team will identify the driving requirements imposed on the problem area based on review of the problem statement, use cases and the operating regions. The CRWG is expected to provide the latter two inputs. The expectation is that the SII WG's SCOPE model will be used to initiate the process for bounding the problem. The problem area team will then complete this task and feed the improvements back into the SCOPE model. IA WG is expected to provide a general security framework for problem areas. Lessons learned should be captured for later use. Phase 2 is responsible for identifying the alternative Mobility Functional Model(s) that have been proposed by related forums for addressing the above problem and requirements. This is followed by Technology and Standard Survey and Mapping identifying and trading candidate standards for addressing the functions within the Mobility Functional Model(s). The survey will include alternative solutions from technologies, open standards and other industry consortia forums affecting NCO including IETF, ITU, IEEE, WiMAX, 3GPP, 3GPP2, IPv6 Forum, ATIS, etc. The standards/technologies are then mapped to the functions. The mappings will be captured within a Standards-Functional Model Map. Functions with standards addressing them are designated as "mapped". Functions with no standards/technologies addressing them are designated as "gaps". This basically captures the standards-space to be addressed by MNE. The standards need to be categorized in terms of maturity to begin documenting the expected time frame of support by the consortium. The classification options include standard vs. draft standard vs. proposed standard and/or current vs. emerging vs. retiring. The details will be worked out during final MNE development and planning. The standards identified by MNE process for consortium support over particular time frames is expected to return substantial dividend to vendors, integrators and customers by helping them make better informed choices. Finally a number of important potential customers including North American Treaty Organization (NATO) and Defense Information Systems Agency (DISA) have implemented similar classification schemes. The above products of phase 2 will be coordinated with the framework captured by the NIF. Updates will be fed back into the NIF. This phase will develop basic trade criteria which are specific to addressing the technological problem area at hand, i.e., not related to general net-centric qualities or enablers. The general results of phase 2 will be captured as Functional Key Tenets, Patterns & Assumptions. Lessons learned are captured for later use. At the output of phase 2 the MNE Workflow process has a branch leaving the Technical Area. The unmapped functions trigger the Standard Development Area. The standards mapping into a function trigger the Net-Centric Area responsible for evaluating the net-centric quality of the


58

standards. For the Network-Centric (Evaluation) Area the problem area task group will develop an evaluation filter relevant to the particular problem area at hand using applicable inputs from the Net-Centric Checklist, SCOPE, NCAT, IAWG and related work from other problem areas. The filter elements should be traceable to the high level IPRM-based network tenets such as: • Connectivity • Interoperability • Manageable, identifiable, and discoverable • Security • End-to-end Currently it is not clear if this filter is specific to a problem area or general across multiple or all. The updates/improvements captured within the filter are fed back into applicable NCOIC products (NIF, NCAT, etc). Upon completion of the filter, the standards are processed through the filter for compliance and results organized between three categories: • Compliant • Conditional • Not Compliant Compliant means the standard adequately addresses the filter. Conditional means the standard would support the filter with identified change recommendations that don't impact the foundation of the standard. Not Compliant means some fundamental aspect(s) of the standard fails the filter and the standard can’t be modified to achieve a particular necessary net-centric quality. The evaluation process in Phase 3 may generate new requirement(s) missed during Phase 1. Any new requirements are fed back into the Mobility Functional Model(s). General lessons learned, i.e., pertinent to standard development for given function, are captured as Net-Centric Key Tenets, Patterns & Assumptions. This is expected to help in the development of new standards. Phase 4 (Development End Products) is responsible for taking these results and developing the NCOIC Mobility Model for the given problem area at hand. This is the Network-Centric subset of the Standards-Functional Model Map developed during phase 2. Phase 4 is also responsible for packaging the conclusions in the relevant NCOIC products including the Building Code, PFCs, NIF, and SII Ontology products. The Gaps (or unmapped functions from Phase 2) on the other hand trigger the activation of Phase 5, New/Enhanced Standard Development Area. The first activity in the phase documents the gap and then explores external forums for developing a new/enhanced standard to satisfy the Net-Centricity needs. If a forum is identified they are encouraged to develop the necessary standard(s). MNWG will propose NCOIC internal development if no appropriate standards forum is found to take on the task. After development the standard is fed back into


59

Standards-Functional Model Map (phase 2). This phase may also be triggered to follow-up on a standard identified in phase 3 as conditionally compliant. STRATEGY The MNE strategy is to (1) solicit appropriate expertise for each problem area and (2) orchestrate the interaction between MNE with the NCOIC vision and resultant process and products, e.g., NIF, NCAT, etc. and (3) develop an effective process. This is uncharted territory for a complex endeavour. This MNE framework will be used as a guideline to develop the level of detail required to allow the WG to proceed with the first iteration of the MNE. A successful MNE process maintains an optimum balance between enabling locally speedy problem-specific process and larger emergent discipline, consistency and integration across problem areas. A one-size process will not fit all perfectly. It is expected that not all elements of the process will be applicable to all problem areas. The MNE described herein is a living process and is expected to be revisited for “fine tuning” using experience obtained during or after first iteration. The interactions between MNE and the larger process must be loosely coupled due to the complexity of the mission and diverse maturity levels across NCOIC developments. Within reason, one NCOIC activity should not slow others down. When there are mature inputs, say from CRWG, affecting a MNE activity it should be incorporated, however, they should not significantly impact MNE product delivery schedule. It will be up to the discretion of specific problem area teams whether their schedule should be gated by results from other problem areas or WGs or not. The CRWG is expected to provide the motivating and problem constraining use cases and requirements. These inputs should be delivered up front to help orchestrate the first iteration of the MNE. If the inputs from CRWG impact a particular MNO problem area, then the MNE team responsible for the problem area will develop (multiple) functional model(s) potentially satisfying multiple classes of usage. If no relevant inputs are received from CRWG the MNE team will use their best judgement to develop the necessary functional model(s), tenets and assumptions. The top-down input will increase the probability that the MNE work has maximum effectiveness and consistency between problem areas, i.e., they are resolving similar classes of use cases. In the absence of these inputs MNE must proceed using bottoms up experience. The practitioner of MNE is expected to take advantage of both top-down and bottoms-up viewpoints to successfully complete their work. The exact balance will probably be dependent on the problem area and the nature of the input provided from CRWG. The participants experience with the "bottom/network plumbing" technology will help them effectively filter the irrelevant high-level motivating requirements and vice versa. Finally a MNWG focal will be identified responsible for each interaction identified within the MNE process. Only one MNWG participant has to be intimately familiar with each external


60

product interacting with MNE to maximize the use limited SME resources available in the MNWG. This approach does require interaction focal to have comprehensive understanding of the other MNE problem areas. Again the steps in the workflow provided herein are only to be used as guidelines. Problem area investigators are expected to make reasonable effort to address each task during their investigation. If they decide that they cannot use a particular step for their problem area they should document the rationale why they had to pass in lessons-learned. This input will be used to help fine tune the MNE framework during next design iteration for addressing the next series of problem areas as the current ones are resolved. CONCLUSIONS: This proposed process provides guidelines and directions to MNWG for development of the MNE. This ensures that MNWG’s multiple teams will proceed with similar bearing with respect to NCOIC mission as they develop products for their particular problem areas. The process is expected to be finalized during the early stage of the MNE to include agreement on the task flow and the specific nature of the deliverables. Further process improvement is expected over time as the WG gains experience executing the MNE.


61

5 Conclusion

The MNO initiated the identification of open standards for enabling network mobility that meet the net-centricity criteria within the overall NCOIC concept. This product enables collaborative feedback between our customers and industry. This document emphasizes a network-centric environment where all classes of information systems interoperate by integrating existing and emerging open standards into a common evolving global framework employing a common set of principles and processes. The MNO problem areas focused on the communication layers. The interactions between these layers and lower layers (i.e. Physical and Data link layers) and higher layers (i.e. user applications) have also been included. This activity excluded the components within the applications and physical layers other than to appreciate the external interfaces they might extend to the two layers of focus. MNWG settled on 10 pressing problem areas that need to be addressed to help NCO systems achieve interoperability amongst, per NCOIC mission statement, all levels of governments involved in Joint, Interagency and Multinational operations. An overview of the scope of each problem area was provided to bind the ensuing MNE effort. The MNE Concept section documented the common process framework developed to impose common guidelines over all problem areas to enforce optimum coordination and discipline across them. It also begins to identify the external interactions to the greater NCOIC WGs to maximize support of the broader NCOIC mission, while minimizing the negative impact on the MNE delivery schedule. The MNWG hopes that the larger community will now seize the opportunity to provide feedback to help ensure the success of the MNWG mission. The MNWG learned a number of lessons while developing the MNO document. First the WG made the distinction between mobility and RF link issues to bind the problem. The latter relates to issues that apply to RF links connecting nodes independent of whether nodes are mobile or fixed (data loss due to RF characteristics, header compression, etc). Mobility relates to those issues specific to mobile environments beyond RF link characteristics (e.g. handoff, dynamic topology and murky domain). The MNWG also made a distinction between ad hoc networking and MANET. The former relates to larger impromptu network formation that may involve both fixed and mobile nodes. MANET is an ad hoc network that includes only mobile nodes. Ad hoc networking including MANET warrant a standalone problem area while MANET’s routing element is incorporated as an alternative solution to be investigated under the routing problem area. The final realization is that management and Ad hoc networking are not mutually exclusive. Nodes can


62

form networks in Ad hoc fashion and also be planned and managed, generally, prior to deployment. The MNO document lays the groundwork for an effective follow-on MNE activity. This deliverable experience taught the WG the importance of discipline and coordination of dividing, conquering and provisioning across distributed collaborative workforce such as MNWG. This necessitates the use of an online environment allowing SMEs to work in an asynchronous manner while collaborating on various challenges.


63

6 Appendix

6.1 Appendix A: Acronyms

This section defines acronyms used in this document. Acronym Definition 3GPP 3rd Generation Partnership Project 3GPP2 3rd Generation Partnership Project 2 AAA Authorization, Authentication, and Accounting AFCEA Armed Forces Communications & Electronics Association AFEI Association For Enterprise Integration AHN Ad Hoc Networks AI Application Interactions AIAA American Institute of Aeronautics and Astronautics AODV Ad hoc On demand Distance Vector ARSVP Aggregate RSVP ASA Architecture and Standards Analysis ATIS Alliance for Telecommunications Industry Solutions BGP Border Gateway Protocol BLOS Beyond LOS C2 Command and Control CAD Computer Aided Dispatch, Computer Aided Design CBT Computer Based Training CES Core Enterprise Services CHD Complex Humanitarian Disaster CMIP Common Management Information Protocol CMIS Common Management Information Service CONOPS CONcept of OPerationS COOP Continuity Of Operations Plan COTM Communications On The Move CRWG Customer Requirements WG CTMS Constraint Tree Migration Scheme DARPA Defence Advanced Research Project Agency DCCP Datagram Congestion Control Protocol DCGS Distributed Common Ground Systems DHS Department of Homeland Security DiffServ Differentiated Services DISR DoD IT Standards Registry


64

Acronym Definition DMTF Distributed Management Task Force DoD Department of Defence DVMRP Distance Vector Multicast Routing Protocol E2E End-to-End EKG ElectroKardioGram EMS Emergency Medical Services, Emergency Management System EPLRS Enhanced Position Location and Reporting System ER Emergency Room ETSI European Telecommunications Standards Institute FCAPS Fault, Configuration, Accounting, Performance, & Security FCFS First Come First Serve FMIPv6 Fast Handovers for Mobile IP version 6 GA Global Attribute GIG Global Information Grid HETNET Heterogeneous Network HMIPv6 Hierarchical Mobile IP version 6 IA Information Assurance IAS Information Assurance and Security IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IETF Internet Engineering Task Force IGMP Internet Group Management Protocol iLBC Internet Low Bitrate Codec IntServ Integrated Services IP Internet Protocol IPRM IP Reference Model IPv6 Internet Protocol version 6 ISO International Organization for Standardization ITU International Telecommunications Union ITU-T ITU-Telecommunications JBMC2 Joint Battle Management Command and Control JC2 Joint Command and Control JTRS Joint Tactical Radio System LAN Local Area Network LEO Low Earth Orbiting LMM Localized Mobility Management LOS Line of Sight MALSR Multi-level Abstract Link State Routing MAN Metropolitan Area Network MANET Mobile Ad hoc NETwork MIPv4 Mobile Internet Protocol version 4 MIPv6 Mobile Internet Protocol version 6 MMROP Mobile Multicast with Routing Optimization


65

Acronym Definition MNE Mobile Networking Evaluation MNO Mobile Networking Overview MNWG Mobile Networking Working Group MoM Mobile Multicast MONET Mobile Network MOSPF Multicast Open Shortest Path First MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching NATO North Atlantic Treaty Organization NCAT NCO Analysis Tool NCES Network Centric Enterprise Services NCO Network Centric Operations or Net-Centric Operations NCOIC Network Centric Operations Industry Consortium NCOIF Network Centric Operations Industry Forum NCOW-RM Net-Centric Operations - Warfare Reference Model NDIA National Defence Industrial Association NEC Network-Enabled Capability NEMO NEtwork MObility NIF Netcentric Interoperability Framework NNM Network and Node Mobility NPM Network Planning and Management NSIS Next Steps In Signalling ODMRP On-Demand Multicast Routing Protocol OLSR Optimized Link State Routing OMG Object Management Group OSI Open System Interconnection OSPF Open Shortest Path First PC Program Committee PDA Personal Digital Assistant PFC Protocol Functional Collection PIM Protocol Independent Multicast PIM-DM PIM-Dense Mode PIM-SM PIM-Sparse Mode PSAP Public Safety Answering Point QoS Quality of Service RFC Request for Comments RIP Routing Information Protocol RSVP Resource ReSerVation Protocol RTP Real Time Protocol SA Security Association SCA Software Communications Architecture SCOPE Systems, Capabilities, Operations, Programs, and Enterprises SCTP Stream Control Transmission Protocol


66

Acronym Definition SII Services Information Interoperability SINCGARS Single Channel Ground to Air Radio System SMF Simplified Multicast Forwarding SMURF Simplified MANET Multicast Routing / Forwarding SNMP Simple Network Management Protocol SOA Service Oriented Architecture SoR Statement of Requirements TBRPF Topology Broadcast based on Reverse Path Forwarding TCP Transmission Control Protocol TLP Transport Layer Protocols TM Telecommunications Management TMN Telecommunications Management Network TMR Transmission Media Requirements TSG Technical Specifications Group TTL Time to Live UDP User Datagram Protocol VMTP Versatile Message Transaction Protocol VPN Virtual Private Network W2COG World-Wide Consortium for the Grid WG Working Group WiMAX Worldwide Interoperability for Microwave Access, Inc. (group

promoting IEEE 802.16 wireless broadband standard) WLAN Wireless Local Area Network, Wave Local Area Network WNW Wideband Network Waveform

6.2 Appendix B: Glossary

This section defines terms used in this document. Standard definitions, where available, were used.

Term Definition Ad hoc network A self organizing network that is formed without external support, in

which the devices are a part of the network for a temporary period, and there is no assumed infrastructure

Authentication It is a security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information.

Availability (of information)

Timely and reliable access to information

Bandwidth The total width of the frequency band available to or used by a communications channel. Usually measured in Hertz (Hz). The


67

Term Definition bandwidth of a channel limits the available channel capacity.

Bandwidth utilization

The actual rate of information transfer achieved over a link, expressed as a percentage of the theoretical maximum channel capacity on that link, according to Shannon’s Law.

Communications Layers

Layers 1-4 of the Internet Reference Model. This includes the Physical Layer, Data Link Layer, Network Layer, and the Transport Layer

Confidentiality (of information)

The property that information possesses when it is only made available to, or shared with, authorized individuals, processes, or devices

Congestion management

Methods by which a network manages situations where there is more traffic than can be handled by available network resources

Control plane Provides for signaling and set-up functions for the system. Example functions include call set-up, call termination.

Core Major arterial networks carrying high volumes of traffic. A core network typically interconnects multiple lower-speed networks together. This usually involves very high-speed connections and geographically long links. (Reference Cisco Routing Glossary)

Core routing Forwarding of packets through the core, which is a network or group of networks that provide transit services. See Core

Datagram A packet which contains enough information in the header to allow the network to forward it to the destination independently of previous or future datagrams

Domain 1) A set of network resources for a group of users; 2) a sphere of knowledge; 3) a set of network addresses; 4) network(s) under the control of a single administrative authority. (Ref. WhatIs.com)

Edge Network An edge network is where users are directly connected and their data aggregated into the network core. This is where user-specific services and policies are enabled such as quality of service. (Reference Cisco Routing Glossary)

Edge routing Forwarding of packets through an edge network, i.e. from a border router to the nodes within a local network

End-to-end From the source host to the destination host Enterprise Mobility:

Enterprise mobility includes mobile computing platforms which have the capabilities for real time distributed transaction processing applications throughout an enterprise. These computing platforms can consist of: application software, mobile computing devices, Wireless and wired connectivity solutions and infrastructures. The enterprise could be a corporation, retail chain, transport company, hospital, distribution facility, etc. The transactions that are processed by the enterprise can be the purchase of an airliner down to a candy bar at the local convenience store. With mobile networks becoming more prevalent there is a strong shift from “stand alone” data repositories to more tightly integrated data repository at the enterprise level.


68

Term Definition MobiCast Multicast Scheme for Wireless Networks First responders Those emergency workers who are first on the scene after a natural or

man-made disaster or emergency situation has occurred Fixed infrastructure

Interconnected fundamental structural elements of a network that are not capable of mobility which provide the framework for transporting information

Global Mobility: Global mobility includes the movement of nodes or an entire network from one Internet IP address space to another IP address space while maintaining connectivity to nodes with which it is communicating.

Heterogeneous Network

A collection of nodes of different manufacturer’s products or technologies that can exchange data

Information Assurance

All aspects of safeguarding and protecting information, networks, and data

Integrity (of information)

The property that information possesses when it is current, accurate, and complete (e.g., is not accidentally or maliciously modified or destroyed)

Inter-domain Between domains Intra-domain Within a domain IP Reference Model

It generically references the TCP/IP Protocol suite and the Internet Architecture reference for the communications layers is documented in RFC 1122 Requirements for Internet Hosts -- Communication Layers in Section 1.1.3 Internet Protocol Suite ftp://ftp.rfc-editor.org/in-notes/rfc1122.txt . The Applications Layer is documented essentially in RFC 1123 Requirements for Internet Hosts -- Application and Support ftp://ftp.rfc-editor.org/in-notes/rfc1123.txt. The layers are a virtual abstraction to provide a form to discuss protocol placement within the Internet Architecture for IETF standards and implementations. The IPRM Layers are as follows top to bottom:

• Application Layer • Transport Layer • Internet Protocol Layer • Link Layer • Physical Layer

Local Mobility: Local mobility references the movement of nodes within a local area network or within a mobile Ad hoc network and the peer-2-peer topology changes for node-to-node communications within that local network. Local Mobility can impact layers 1-5 and applications and these impacts must be part of the analysis for Local Mobility operations.

Management plane

Performs management functions for the system, and also coordinates the other planes (data, control, services). The following are example


69

Term Definition workflows for the MP: login/logout, configure network elements, generate billing details. (Ref. “Security and the Management Plane Part 2”, Stephen Davis)

Mesh Network A network where all the nodes can connect to each other. This rich connectivity allows inexpensive peer network nodes to supply back haul services to other nodes in the same network. It effectively extends a network by sharing access to higher cost network infrastructure. Mesh networks are self-healing: the network can still operate even when a node breaks down or a connection goes bad. As a result, a very reliable network is formed. This concept is applicable to wireless networks, wired networks, and software interaction. (Ref. Wikipedia)

Mobile Ad hoc Network (MANET)

Self-configuring network of mobile nodes connected by wireless links, not dependent on any infrastructure, that form an arbitrary, changing, and unpredictable topology.

Mobile Network An entire network, moving as a unit, which dynamically changes its point of attachment to a serving network, and thus its reachability in the topology. A mobile network may be composed of fixed and/or mobile nodes

Mobile Node A simple or complex device whose location and point of attachment to the network may change

Mobility: A quality or capability of nodes, which permits them to move from place to place while retaining the ability to fulfil their primary mission. Users must be continuously connected to the network while on the move, in any terrain, throughout the three dimensions of space, in all environmental conditions, and through all phases of the operational continuum. The network will seamlessly maintain connectivity during “hand-off” from one layer to another, utilizing the most efficient communications path while on the move.

Multicast Communication between a single sender and multiple receivers on a network (Reference WhatIs.com)

Murky Fluid, indistinct Network A group of computing devices connected together to share

information or resources. Network centric Capability of a node, system, component to easily and seamlessly

connect with other nodes, systems, components to share information leading to increased situational awareness and easier accomplishment of individual and group goals

Network Infrastructure

The physical hardware used to interconnect computers and users. This includes transmission media, such as telephone lines, cable television lines, satellites and antennas, and also the routers, aggregators, repeaters, and other devices that control transmission paths. Infrastructure also includes the software used to send, receive, and manage the signals that are transmitted (Ref WhatIs.com)


70

Term Definition Network Planning and Management

Execution of the set of functions required for controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a network. This includes such functions as initial network planning, frequency allocation, cryptographic key distribution, configuration management, fault management, security management, accounting management, performance management. A large number of protocols exist to support network and network device management. Common protocols include SNMP and NETCONF. (Ref Wikipedia)

Node A device that is connected to a computer network. Examples of nodes include personal computers, cell phones, personal digital assistants, routers. (Ref Wikipedia)

Non-repudiation It is an assurance the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data.

Packet Fundamental unit of information organized in a standard way with a header followed by the data

Policy based management

An administrative approach that is used to simplify the management of a network by establishing operating rules (i.e. policies) to deal with situations that are likely to occur. These operating rules can be used to control access to and priorities for the use of network resources (Ref. WhatIs.com)

Provisioning Set up, allocation, and configuration of hardware, software, and services in order to provide capability to customers

Quality of Service

Characteristics such as bandwidth, latency, and jitter that describe a network's ability to customize the treatment of specific classes of data. For example, QoS can be used to prioritize video transmissions over Web-browsing traffic. Advanced networks can offer greater control over how data traffic is classified into classes and greater flexibility as to how the treatment of that traffic is differentiated from other traffic. (Reference WhatIS.com)

Routing Selecting of paths in a computer network along which to send data. Routing directs forwarding, the passing of logically addressed packets from their source toward their destination through intermediary nodes, i.e. routers. (Ref Wikipedia)

Scalability The ability of a network to operate properly with an arbitrarily large number of participants.

Service classes A way of managing traffic in a network by grouping similar types of traffic (for example, e-mail, streaming video, voice, large document file transfer) together and treating each type as a class with its own level of service priority

Service oriented architecture

A methodology and framework for documenting enterprise capabilities. SOAs comprise loosely coupled, highly interoperable application services. These services interoperate based on a formal definition independent of the underlying platform and programming


71

Term Definition language. (Ref. Wikipedia)

Topology The notion of an internetwork’s physical structure, e.g. who is connected to whom.

Transport Movement of data through one or more networks Use case A technique for capturing requirements. Each use case provides one

or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal. Use cases are typically in the language of the end user. (Ref. Wikipedia)

Wireless Network

A collection of nodes connected through wireless (RF) links

6.3 Appendix C: Contributors

The following have contributed to the development and production of this document. Allen Jones – The Boeing Company Bill Carmichael – Rockwell Collins Bonnie Gorsic - The Boeing Company Dimitrios Hatzipapafotiou – Lockheed-Martin Diwakar (Dick) Gan - The Boeing Company Francois-Xavier Lebas – Thales James Holden- CACI International, Inc. Jim Bound – Hewlett-Packard Jonathan Nicholas - ITT Industries Marty Egan - Lockheed-Martin Paul Schweitzer - Lockheed-Martin Roy Blackwell – Datapath Torsten Griem - The Boeing Company


72

6.4 Appendix D: References

The references in this document listed below use a convention as follows. A section referencing those uses a three letter abbreviation, such as NNM for Network and Node Mobility, appropriate for the section. References in that section are then incrementally referred to as NNM-1, NNM-2, etc. Forward Table 6-1 lists the references for the Forward section.

Table 6-1. Forward References

Document ID

Document Information

FRD-1 http://www.ncoic.org/about/mission_vision/ FRD-2 http://www.defenselink.mil/nii/org/cio/doc/NetCentric_Checklist_v2-1-

3_May12.doc General Use Cases Table 6-2 lists the references for the General Use Cases section.

Table 6-2. General Use Cases References

Document ID


GUC-1 U.S. Armed Services NCO Initiatives: ForceNet, C2 Constellation Net, LandwarNet, DCGS, JBMC2, and JC2; International NCO Initiatives: NATO NEC; Enterprise Initiatives: GIG Architecture, NCOW-RM and NCES, and DoD Chat and Collaboration Standards.

GUC-2 Statement of Requirements (SoR) for Public Safety Wireless Communications and Interoperability, The Safecom Program, Department of Homeland Security, March 10, 2004. [http://www.safecomprogram.gov/SAFECOM/library/technology/1200_statementof.htm].

Network Planning and Management Table 6-3 lists the references for the Network Planning and management.

Table 6-3. Network Planning and Management References


73

Document ID


NPM-1 STD0062 – RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks; D. Harrington, R. Presuhn, B. Wijnen; Dec 02

NPM-2 STD0015 – RFC 1157 - Simple Network Management Protocol (SNMP); J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin; May 90

Applications Interactions Table 6-4 lists the references for the General Use Cases section.

Table 6-4. Applications Interaction References

Document ID


AI-1 Port Numbers for Well Known Ports, Registered Ports, and Dynamic and/or Private Ports (Aka. Socket Numbers) Assigned by IANA; Aug 06

AI-2 Cross-Layer Protocol Engineering for Wireless Mobile Networks – Part 2; IEEE Communications Magazine; Jan 06

AI-3 Cross-layer Feedback Architecture for Mobile Device Protocol Stacks; IEEE Communications Magazine; Jan 06

AI-4 Application-Driven Cross-Layer Optimization for Video Streaming over Wireless Networks; IEEE Communications Magazine; Jan 06

AI-5 Toward an Improvement of H.264 Video Transmission over IEEE 802.11e through a Cross-Layer Architecture; IEEE Communications Magazine; Jan 06

AI-6 A Cautionary Perspective on Cross-Layer Design; IEEE Wireless Communications Magazine; Feb 05

Quality of Service Table 6-5 lists the references for the QoS problem area.

Table 6-5. QoS References

Document ID


QOS-1 RFC 1633 - Integrated Services in the Internet Architecture – An Overview; R. Braden, D. Clark, S. Shenker; June 99

QOS-2 RFC 2205 - Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification; R. Braden, L Zhang, S Berson, S. Herzog, S Jamin; Sept 97


74

Document ID


QOS-3 RFC 2475 - An Architecture for Differentiated Services; S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss; Dec 98

QOS-4 RFC 3031 - Multiprotocol Label Switching Architecture; E. Rosen, A. Viswanathan, R. Callon; Jan 01

QOS-5 RFC 3175 - Aggregation of RSVP for IPv4 and IPv6 Reservations; F. Baker, C. Iturralde, F. Le Faucheur, B. Davie ; Sept 01

QOS-6 RFC 4080 - Next Steps in Signalling (NSIS): Framework; R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch; June 05

Information Assurance Table 6-6 lists the references for the Information Assurance problem area.

Table 6-6. Information Assurance References

Document ID


IAS-1 National Information Assurance (IA) Glossary; Committee on National Security Systems (CNSS) Instruction No. 4009; May 03

IAS-2 RFC 4301; Security Architecture for the Internet Protocol; Dec 05

IAS-3 RFC 4302; IP Authentication Header; Dec 05

IAS-4 RFC 4303; IP Encapsulating Security Payload (ESP); Dec 05

IAS-5 RFC 4306; The Internet Key Exchange (IKEv2) Protocol; Dec 05

IAS-6 Secure Space Networking, Third Space Internet Workshop; Jun 03

IAS-7 Internet Protocol Header Compression, Robust Header Compression, and Their Applicability in the Global Information Grid; Nov 04

IAS-8 draft-ietf-msec-gsakmp-sec-10.txt – GSAKMP: Group Secure Association Group Management Protocol; May 05

IAS-9 draft-ietf-radext-rfc2486bis-06.txt – The Network Access Identifier; July 05

IAS-10 draft-ietf-rpsec-ospf-vuln-01.txt – OSPF Security Vulnerabilities Analysis; Dec 04

IAS-11 draft-ietf-pki4ipsec-ikecert-profile-07.txt – The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX; Nov 05


75

IAS-12 draft-ietf-pana-pana-10.txt – Protocol for Carrying Authentication for Network Access (PANA); Jul 05

IAS-13 draft-ietf-rpsec-generic-requirements-01.txt – Generic Security Requirements for Routing Protocols; Jan 05

Transport Layer Protocols Table 6-7 lists the references for the Transport Layer problem area.

Table 6-7. Transport Layer Protocols References

Document ID


TLP-1 TCP- http://tools.ietf.org/html/793

TLP-2 UDP- http://tools.ietf.org/html/768

TLP-3 RTP- http://tools.ietf.org/html/1889

TLP-4 DCCP- http://tools.ietf.org/html/4340

TLP-5 SCTP- http://tools.ietf.org/html/2960

TLP-6 TSVWG- http://www.ietf.org/html.charters/tsvwg-charter.html

TLP-7 TCPM- http://www.ietf.org/html.charters/tcpm-charter.html

Network and Node Mobility Table 6-8 lists the references for the Network and Node Mobility problem area.

Table 6-8. Network and Node Mobility references

Document ID


NNM-1 Ernst, T. and Lach, H-Y, “ Network Mobility Support Terminology”, http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-04.txt, October 24, 2005

NNM-2 Devarapalli, V., Wakikawa, R., Petrescu, A., and Thubert, P., “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, January 2005.

NNM-3 Bhagavathula, R., Thanthry N., Lee, W., and Pendse, Dr. R., “Mobility: A VPN Perspective”, IEEE 0-7803-7523-8/02, 2002.

NNM-4 Ernst, T., “Network Mobility Support in IPv6”, http://www.sfc.wide.ad.jp/~ernst/doc/20050627-ITST-eBicycle-TErnst-slides.pdf, June 2005.

NNM-5 Ernst, T., “Network Mobility Support Goals and Requirements”, http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt, October


76

24, 2005. NNM-6 Kempf, J. et al, “Problem Statement for IP Local Mobility”,

http://www.ietf.org/internet-drafts/draft-ietf-netlmm-nohost-ps-00.txt, February 2006.

NNM-7 Baba, S., “Mobility Management in a SIP Environment - Requirements, Functions, and Issues”, http://www3.ietf.org/proceedings/00mar/slides/sip-mobility-00mar.pdf, March 2000.

NNM-8 Sun, J and Suavola, J., “Mobility and Mobility Management – A Conceptual Framework”, presented at Networks 2002 ICON 2002, August 2002.

NNM-9 Akyildiz, I. et al, “A Survey Of Mobility Management In Next-Generation All-IP-Based Wireless Systems”, IEEE Wireless Communications, August 2004

NNM-10 E. Hepworth et al, “Media Independent Handover Signaling”, draft-hepworth-mipshop-mih-problem-statement-01, February 25, 2006.

Ad hoc Networks Table 6-9 lists the references for the Ad hoc Networks problem area.

Table 6-9. Ad hoc Networks References

Document ID


AHN-1 RFC 2501, Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations; Jan 99

AHN-2 RFC 3561, Ad hoc On-Demand Distance Vector(AODV) Routing; Jul 2003

AHN-3 RFC 3626, Optimized Link State Routing Protocol (OLSR); Oct 2003

AHN-4 RFC 3684, Topology Dissemination Based on Reverse-Path Forwarding (TBRPF); Feb 2004

AHN-5 IETF Draft – The dynamic Source Routing (DSR) Protocol; Jul 04

AHN-6 IEEE 802.11a/b/g, IEEE Wireless MAN/LAN standards for 2.4 GHz (a) or 5 GHz (b/g) band – best known as Wi-Fi standards; 1999

AHN-7 IEEE 802.16e, IEEE Broadband Wireless MAN/LAN standard - best known as Mobile WiMAX); 2005

Routing Table 6-10 lists the references for the Routing problem area.

Table 6-10. Routing References


77

Document ID


ROU-1 M. Chandra, "Extensions to OSPF to Support Mobile Ad Hoc Networking", draft-chandra-ospf-manet-ext-03.txt (work in progress), April 2005.

ROU-2 G. Malkin, "RIP Version 2", RFC 2453, November 1998

ROU-3 J. Moy, "OSPF Version 2", RFC 2328, April 1998

ROU-4 Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006

ROU-5 E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001

ROU-6 C. Perkins, E. Belding-Royer, E. Das, "Ad hoc On-Demand Distance Vector(AODV) Routing", RFC 3561, July 2003

ROU-7 T. Clausen, T. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003

ROU-8 R. Ogier, F. Templin, M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004

Multicast Table 6-11 lists the references for the Multicast problem area.

Table 6-11. Multicast References

Document ID


MUL-1 Romdhani, I., Kellil, M., Lach, H.Y., “IP Mobile Multicast: Challenges and Solutions”, IEEE Communications Surveys Vol. 6, No.1 2004.

MUL-2 Obraczka, K., Tsudik, G., “Multicast Routing Issues in Ad Hoc Networks”, In Proc. of IEEE ICUPC, Oct. 1998.

MUL-3 Zheng, J., Huang, K., Wu, Y., Wu, Z., “Mobility Pattern Based Adaptive Mobile Multicast Algorithm”, In Proc. Of IEEE 5th International Symposium on Multi-Dimensional Mobile Communications, 2004

MUL-4 Schmidt, Thomas C., Waehlisch, Matthias, “ Multicast Mobility in MIPv6: Problem Statement”, IRTF draft: draft-irtf-mobopts-mmcastv6-ps-00.txt, MobOpts Research Group, October 2005.


78

Physical and Data Link Layer Constraints Table 6-12 lists the references for the Physical and Data Link Layer Concepts problem area.

Table 6-12. Physical and data Link Layer Constraints References

Document ID


PHY-1 Len Schiavone, Joint Tactical Radio System (JTRS) briefing, http://enterprise.spawar.navy.mil/body.cfm?type=c&category=27&subcat=60

PHY-2 Software Communications Architecture (SCA), http://jtrs.spawar.navy.mil/sca/

PHY-3 Common Data Link (CDL), http://www.globalsecurity.org/intell/systems/cdl.htm

PHY-4 Captain James Loiselle, et. al., The Next Generation Mobile User Objective System (MUOS), http://enterprise.spawar.navy.mil/UploadedFiles/next_gen_muos.pdf

PHY-5 Global System for Mobile Communication (GSM), http://www.gsmworld.com/index.shtml

PHY-6 3rd Generation Wireless Systems, http://www.fcc.gov/3G/

PHY-7 WiFi or IEEE 802.11, http://en.wikipedia.org/wiki/Wi-Fi

PHY-8 WiMax or IEEE 802.16, http://en.wikipedia.org/wiki/WiMax

Documents

Network-Centric Operations Industry Consortium (NCOIC ...mobile networking problem areas and the process for addressing them. MNWG is a living, distributed, collaborative forum providing