As per Relevance of the word communication, we have this rfc below:











Network Working Group B.
Request for Comments: 1677 Naval Research
Category: Informational August 1994


Tactical Radio Frequency Communication Requirements for

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited



This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list

Executive

The U.S. Navy has several efforts exploring the applicability
commercial internetworking technology to tactical RF networks.
these include the NATO Communication System Network
(CSNI) project, the Naval Research Laboratory Data/Voice
Advanced Technology Demonstration (D/V ATD), and the
Communication Support System (CSS) architecture development

Critical requirements have been identified for security, mobility
real-time data delivery applications, multicast, and quality-of
service and policy based routing. Address scaling for
application of internet technology will include potentially
large numbers of local (intra-platform) distributed information
weapons systems and a smaller number of nodes requiring
connectivity. The flexibility of the current Internet Protocol (IP
for supporting widely different communication media should
preserved to meet the needs of the highly heterogeneous networks
the tactical environment. Compact protocol headers are necessary
efficient data transfer on the relatively-low throughput RF systems
Mechanisms which can enhance the effectiveness of an
datagram protocol to provide resource reservation, priority,
service quality guarantees are also very important. The
nature of many RF networks and the need for broad dissemination
information to warfighting participants makes multicast the
case for information flow in the tactical environment





Adamson [Page 1]

RFC 1677 IPng Tactical RF Requirements August 1994




This paper describes requirements for Internet Protocol
generation (IPng) candidates with respect to their application
military tactical radio frequency (RF) communication networks.
foundation for these requirements are experiences in the
Communication System Network Interoperability (CSNI) project,
Naval Research Laboratory Data/Voice Integration Advanced
Demonstration (D/V ATD), and the Navy Communication Support
(CSS) architecture development

The goal of the CSNI project is to apply internetworking
to facilitate multi-national interoperability for typical
communication applications (e.g., electronic messaging, tactical
exchange, and digital voice) on typical tactical RF
links and networks. The International Standard Organization (ISO
Open Systems Interconnect (OSI) protocol suite, including
Connectionless Network Protocol (CLNP), was selected for this
for policy reasons. This paper will address design
encountered in meeting the project goals with this
protocol stack

The D/V ATD is focused on demonstrating a survivable, self
configuring, self-recovering RF subnetwork technology capable
simultaneously supporting data delivery, including message transfer
imagery, and tactical data, and real-time digital voice applications
Support for real-time interactive communication applications
extended to include a "white board" and other similar applications
IP datagram delivery is also planned as part of this
system

The CSS architecture will provide U.S. Navy tactical platforms with
broad array of user-transparent voice and data information
services. This will include support for sharing and management
limited platform communication resources among multiple
communities. Emphasis is placed on attaining interoperability
other military services and foreign allies. Utilization
commercial off-the-shelf communications products to take advantage
existing economies of scale is important to make any resulting
design affordable. It is anticipated that open, voluntary standards
and flexible communication protocols, such as IP, will play a
role in meeting the goals of this architecture



Before addressing any IPng requirements as applied to tactical
communications, it is necessary to define what this paper means
"IPng requirements". To maintain brevity, this paper will focus



Adamson [Page 2]

RFC 1677 IPng Tactical RF Requirements August 1994


criteria related specifically to the design of an OSI model's Layer 3
protocol format and a few other areas suggested by RFC 1550.
are several additional areas of concern in applying
protocols to the military tactical RF setting including
protocol design, address assignment, network management, and
management. While these areas are equally important, this paper
attempt to satisfy the purpose of RFC 1550 and address issues
directly applicable to selection of an IPng candidate



The projection given in RFC 1550 that IPng should be able to
with 10 to the 12th nodes is more than adequate in the face
military requirements. More important is that it is possible
assign addresses efficiently. For example, although a
platform may have a relatively small number of nodes
requirements to communicate with a larger, global infrastructure
there will likely be applications of IPng to management and
of distributed systems (e.g., specific radio communications
and processors, weapons systems, etc.) within the platform.
local expansion of address space requirements may not
need to be solved by "sheer numbers" of globally-unique addresses
perhaps by alternate delimitation of addressing to
between globally-unique and locally-unique addressing.
advantages of a compact internet address header are clear
relatively low capacity RF networks

Timescale, Transition and

The U.S. Navy and other services are only recently (the last
years) beginning to design and deploy systems utilizing open
internetworking technology. From this point of view, the time
for selection of IPng must be somewhat rapid. Otherwise,
transition phases will need to be suffered, 1) the move from unique
"stove pipe" systems to open, internetworked (e.g., IP) systems,
then 2) a transition from deployed IP-based systems to IPng. In
sense, if an IPng is quickly accepted and widely implemented,
transition for tactical military systems will be somewhat easier
the enterprise Internet where a large investment in current
already exists. However, having said this, the Department of
as a whole already deploys a large number of IP-capable systems,
the issue of transition from IP to IPng remains significant



As with any military system, information security,
confidentiality and authenticity of data, is of paramount importance
With regards to IPng, network layer security mechanisms for



Adamson [Page 3]

RFC 1677 IPng Tactical RF Requirements August 1994


RF networks generally important for authentication purposes
including routing protocol authentication, source authentication,
user network access control. Concerns for denial of service attacks
traffic analysis monitoring, etc., usually dictate that tactical
communication networks provide link layer security mechanisms
Compartmentalization and multiple levels of security for
users of common communication resources call for additional
mechanisms at the transport layer or above. In the typical
RF environment, network layer confidentiality and, in some cases
even authentication becomes redundant with these other
mechanisms

The need for network layer security mechanisms becomes more
when the military utilizes commercial telecommunications systems
has tactical systems inter-connected with commercial internets
While the Network Encryption Server (NES) works in this role today
there is a desire for a more integrated, higher performance
in the future. Thus, to meet the military requirement
confidentiality and authentication, an IPng candidate must be
of operating in a secure manner when necessary, but also allow
efficient operation on low-throughput RF links when other
mechanisms are already in place

In either of these cases, key management is extremely important
Ideally, a common key management system could be used to provide
distribution for security mechanisms at any layer from
application to the link layer. As a result, it is anticipated
however, that key distribution is a function of management,
should not dependent upon a particular IPng protocol format



The definition of most tactical systems include mobility in
form. Many tactical RF network designs provide means for members
join and leave particular RF subnets as their position changes.
example, as a platform moves out of the RF line-of-sight (LOS) range
it may switch from a typical LOS RF media such as the ultra-
frequency (UHF) band to a long-haul RF media such as high
(HF) or satellite communication (SATCOM).

In some cases, such as the D/V ATD network, the RF subnet
perform its own routing and management of this dynamic topology
This will be invisible to the internet protocol except
(hopefully) subtle changes to some routing metrics (e.g., more
less delay to reach a host). In this instance, the RF
protocols serve as a buffer to the internet routing protocols
IPng will not need to be too concerned with mobility




Adamson [Page 4]

RFC 1677 IPng Tactical RF Requirements August 1994


In other cases, however, the platform may make a dramatic change
position and require a major change in internet routing. IPng
be able to support this situation. It is recognized that an
protocol may not be able to cope with large, rapid changes
topology. Efforts will be made to minimize the frequency of this
a tactical RF communication architecture, but there are
when a major change in topology is required

Furthermore, it should be realized that mobility in the
setting is not limited to individual nodes moving about, but that,
some cases, entire subnetworks may be moving. An example of this
a Navy ship with multiple LANs on board, moving through the
of different RF networks. In some cases, the RF subnet will
moving, as in the case of an aircraft strike force, or
battlegroup

Flows and Resource

The tactical military has very real requirements for multi-
services across its shared and inter-connected RF networks.
includes applications from digital secure voice integrated
applications such as "white boards" and position reporting
mission planning purposes to low-latency, high priority tactical
messages (target detection, identification, location and
information). Because of the limited capacity of tactical
networks, resource reservation is extremely important to
access to these valuable resources. Resource reservation can play
role in "congestion avoidance" for these limited resources as well
ensuring that quality-of-service data delivery requirements are
for multi-media communication

Note there is more required here than can be met by simple quality
of-service (QoS) based path selection and subsequent source-
to get real-time data such as voice delivered. For example,
support digital voice in the CSNI project, a call setup and
reservation protocol was designed. It was determined that the
mechanisms provided by the CLNP specification were not sufficient
our voice application path selection. Voice calls could not
routed and resources reserved based on any single QoS
(e.g., delay, capacity, etc.) alone. Some RF subnets in the
test bed simply did not have the capability to support voice calls
To perform resource reservation for the voice calls, the CLNP
metric was "hijacked" as essentially a Type of Service identifier
let the router know which datagrams were associated with a
call. The cost metric, concatenated with the source and
addresses were used to form a unique identifier for voice calls
the router and subnet state tables. Voice call paths were to
selected by the router (i.e. the "cost" metric was calculated) as



Adamson [Page 5]

RFC 1677 IPng Tactical RF Requirements August 1994


rule-based function of each subnet's capability to support voice,
delay, and its capacity. While source routing provided a
means for voice datagrams to find their way from router to router
the network address alone was not explicit enough to direct the
to the correct interface, particularly in cases where there
multiple communication media interconnecting two routers along
path. Fortunately, exclusive use of the cost QoS indicator for
in CSNI was able to serve as a flag to the router for
requiring special handling

While a simple Type of Service field as part of an IPng protocol
serve this purpose where there are a limited number of well
services (CSNI has a single special service - 2400 bps
voice), a more general technique such as RSVP's Flow
can support a larger set of such services. And a field, such as
one sometimes referred to as a Flow Identification (Flow ID),
play an important role in facilitating inter-networked
communication over these limited capacity networks

For example, the D/V ATD RF sub-network provides support for
connectionless datagram delivery and virtual circuit connectivity
To utilize this capability, an IPng could establish a virtual
connection across this RF subnetwork which meets the requirements
an RSVP Flow Specification. By creating an association between
particular Flow ID and the subnetwork header identifying
established virtual circuit, an IPng gateway could forward
across the low-capacity while removing most, if not all, of the
packet header information. The receiving gateway could re-
these fields based on the Flow Specification of the particular
ID/virtual circuit association

In summary, a field such as a Flow Identification can serve at
two important purposes

1) It can be used by routers (or gateways) to
packets with special, or pre-arranged
requirements. It is important to realize that it
not always be possible to "peek" at internet
content for this information if certain
considerations are met (e.g., an encrypted
layer).

2) It can aid mapping datagram services to
types of communication services provided
specialized subnet/data link layer protocols






Adamson [Page 6]

RFC 1677 IPng Tactical RF Requirements August 1994




Tactical military communication has a very clear requirement
multicast. Efficient dissemination of information to
warfighting participants can be the key to success in a battle.
modern warfare, this information includes imagery, the "
scene" via tactical data messages, messaging information, and real
time interactive applications such as digital secure voice. Many
the tactical RF communication media are broadcast by nature,
multicast routing can take advantage of this topology to
critical data to a large number of participants. The
limitations imposed by these RF media and the physics of
electronic counter measures (ECM) dictate that this information
distributed efficiently. A multicast architecture is the
case for information flow in a tactical internetwork

Quality of Service and Policy-Based

Quality of service and policy based routing are of
importance in a tactical environment with limited
resources, limited bandwidth, and possible degradation and/or
of service. Priority is a very important criteria in the
setting. In the tactical RF world of limited resources (
bandwidth, radio assets, etc.) there will be instances when there
not sufficient capacity to provide all users with their perception
required communication capability. It is extremely important for
shared, automated communication system to delegate capacity
priority users. Unlike the commercial world, where everyone has
more equal footing, it is possible in the military environment
assign priority to users or even individual datagrams. An example
this is the tactical data exchange. Tactical data messages
generally single-datagram messages containing information on
location, bearing, identification, etc., of entities detected
sensors. In CSNI, tactical data messages were assigned 15
levels of CLNP priority. This ensured that important messages,
as a rapidly approaching enemy missile's trajectory, were
priority over less important messages, such as a friendly, slow
moving tanker's heading



There will be a significant amount of applicability to tactical
networks. The current IP and CLNP protocols are being
considerable attention in the tactical RF community as a means
provide communication interoperability across a large set
heterogeneous RF networks in use by different services and countries
The applicability of IPng can only improve with the inclusion
features critical to supporting QoS and Policy based routing



Adamson [Page 7]

RFC 1677 IPng Tactical RF Requirements August 1994


security, real-time multi-media data delivery, and
addressing. It must be noted that it is very important that the
protocol headers not grow overly large. There is a sharp
between the value added by these headers (interoperability,
addressing, etc.) and the degree of communication
attainable on limited capacity RF networks. Regardless of the
rate that future RF networks will be capable of supporting, there
always a tactical advantage in utilizing your resources
efficiently

Datagram

The datagram service paradigm provides many useful features
tactical communication networks. The "memory" provided by
headers, provides an inherent amount of survivability essential
the dynamics of the tactical communication environment.
availability of platforms for routing and relaying is never 100%
certain in a tactical scenario. The efficiency with which multi-
can be implemented in a connectionless network is highly critical
the tactical environment where rapid, efficient
dissemination can be a deciding factor. And, as has been proven
with several different Internet applications and experiments,
datagram service is capable of providing useful connection-
and real-time communication services

Consideration should be given in IPng to how it can co-exist
other architectures such as switching fabrics which offer demand
based control over topology and connectivity. The military owns
of its own communication resources and one of the large problems
managing the military communication infrastructure is directing
underlying resources to where they are needed.
management (SNMP, etc.) is of course useful here, but
communication media can be somewhat dynamically allocated.
switching designs offer some advantages here. Dial-up IP routing
an example of an integrated solution. The IPng should be capable
supporting a similar type of operation

Support of Communication

The tactical communication environment includes a very broad
of communication media from shipboard fiber-optic LANs to very
data rate (<2400 bps) RF links. Many of the RF links, even
speed ones, can exhibit error statistics not necessarily well
serviced by higher layer reliable protocols (i.e., TCP). In
cases, efficient lower layer protocols can be implemented to
reliable datagram delivery at the link layer, but at the cost
highly variable delay performance




Adamson [Page 8]

RFC 1677 IPng Tactical RF Requirements August 1994


It is also important to recognize that RF communication cannot
viewed from the IPng designer as simple point-to-point links
Often, highly complex, unique subnetwork protocols are utilized
meet requirements of survivability, communications performance
limited bandwidth, anti- jam and/or low probability of
requirements. In some of these cases IPng will be one of
Layer 3 protocols sharing the subnetwork

It is understood that IPng cannot be the panacea of Layer 3
protocols, particularly when it comes to providing special
to support the endangered-specie low data rate user. However,
that there are many valuable low data rate applications useful to
tactical user. And low user data rates, coupled with
networking protocols can allow many more users share limited
bandwidth. As a result, any mechanisms which facilitate
of network headers can be considered highly valuable in an
candidate

Security

Security issues are discussed throughout this memo

Author's

R. Brian
Communication Systems
Information Technology
Naval Research
NRL Code 5523
Washington, DC 20375

EMail: adamson@itd.nrl.navy.



















Adamson [Page 9]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum