[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT          EXPIRES MARCH 1998              INTERNET DRAFT

Rex Buddenberg
Editor

Automated Digital Network System Description
<draft-rfced-info-buddenberg-00.txt>

Status of This Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.


Contributing Authors

The following are the authors of the description.  This work compiled
and digested internal notes, in-house training materials and several
conversations with the NRaD engineers.  The material of this memo was
used as a chapter in each of these students' theses:

Brian Rehard, Lt, US Navy
Jim Sullivan, Lt, US Navy
Eric Andalis, Lt, US Navy
Mark Witzel, Maj, US Marine Corps


Editors' Note This memo is a first attempt at publicly documenting
internal Navy laboratory work aimed at encapsulating a variety of
connectivity options inside a radio-WAN shell that fits into the
internet structure.

I. Introduction
        A. What is ADNS?
        B. What is ADNS good for?
                1. Mobile Platforms
                2. Alternative to Wire/Fiber Transmission
        C. Why invest in ADNS?
                1. Quality of Service
                2. Cost Effective Bandwidth
                3. Leverages the existing Internet
                4. Flexibility
        D. How does ADNS work?
        E. ADNS Advantages
                1. Removing Humans From the Loop
                2. Load Sharing
                3. Optimal Use of Bandwidth
                4. Communications Agility
                5. Transparency of Installation and Use
                6. Ease of Upgrade
                7. Single Point for Communications Management
                8. Ability to Transmit All Types of Data
        F. ADNS Disadvantages
                1. Cost of Installation

II. ADNS Operational Description
        A. Overview
        B. Network Features
                1. Routing Protocols
                        a. OSPF
                        b. BGP4
     2. Logical Organization
        C. Key Features/Functions
                1. Priority
                        a. Priority Tables
                        b. Determining Message Priority
                        c. Message Transmission
                2. Load Balancing
                3. Congestion Control
                        a. Load Sharing
                                1) Restrictions
                                2) Implementation
                        b. Source Quench
                4. TCP Duplicate Packet Transmission Problems
                        a. TCP Duplicate Packet Rejection
        D. Integrated Network Management
                1. Overview
                        a. Local Control Center
                                1) Network Manager
                                2) Distributed Manager
                                3) Communication Automation Manager
                                        i) Communication Manager
                                        ii) Site Manager
                                        iii) Equipment Manager
                        b. Autonomous System Control Center
                        c. Network Operations Center
                2. Network Management Tools
                        a. Network Management System Software
                        b. Third Party Applications

III. Hardware
          A. LAN
        B. Router
        C. CRIU
        D. CAP
        E. Cryptographic Device
        F. Modem
        G. Connectivity Media

IV.  Acknowledgements and addresses

I.  Introduction

A.  What is ADNS?

The Navy's Automated Digital Network System (ADNS) provides a means
for ship's to centralize and automate the operation of multiple
independent radio communications systems into an efficient
communications network.

ADNS provides connectivity for transmitting bits (which may represent
voice, video or data) creating a seamless ship to ship and ship to
shore communications network. By managing all of the radio assets
within one system, ADNS creates a reliable multiple path
communications network.  This network is essentially a radio-based
Wide Area Network (Radio-WAN).  What constitutes the internals of the
Radio-WAN are those radio systems configured to support ADNS.



                            Media Dependent Layer
        |---------------------------------------------------------|
        |                 Media Independent Layer                 |
        |               |-------------------------|               |
        |               |                         |               |
  ---|  |  ________     |   (MilSat)              |     ________  |
|---
  ---|  | |        |    |            (Commercial) |    |        | |
|---
  ---|----| Router |----|            (Satellites) |----| Router
|----|---
  ---|  | |________|    |                         |    |________| |
|---
  ---|  |               |       (HF)              |               |
|---
        |               |-------------------------|               |
  LAN   |                      Radio-WAN                          |
LAN
        |---------------------------------------------------------|


Although currently a Navy specific installation, ADNS is like any
other LAN/WAN Internet connection utilizing commercial products.
Applications need only adhere to the established Internet protocols
that ADNS has adopted.  This allows a sense of transparency of
applications to ADNS. It is also an open-ended system that allows for
future expansion.  ADNS allows a plug and play like addition of radio
links in a process completely transparent to the user.

B.  What is ADNS good for?

A group of platforms, linked by ADNS, create a radio-based
packet-switched WAN.  By using existing Internet technology and open
standards users of ADNS have seamless transparent access to the
Internet.  Using a load balancing concept ADNS spreads traffic equally
across the appropriate radio links such that the available capacity is
the sum of all the links.  ADNS does not provide additional bandwidth
instead it multiplexes the bandwidth that is already available.

There has recently been an insatiable demand for Internet access in
areas never previously deemed necessary and although Internet
technologies are relatively new, limitations are being experienced on
traditional wire/fiber transmission paths.  The primary purpose of
wireless data transfer is for communications with mobile platforms.
This capability already exists in various forms.  However, ADNS
provides a robust means of choosing the most efficient set of paths to
transfer data in a way that is transparent to the user. It allows
existing stovepipe systems to be integrated into one common data
transmission network.  When linked with a fixed shore site, to provide
wire/fiber connectivity, this network becomes, in essence, a mobile
extension of the Internet.

1. Mobile Platforms

Although ADNS was specifically designed for the Navy, it's commercial
potential is great.  The easiest technology transfer can be applied to
maritime platforms.  Commercial and research ships have similar needs
as the Navy for transferring data to and from shore sites.  Imagery
(such as weather) transfer, e-mail, Internet access, and file transfer
capability are becoming essential tools necessary to accomplish
everyday tasks.  Commercial aircraft crew and passengers can also
benefit from these same capabilities.  Cellular phones in automobiles
are commonplace.  Some cars already receive one way satellite position
information using the Global Positioning System (GPS). Currently there
is even auto industry research into providing cars with Internet
access.  The field of mobile communications has become increasingly
complex and will continue to grow.  However, what should be avoided is
a spaghetti-like architecture of different transmission paths linked
to different applications.

The traditional way to adopt new data transfer technologies is to
implement a stovepipe system with its own dedicated transmission path.
Mobile platforms, especially large ones like ships, typically have
more than one transmission path for data transfer.  However, if data
is to be transferred, a dedicated radio link has to be assigned to a
specific application.  An application can not share different links or
be distributed.  The same is true for aircraft.  Although more limited
in space, aircraft too have different radio links which transmit data
in a stovepipe fashion.  The requirement for data transfer capability
in autos is a relatively new concept. However, the reality of cellular
phones and GPS combined with the possibility of Internet access
already points to multiple transmission paths. Wireless communications
do not have to be limited to just mobile platforms.  It can also be a
viable alternative to traditional shore links especially if they are
saturated or can not be established, for example, in remote areas
where the infrastructure just doesn't exist.

2. Alternative to Wire/Fiber Transmission

Traditional shore transmission paths have been saturated with the
increasing number of Internet users.  Although much research has been
done in alternative technologies to alleviate this congestion, such as
installing optical fiber, these solutions often require investing in a
whole new and different infrastructure.  However, ADNS does not
provide the same high capacity data transfer capability as shore
backbones but instead allows an alternative to traditional mediums for
transmitting data without worrying about infrastructure changes.
Wireless data transfer could also be an attractive short term solution
for areas where the infrastructure doesn't exist or is temporary such
as in remote regions.  A parallel to this can be seen in many
lesser-developed countries where cellular telephones have proliferated
because of inadequate landline telephone networks.


C.  What Does ADNS Do?

A mobile platform can be thought of as a roaming Local Area Network
(LAN).  What existed onboard U.S. Navy ships prior to ADNS was a
potpourri of different LANs and radio systems.  If data was to be
transferred to and from a ship, a different radio system was used for
each application. ADNS allows platforms with more than one
transmission path to integrate these different systems via one black
box (ADNS), which then distributes data throughout the different paths
in the most efficient manner.  This method is desirable for several
reasons.

1.  Load Sharing

If one or more transmission paths fail or are congested, ADNS can
redirect data flow to open channels, which leads to an increased
quality of service (QoS). ADNS can distribute data flow much more
efficiently than the present stovepipe system.  For example, a video
teleconference (VTC) often inundates bandwidth, leaving other
applications looking for an open transmission path.  Other
applications such as e-mail can be redirected to less congested
channels instead of being stacked in a queue, waiting for
transmission.

2.  Cost Effective Bandwidth

ADNS can direct data from different applications through desired
transmission paths.  This can be done to preferentially use the most
cost-effective means for data transfer.

3.  Leverages the existing Internet

Another big appeal for ADNS, and one of the main reasons why the Navy
has developed it, is that ADNS ties together the existing stovepipe
communications architecture.  There is no need to create a brand new
infrastructure.  Existing organizational LANs can be connected to ADNS
and have access to the full range of communications assets available
to that unit.

4.  Flexibility

The use of open protocols and Commercial off the Shelf (COTS) hardware
creates a very flexible system.  Modifications or additions to the
shipboard LAN have no effect on ADNS.  By using IP routers as the
interface between ADNS and the shipboard LAN modifications on one side
of the router are transparent to the other.  Adding a new radio system
is not much more complicated than adding a new circuit card.

D.  How does ADNS work?

The easiest way to visualize how the system works is through an
example.  The following is a high level block diagram of ADNS and
general description of operation.

|---------------------------------|
|---------------------------------|
|                                 |          |
        |
|  _____     ________     ______  |  Radio-  |  ______     ________
 _____  |
| |     |   |        |   |      | |   WAN    | |      |   |        |
|     | |
| | LAN |---| Router |---| ADNS | |----------| | ADNS |---| Router
|---| LAN | |
| |_____|   |________|   |______| |          | |______|   |________|
|_____| |
|                                 |          |
        |
| -------------------- -----------|
|---------------------------------|
       Mobile Platform                                  Mobile
Platform


Suppose that a user on a ship at sea wished to transfer a file to
another user on a different ship.  Let us also assume that both users'
computers are connected to their respective shipboard LANs.  When the
originating user is ready to send the message he simply clicks on the
appropriate button to send the message on its way via the ship's LAN.

The size of most data files will necessitate their being broken into
multiple IP datagrams. The router, processing each datagram
independently, uses the Open Shortest Path First (OSPF) protocol to
determine the best path(s) to reach the destination. If there are
multiple equal cost paths the router will balance the load amongst
them. Similar to a packet switched network a single message may be
routed via multiple paths.  The router then forwards the datagrams to
ADNS.

ADNS prioritizes, queues and transmits the datagrams on the selected
radio system.  The transmitted datagrams transit the Radio-WAN much
the same way as in a packet switched network. At the destination there
is a mirror image of the transmitting site.  Arriving IP datagrams
pass back through ADNS to the router and onto the LAN where they are
received and reassembled at the destination host.

This example described the transmission of one message to one
destination via a single RF path.  To understand the system's true
potential, envision multiple ADNS capable platforms communicating
simultaneously from multiple applications via multiple RF paths.


E. ADNS Advantages

1. Removing humans from the loop

In current naval communication systems, messages are generated on
personal computers or workstations.  These messages are transmitted
via LAN, (or by use of magnetic media such as floppy disks where no
LAN exists), to the communication center.  The messages are then
processed by technicians and transmitted.  This process introduces
time delays ranging from minutes to hours.  ADNS eliminates the need
for human processing of messages by establishing a direct connection
from any node on the LAN, through the transmitter, to the receiver at
the intended destination.  The result is complete automation of the
transmission process, with total elimination of any handling delays
caused by human interaction.

2.   Load Sharing

Most naval vessels maintain at least two operational communication
channels at all times.  The reason for multiple channels is a legacy
one - systems were developed such that only certain types of
information could be transmitted and received over each channel.  This
frequently results in one or more channels being completely silent,
while another is backlogged with traffic.  The Load Sharing Feature of
ADNS was specifically designed to alleviate these backlogs by making
more efficient use of all operational communication channels.  This is
accomplished assigning a "cost" value to each network.  Message queues
in each CAP are monitored and messages are routed evenly across equal
cost circuits.

3.  Optimal use of bandwidth

Network costs are assigned such that higher capacity circuits are
assigned lower cost values.  ADNS maximizes throughput by finding the
lowest cost path for a message to reach its destination.  The
combination of removing humans from the loop, load sharing and using
the lowest cost paths discussed above results in a four-fold increase
in throughput during peak traffic times.  This is a direct increase in
the bottom line throughput of the communications system without
purchasing additional transmitters.

4.  Communications Agility

ADNS provides the capability for two units that do not share a common
communication channel to maintain communications.  As long as each
unit is operating at least one communication channel and at least one
node on the network is operating both channels simultaneously,
communications can occur.  This process is completely transparent to
the users, and occurs with no human intervention.  This is analogous
to Internet packet delivery.  Few end systems share a common
communications channel (that is, they are on the same network
segment).


5.  Transparency of installation and use

The installation of ADNS is totally transparent to the end users.  It
merely appears that a new router has been added to the LAN with links
to many other LANs.  There is no major LAN or transmitter
reconfiguration that is required.  Additionally, there are no major
infrastructure modifications (cooling, ventilation, etc.) required and
power requirements are modest.

6.  Logistics

The entire installation is small and lightweight, allowing it to be
installed in any unused space without impacting shipboard weight and
balance.

7.  Ease of upgrade

Following initial installation, upgrading of ADNS is quite simple.
Addition of new communication channels can be accomplished through the
installation of the appropriate CAP cards.  Adding capabilities to
ADNS itself, such as installing successive builds as they become
available, is as simple as downloading the new software.  Router
reconfiguration is a relatively simple matter as well.

8.  Single point for Communications Management

ADNS provides a single point for monitoring all communications, both
incoming and outgoing.  Prior to ADNS, monitoring all communications
was much more difficult due to the lack of interconnection between
stovepipe systems.  Each of these systems had to be monitored
separately.  This monitoring capability is available locally via the
local net manager's workstation, or remotely from the Network
Operations Center.


9.  Ability to transmit all types of data

Essentially, ADNS transmits Internet Protocol (IP) datagrams from one
router to another.  It is the applications on these LANs that decode
the datagrams and put the information contained in them to use.
Therefore, ADNS can transmit text, graphics, voice, or video
applications over existing channels, without the need for developing
expensive new stovepipe systems to support each new application.

F. ADNS Disadvantages

1. Cost of installation

The high initial cost of an ADNS installation is a large obstacle to
its widespread use. However, new technology, innovation, and mass
production of ADNS should continue to drive costs down.  The hardware
used in an ADNS installation is COTS equipment but it is very
implementation specific.  It is unlikely that a unit will already
possess equipment that can be modified for ADNS in order to save money
on an initial installation.  However, future builds of ADNS are
planned that will incorporate more readily available hardware.


II. ADNS Operational Description

A. Overview

The behavior of the Radio-WAN created by ADNS is the same as a
terrestrial WAN.  The router on one platform still "talks" to routers
on other platforms, but at a slower rate than if they were connected
by wire or fiber.  Some of the circuits used in the Navy's ADNS
program, such as HF and UHF have transmission rates in the 2.4Kbps
range.  The insertion of the ADNS hardware and the RF transmission
path is simply a conduit for creating a router based network.  ADNS
deals strictly with IP datagrams.  Although some encapsulation occurs
as a result of the handling process the underlying packets are not
altered and thus the path between destinations is in essence
transparent to the routers.

The diagram below shows the relative position of each component in a
typical ADNS setup. The minimum component mix needed for a complete
ADNS installation consists of: LAN-Router-CRIU-CAP-Cryptographic
Device-Modem-RF System.  From the Channel Access Protocol (CAP) to
Router Interface Unit (CRIU) back (to the left) there will be only one
of each for a given installation. From the CAP forward (to the right)
there will be one chain for each radio system that is part of the
system (i.e. there may be a UHF SATCOM chain, a UHF LOS chain, an SHF
chain, an HF chain, etc.).  In this particular configuration there are
three RF paths connected to ADNS.

                                    _____     _______     _______
______
                                   |     |   |       |   |       |   |
     |
                                 |-| CAP |---|CRYPTO |---|MODEM
|---|RADIO |
                                 | |_____|   |_______|   |_______|
|______|
  _____     ________     ______  |  _____     ______      _______
______
 |     |   |        |   |      | | |     |   |       |   |       |   |
     |
 | LAN |---| Router |---| CRIU |---| CAP |---|CRYPTO |---|MODEM
|---|RADIO |
 |_____|   |________|   |______| | |_____|   |_______|   |_______|
|______|
                                 |  _____     _______     _______
______
                                 | |     |   |       |   |       |   |
     |
                                 |-| CAP |---|CRYPTO |---|MODEM
|---|RADIO |
                                   |_____|   |_______|   |_______|
|______|

As discussed earlier, the router accepts outbound datagrams from the
LAN and selects the best path for reaching the destination.  The CRIU,
which interfaces between the router and CAP, assigns a priority to
outbound IP datagrams.  Priority is inferred based on both the source
application (logical port number) and the host (IP address) from which
the message originated.  At the CAP the message is placed in a queue
to await transmission. Messages in the CAP queue are sorted by the
priority assigned by the CRIU.

When the message leaves the CAP it passes through a cryptographic
device.  The standard Navy ADNS configuration operates at the secret
high level of classification, thus all information entering the RF
network is link encrypted.  This: 1. Conforms to existing practice.
2. Provides resistance to AS spoofing.  3. Provides limited content
confidentiality/authenticity protection (because this layer of
encryption is stripped off at each routing point).  Although this
provides protection during transmission it does not provide content
security once the information passes through the cryptographic device
at the receiving end.  4. Provides opportunities for secure tunnels
such as Unix Secure Shell (SSH) or Network Encryption System (NES),
which deal with IP datagram encapsulation (IP datagrams inside other
datagrams).  These encapsulated IP datagrams are transmitted by ADNS
in the same manner as any other IP datagrams.  5. Does not affect
applications that offer end-to-end security (e.g. secure e-mail).
Similar to secure tunnels, end system encrypted datagrams are
unaffected by the presence of ADNS in the system.

After leaving the Cryptographic device the datagram passes through a
modem and then enters the transmitter.  Once it leaves the ship the
message begins traveling via the predetermined path to its
destination.  Upon arrival at its destination the datagram, traveling
through a mirror image of the originating system, terminates at the
host specified in the IP header.


B. Network Features

1. Routing Protocols

ADNS uses three different routing protocols. The primary reason for
using these algorithms was that the specifications for all three are
in the public domain.

a. Open Shortest Path First (OSPF)/Multicast OSPF (MOSPF)

OSPF is used as the Internal Gateway Protocol (IGP) for routing within
an AS.  The specification for OSPF Version 2 is contained in Request
For Comments (RFC) 2178.  It is a dynamic protocol in that each router
maintains a continuously updated database containing the status of all
other routers in the same system. OSPF uses a lowest cost algorithm to
determine the best path to send a message to its destination.  Costs
are determined based on metrics values assigned to the various
transmission paths.

Multicast OSPF (MOSPF) is used for multicast within an AS. The
specification for MOSPF is contained in RFC 1584.  MOSPF uses the same
lowest cost concept as OSPF except the lowest cost is determined with
respect to the group.

b. Border Gateway Protocol Version 4 (BGP4)

BGP4 is used as the External Gateway Protocol (EGP) for routing
between ASs.  Specifics for BGP4 can be found in RFC 1771.  BGP4 is
not as dynamic as OSPF and makes its routing decisions based on
predetermined routes.  In ADNS, BGP4 will typically reside at the
shore station in a system. Since BGP4 requires a more stable
environment than OSPF the shore station is the logical choice.

2. Logical Organization

The naming and logical grouping of the elements in an ADNS network are
based on the concepts established by the routing protocols used by
ADNS.

The basic unit of an OSPF network is an area.  For ADNS a ship is
typically considered an area. Certain shore installations will also be
areas since the ships need an interface point with other shore based
establishments.

A number of ships grouped together using OSPF create an Autonomous
System (AS).  A typical AS consists of a group of Navy ships with some
logical connection, such as a common mission.  A Battle Group is a
typical AS.  The emphasis in AS establishment is on mission and not
location.  The units do not have to be in the same geographic region
to be in the same AS.  At least one and possibly two or more shore
communications establishments will also be a part of an AS to act as
the gateway to other navy networks such as SIPRNET (Secret IP Router
Network) or the Internet.

The combined network of RF systems creates the subnet backbone of the
AS.  Each subnet is a different RF system such as UHF Satcom, SHF
Satcom or INMARSAT B.  The router on each ship that interfaces with
ADNS is established as an Area Border Router (ABR).  Each ABR operates
OSPF. Part of the data that is maintained in the OSPF routing tables
are metrics for each subnet in the AS.  In current ADNS installations,
metrics values are assigned based on subnet capacity or bandwidth.
Higher capacity subnets are assigned lower metric values.  The values
chosen for these metrics determine how the system performs load
balancing and load sharing, as discussed below.  Obviously since each
router must maintain a dynamically updated table of every other router
in the AS there is a limit to the number of routers which can be
managed effectively.  This is what drives the upper limit to the size
of an AS.

The router that acts as the gateway between an AS and other ASs, WANs,
or the Internet uses BGP4.  The shore establishment usually performs
this function since BGP4 needs a stable environment.  The OSPF to BGP4
transition acts to hide the internals of the AS from the outside.
Routers outside the AS don't need to know the specifics of all the
routers inside the AS.  They only need to know where the BGP4 gateway
into the AS is.  Changing missions will prompt changes to an AS.
Ships may need to transfer from one AS to another to support
operational or training objectives.  This dynamic reorganization
requirement reinforces the need to shield the internal routing issues
of each AS from the outside.

This illustration shows the relationship between routers within a
simple Autonomous System.


                               To other
                          Autonomous Systems
                                  or
                          Wide Area Networks
                                  |
                                 ___
                                /   \
                               /     \
                              / BGP4  \
                             (-(Shore)-)
                              \ OSPF  /|
                              |\     / |
                              | \___/  |
                              |   |    |
                              |   |    |
           ___              +-)---)----)--+              ___
          /   \ ------------|-)--EHF---)--|-------------/   \
         /     \            | |        |  |            /     \
        / OSPF  \-----------|-HF-------)--|-----------/ OSPF  \
       ( router  )          |          |  |          ( router  )
        \(Ship) /-----------|---------UHF-|-----------\(Ship) /
         \     /            +-------------+            \     /
          \___/            Backbone Networks            \___/

The third party routing feature of this type of network can be seen in
the illustration below. If the originating and destination ships are
not operating a common circuit ADNS will route traffic through a third
platform which has connectivity on both source and destination
circuits.  By maintaining the status of other ships in the AS, ADNS
can determine the best path to ensure delivery of each message.  The
diagram shows how the sending ship's router (R1) will send via either
EHF or UHF (or both, depending on the metric values assigned to each
RF path) to R3.  R3 will then forward via HF to the destination ship,
R2.

                                 ___
                                /   \
                               /     \
                              /       \
                             (   R3    )
                              \       /|
                              |\     / |
                              | \___/  |
                              v   |    ^
                              |   ^    |
           ___              +-)---)----)--+              ___
          /   \------->-----|-)--EHF   )  |             /   \
         /     \            | |        |  |            /     \
        /  R1   \           | HF-------)--|--->-------/  R2   \
       ( Origin  )          |          |  |          (  Dest.  )
        \       /------>----|---------UHF |           \       /
         \     /            +-------------+            \     /
          \___/                                         \___/


C. Key Features/Functions of ADNS

1. Priority

Several different methods for assigning priority to outgoing messages
were evaluated during the ADNS implementation process.  One obvious
method, using the built-in precedence field in the IP header, was
briefly considered.  This idea was quickly discarded since no relevant
applications currently use this feature of the IP header.  Eventually,
a priority scheme was implemented which assigned priorities of 0
(lowest) to 15 (highest).  The two methods which proved most useful
for assigning priority were based on source IP address (Host), or port
number (Application).

This approach has the same advantages and drawbacks of a firewall that
uses the same data to make its filtering decisions.  The advantage is
its practicality.  The disadvantage is that it's rather crude and, at
the moment requires manual configuration of the router's routing
table.

a. Priority Tables

The CRIU maintains two priority tables.  The Source IP table contains
the IP addresses of hosts on the associated LAN and the priority which
they have been assigned.  There are no default settings for this
table.  If a host is to have an associated priority it must be entered
into the table.  This table is filled in manually by the local ADNS
Manager during initial system configuration and can be updated at any
time.  The Source IP table contains space for up to 40 entries.

The second table maintained by the CRIU is the Port priority table.
It contains the dedicated port numbers used by certain applications
and the priority that has been assigned to that particular
application.  Just as with the Source IP table above, there are no
default values, priorities must be entered manually, and it contains
space for up to 40 entries.

b. Determining Message Priority

The CRIU receives datagrams from the router.  The CRIU determines the
port number and originating IP address for each datagram and assigns
priority based on entries in the Source IP and Port priority tables.
Here, a conflict may arise.  If the Source IP priority table assigns a
certain priority to a particular datagram and the Port priority table
indicates a different priority for the same datagram, priority
assignment will be made on the basis of Source IP address.  This
allows priority based primarily on host, and secondarily on
application should the host have no assigned priority.  If neither the
host nor the application have an assigned priority, the CRIU assigns a
default value of priority 4.  Once assigned, the priority is placed in
the IP datagram header and the entire IP datagram is passed to the
CAP.

c. Message Transmission

Following Assignment of priority, the IP datagram is forwarded to the
appropriate CAP, where it is entered into one of 16 queues based on
priority.  Datagrams are assembled into transmission units, each of
which can contain up to 64 IP datagrams.  The size of the transmission
unit depends on the capacity of the link.  Lower capacity links will
have to utilize lower transmission unit sizes.  The CAP builds a
transmission unit by removing datagrams from the queues in order of
priority.  Datagrams are removed from the highest priority queue
first, until it is empty. Datagrams are removed in sequence,
continuing down the priority queues until the transmission unit is
complete or all queues are empty.  The transmission unit is sent from
the CAP to the corresponding RF transmitter and the process is
repeated.

2. Load Balancing

Load balancing is the sharing of transmission load equally among
different subnets. When the router selects a transmission path it does
so based on the metrics assigned to that RF system.  OSPF metrics are
based on link capacity, with links having similar capacity being
assigned identical metric values. If multiple CAPs have the same
metrics values then the router will balance the load evenly by
alternating between those CAPs.  For load balancing to work
effectively the sharing must be done among systems of equivalent
capacity.  Consequently, when assigning metric values to RF systems it
is important that only networks of like capacity be assigned the same
values.  For example, if a ship is operating two active subnets, HF
(which operates at about 2.4Kbps) and SHF (which operates at about
64Kbps) assigning the same metric values to each would overload the HF
circuit.  The router would divide the load equally between the two,
not proportionally. During periods of high traffic density the SHF
link could handle the load more effectively than the HF link, which
would become backlogged with data.

3. Congestion Control

As described above, each CAP maintains separate queues for each
priority (0-15).  Should one of these queues become full, the CAP does
not provide any overflow queue so additional datagrams with this same
priority will be dropped.  In order to prevent this situation from
occurring, the CRIU monitors the CAP queues and either starts load
sharing or issues a Source Quench command.

Each queue in a CAP is allocated a certain queue size to store IP
datagrams prior to transmission.  The CAP manages this queue space.
The CRIU sets a queue threshold, slightly smaller than the queue size,
to use as a benchmark to determine if congestion of the queue exists.
The gap between the queue threshold and the maximum queue size
provides a buffer to allow action to be taken before the queue becomes
full and datagrams start being discarded.  These queue thresholds are
pre-determined and entered into the CRIU by the local ADNS Manager.
The congestion identification function operates in the following
sequence.  The CAP generates a queue report, at intervals specified by
the queue report threshold.  This report captures the actual queue
levels and sends them to the CRIU.  These levels are compared to the
queue threshold for each queue.  If any queue level is greater than
the queue threshold, then a congestion condition exists in that queue.
The macro behavior of this arrangement is very similar to congested
routers in a conventional Internet so TCP, including the Karn and
Nagel algorithms, will work without change.



a.  Load Sharing

One of the key features of ADNS is its ability to share the traffic
load over available subnets.  In current Navy circuits a situation
frequently occurs in which one communication channel is overloaded
while another is completely idle.  The load sharing feature of ADNS
alleviates this problem by shifting some of the congestion to the idle
channel, thereby increasing throughput and shortening communication
system delays.  This differs from load balancing in that balancing
distributes traffic over channels with similar metric values before
congestion occurs.  Sharing distributes traffic over similar cost
channels because a congestion condition exists.

1) Restrictions

There are two restrictions on the use of load sharing.  First, the
traffic being shifted to an alternate channel must be unicast traffic
only.  Multicast applications introduce a level of complexity that
causes diminished returns, making it not worth the effort to attempt
to load share using multicast applications.  Second, load sharing is
only feasible between subnets whose bandwidths are in the same range,
meaning they share a similar time delay.  Thus, possible opportunities
for a load sharing situation are between UHF and EHF, or between SHF
and Challenge Athena.

2) Implementation

The load sharing process begins when the CRIU determines that a
congestion condition exists on a subnet in one of its associated CAPs.
The CRIU then scans all other compatible (those with similar delay
times) subnets to determine if a path from origin to destination
exists.  If another subnet does exist with a path from origin to
destination and no congestion condition exists on this subnet, load
sharing commences.

b. Source Quench

When congestion is determined to exist in the CAP queue for priority
n, the CRIU issues a Source Quench ICMP command.  This command stops
the generation of message packets for all applications and hosts with
priority n or less.  Assuming compliant TCPs this Source Quench
command has been pre-set to remain in force for five seconds.  At the
end of five seconds, transmission from the affected hosts and
applications resumes automatically unless or until another Source
Quench command is issued.  It should be noted that all applications
and hosts require some sort of flow control to ensure that during
Source Quench conditions, packets are not discarded but rather stored
for transmission when the Source Quench has timed-out.

4. Transmission Control Protocol (TCP) Duplicate Packet Transmission
Problems

One of the major early setbacks to implementing the ADNS architecture
was solving the problem of TCP duplicate transmissions when initially
establishing a TCP connection.  ADNS causes the LAN gateway router to
act as if it is hard-wired to other routers on other LANs.  Thus the
router expects to encounter minimal delays (less than 0.5 seconds) in
receiving acknowledgments to its TCP packets being sent.  In reality,
these TCP packets are being transmitted over RF links to distant LANs.
The minimum acknowledgment time for a 1500 byte packet over a 2400 BPS
connection is in the neighborhood of 5 seconds.  When TCP hasn't
received packet acknowledgment after 0.5 seconds, it re-transmits the
packet.  If acknowledgement is still not received after an additional
1 second, TCP retransmits the packet again, and again after 2 seconds,
4 seconds, 8 seconds, and so on.  Under optimal conditions, a 1500
byte packet will be sent 4 times over a 2400 BPS connection.  The end
result is the use of 6000 bytes to transmit 1500, an efficiency of
25%.

a. TCP Duplicate Packet Rejection

A practical solution, and the one implemented in ADNS, is to design
the CRIU to discard duplicate TCP packets before they are transmitted
over the RF link.  This is accomplished by the use of a table for each
subnet that contains the TCP sequence number and time-stamp indicating
when the packet was received by the CRIU for transmitting.  A TCP
original packet and each duplicate packet sent will have the same TCP
sequence number.  When a TCP packet is received by the CRIU for
transmitting, its TCP sequence number is examined.  If this number
already exists in the table, the packet is rejected.  If this number
does not exist in the table, it is added to the table along with its
time-stamp, and the packet is passed along for transmission.  Each
subnet is assigned a TCP duplicate rejection time.  If a TCP sequence
number has been in the table for longer than the TCP duplicate
rejection time, it is deleted from the table.  The TCP duplicate
rejection time has a default value of 10 seconds.  This provides for
transmission of the original TCP packet followed by a 10 second delay
for acknowledgment.  If none is received, the packet is allowed to be
retransmitted followed by another 10 second delay.  This time delay
can be modified by the Local ADNS Manager, based on the latency of the
link, for optimum performance.

D. ADNS INTEGRATED NETWORK MANAGEMENT

1. Overview

Network management of ADNS is based on SNMPv1 standards.  There are no
proprietary Navy protocols to confront, thus allowing the use of
standard network management tools and practices.  Most of the objects
to be managed (hosts, routers, etc) will have agents attached and MIBs
will be written for any unique objects.  The Navy will adopt a
standard, commercial Network Management System (NMS) to provide the
foundation for network management.  However, there are Navy-specific
concerns, such as command and control relationships, which impact
network management.  For these special requirements, the Navy will
create special applications and concepts to the NMS.  This section
gives a broad description of how the Navy intends to manage ADNS.

Network management of naval nodes is similar to managing shore-based
nodes.  The fundamental concepts are the same.  However, the mobile
nature of the nodes makes managing shipboard nodes more difficult.
The fact that they are warships makes management more important.  Just
as there is a military hierarchy there is one for network management
in ADNS, where each level has different responsibilities. Network
management is a vital portion of ADNS because the consequences of
system errors or failures can directly affect combat effectiveness.

Integrated network management describes how the Navy will manage
networks on a distributed basis all the way down to individual
objects. They include, but are not limited to: general monitoring,
statistic collection, status monitoring, traffic monitoring, trend
analysis, network loading, network optimization, configuration
control, system configuration, maintenance, problem identification,
problem reporting, trouble documentation, system administration, and
emissions control [INM Technical Approach].


Network management of ADNS contains three different levels: the Local
Control Center (LCC), Autonomous System Control Center (ASCC), and the
Navy Operations Center (NOC).  The LCC will be responsible for
networks at the local level, e.g. within an area (usually a ship).
The ASCC will be in charge of networks on a regional level, having
several subordinate Autonomous Systems.  The NOC will be responsible
for all ASCCs in a certain geographic area.  This arrangement is
consistent with the Navy's organization and its doctrine regarding
distribution of authority.

a.  Local Control Center (LCC)

The LCC is the network management center at every unit level.  There
is a local responsibility to monitor and maintain the status of all
subnets at that unit.  There are three components of an LCC: a Network
Manager, Distributed Manager and a Communication Automation Manager.

i) Network Manager

The Network Manager is network management system software that is
obtained commercially.  The purpose of the network manager is
basically to give the status of the network and individual objects.
An example is the popular HP Open View Network Node Manager product
(OV-NNM) which has been in the Navy Tactical Advanced Computer (TAC)
contracts since 1991.  It provides a topological map representation of
a unit's network and shows the status of each object with the use of
colors and shapes.  However, human interaction is required to
interface with the ASCC and the NOC for troubleshooting or
maintenance.  The specific functions of a Network Manager will be:

* Human machine interface
* Performance management
* Fault management
* Accounting management
* Security management
* Configuration management

The Network Manager will be used as the foundation for the Navy's
Integrated Network Management System, where specific applications can
then be added on to provide other management functions.

ii) Distributed Manager

Distributed Management is an application that determines what is to be
reported locally and what is to be reported to the ASCC and NOC. The
Distributed Manager has two mechanisms for discovering if any
conditions exist that meet the criteria of its policy rules:

* Notification from the Network manager
* Query from Distributed Manager to Network Manager

The specific functions of the Distributed Manager will be:
* Interpretation and implementation of policy
* Filtering of management information

Although commercial products can provide these functions, the
distributed manager in the Navy context specifically describes the
policy rules for the communication relationships between the LCC and
ASCC.

iii) Communication Automation Manager (CAM)

The Communication Automation Manager is in charge of the physical
communication hardware and their related requirements.  On a ship,
they are functions typically related to the radio room.  Duties
include a communication plan implementation, circuit building, and
circuit management.  Three areas make up the Communication Automation
Manager: the Communication Manager, Site Manager, and Equipment
Manager.  The specific functions of the Communication Automation
Manager will be:

* Security management
* Log Control
* Alarm reporting
* Summarization
* Attributes for representing relationships
* Objects and attributes for access control
* Usage Metering
* Test Management
* Event Report Management
* State Management
* Security alarm reporting
* Object management
* Bandwidth management
* Communication plan management
* Equipment control
* Site configuration management

The Navy specific application for these functions is the use of a
remote management tool called the Communications Plan (COMMPLAN).  The
COMMPLAN will used to direct certain network management functions as
described above.  This is still mainly accomplished manually by a
technician after receiving the COMMPLAN via hardcopy message.  However
ADNS will allow many of these requirements to be accomplished remotely
and automatically via the COMMPLAN transmitted to the Communication
Automation Manager.  This concept can be applied to commercial
industries where it is not cost effective to have the necessary
network management expertise at every local site but can instead be
centralized at one remote center.

b. Autonomous System Control Center (ASCC)

An ASCC monitors the operation of several LCCs.  The Navy's
configuration will use its regional shore communications master
stations (NCTAMS) as ASCCs.  The ASCC will receive summary reports
from subordinate LCCs. The exact nature of reporting from an LCC to an
ASCC is still to be determined but will contain mission relevant
information.  Such reporting requirements can include:

* Readiness of communication to support the mission.
* Status of communication services.
* Status of hardware and software.
* Information about usage and reliability.

ASCCs can also give direction to LCCs regarding communications
posture.  This could include such items as prioritization of resources
or equipment configuration changes.

c.  Network Operations Center (NOC)

The NOC is the next level above an ASCC for reporting network
management information.  The NOC would basically monitor all nodes in
a certain geographic location.  For example the Navy has established a
NOC in the Pacific and Atlantic regions.  Although capable of
monitoring detailed network management information, a NOC would be
more interested on the overall status of ASCCs and LCCs.

2. NETWORK MANAGEMENT TOOLS

To achieve the above network management requirements, a vast array of
tools are available to all levels of management and maintenance
personnel.  However, each tool comes with their own training
requirement.  Therefore the total cost of ownership must be taken into
consideration against their utility.  The basic tool for monitoring
the network is commercially available Network Management System
software.  Another tool available for the goal of transparent and
affordable network management is software that is capable of remote
monitoring and maintenance.  These can also be available commercially
or can be developed to be mission specific.  There are always emerging
tools on the horizon for new technologies.  However, one of the
primary reasons why network management techniques lag behind new
network technologies is that time is needed to see which technologies
will become established as industry standards.  ADNS will manage
objects primarily through SNMPv1 standards.  That is not to say that
ADNS can not adapt any emerging technologies that become industry
standards, such as SNMPv2.  However, SNMP has proved that it will be
around for a long time.

a.  Network Management System Software (NMS)

A commercial Network Management System software has been adopted for
the foundation of the INM.  Network Management System software allows
for the basic functions of monitoring nodes and network status.  As
described earlier, many different types of enterprise management
software are available commercially, such as the popular HP Open View
Network Node Manager (OV-NNM).  Although commercial software provides
excellent monitoring tools, proprietary software is often required to
achieve other network management requirements.  Commercial Network
Management System software offers a fairly inexpensive solution that
provides a solid foundation of network management tools.
Additionally, to provide the flexibility desired throughout ADNS a
COTS product is appropriate.

b.  Third Party Applications

An attractive feature of a Network Management System such as OV-NNM is
that third party applications can be integrated into it.  Especially
for organizations like the Navy, solutions to mission specific
requirements can not be obtained off the shelf. These mission specific
add-ons must be developed independently and then integrated into the
existing NMS.  Proprietary equipment also requires some kind of
integration with the NMS.  Such things as configuration management
software for specific objects must be obtained from the vendor.  For
example, companies offer software that can be integrated with an NMS
to allow managers to remotely configure their hardware. Third party
applications offer remote management capability.  This is the whole
purpose of enterprise management.  It is very cost effective to
centrally manage nodes rather than paying for the necessary expertise
at every local level.  Although there needs to be some human
interaction at every level, full management capabilities are not
required down to the local level.

ADNS is a good example of the need for remote management.
Implementation of remote management over ADNS will allow managers to
configure and manage mobile platforms from a central management
location.  This, in turn, allows the assignment of minimal personnel
at the local level, thus saving on personnel costs.  With such
standards as RMON and SNMPv2, remote managers can access remote
networks in a secure manner and troubleshoot or reconfigure the
network.  For example, if one transmission path fails, a remote
manager can gain access to the system via a second transmission path
and troubleshoot the system.  The use of more than one transmission
path allows the ability to continually manage LCCs and even ASCCs
remotely through just one open path.  Although ADNS has not adopted
such standards as RMON or SNMPv2 yet, the technologies currently exist
and can be readily integrated into ADNS.

III. Hardware

A. LAN

The LAN will typically be the existing shipboard Ethernet or FDDI
network.  Hosts on the network will run a wide variety of
applications.

B. Router

The router is an IP router that acts as a gateway to the ADNS network.
The router can be any commercial router capable of running OSPF.
Currently the ADNS program uses the CNX 600 Proteon router.

C. CRIU (Channel Access Protocol to Router Interface Unit)

The CRIU is implemented on a single board computer installed in a VME
chassis.

D. CAP (Channel Access Protocol)

A CAP is also implemented on a single board computer mounted in the
same VME chassis as the CRIU.

E. Cryptographic Device

Navy ADNS installations use the KG-84 for link encryption.

F. Modem

For each CAP there is a corresponding Modem that performs the analog
to digital (inbound) or digital to analog (outbound) conversion of
data passing through ADNS.

G. Connectivity Media

Each RF system (e.g. UHF Satcom, EHF Satcom or INMARSAT B) constitutes
one network when considering all assets in one ADNS Autonomous System.


IV.  Acknowledgements.   The engineers at NRaD, Code 82 working on
ADNS.

Authors addresses.

Rex A Buddenberg
Naval Postgraduate School
Code SM/Bu
Monterey, Ca 93943
budden@nps.navy.mil

The masters students have graduated and moved to new assignments in
the military.  With new e-mail addresses; reach them through the
above.  Complete copies of theses available at
http://web.nps.navy.mil/~seanet.



INTERNET DRAFT          EXPIRES MARCH 1997              INTERNET DRAFT